> > All you are doing is redirecting output from one VT to another. It's the
> > same as grep foo.txt > /dev/tty3 and getting output.
> It was meant to show you that parameter 'con' passed to fb_get_var
> and fb_set_var function HAS meaning and you cannot simply remove it.
No it doesn't in that example. The text data output from that app is
being redirected into another tty. This is handled in the tty layer. It
has nothing to do with the con parameter.
> But I simple do not see
> why you are still trying to remove possibility of setting different
> vertical refresh, color depths or videomodes on different VT by stupid
> idea that if not everyone can support it, so remove it completely...
Videomode:
Just set the video mode with different columns and different number of
rows or set a differnt font size on that VC. This will change the video
resolution.
Color depths:
The console looks at a color as a color palette not a depth. At max
their are 16 entries in the color palette.
Vertical refresh:
With properly written driver it would find the best refresh rate for a
mode. This would require knowing about the monitor and the video card. I
plan to add this to fbdev.
> > that a text console programmer would be interested in are the color
> > palette and the video mode. Both can be extracted on the console level. In
> > text console terms this is number columns and number of rows. The color
> > palette well would be the color palette. This is the kind of info that a
> Midnight commander yes. But there is for example fbtv, svgalib over fb and
> couple of different other apps which can run in parallel over same framebuffer
> just now...
> > As for a graphical program I see no reason and also a lack of stability
> > if you allow apps running on different VCs to open the same /dev/fb and
> > program it at the same time. Why run multiple X server on different
> Program? Just now I can run four instances of fbtv at once, one in left
> up corner, one in right up, another in left down and right down... And it
> works, hardware does not crash and everyone is happy. It is same like that
> old Unix did not have mandatory locking -
Multiple access to framebuffer is not the problem. In fact the PCI bus
ensures serial access in a SMP environment. See below. UNIX does properly
virtualize the hardware :)
> it is your problem if you did
> not do proper locking (and if you have so stupid hardware that it can
> die with inaprorpiate access, either remove rights to /dev/fb for non-root
> or buy better hardware). But do not force open-once on us.
Multiple access to the framebuffer is not the problem. The problem is
if you run fbvt and you run libsvga on top of fbdev which changes the mode
at the same time fbvt is running (think SMP). Their is a change of the
hardware state by one app that effects all the other apps. You could use
userland locks and save the hardware state. Just pray to god that all the
apps behave right.
With VTs its pointless to support anyways since only one VC is active
at a time (single head). The other graphics apps will be put to sleep so
they don't run in parallel. The ones that will run in parallel on a SMP
machine will be on different pieces of video hardware.
> > VT when we have today virtual desktops provided by X window managers.
> X has to open multiple VT if it wants to drive multiple display device.
> Otherwise it breaks currently established behavior that ctrl-alt-fX moves
> you to some VT (and I want this behavior - I run X because of I must, not
> because of I want and I want to be able to quicky switch between X and
> anything else by simple ctrl-ralt-f12).
Switching between X and console is okay but to support running a different
X servers on every VC is just dumb when you can have a userland solution
like virtual desktops. Not only that but its just expensive to do. If you
want a X server to support multihead then all it has to do is have one
X server open all the avaliable /dev/fbX not multiple VTs. Once Vojtechs
input system goes in and we have lost fo fbdev drivers then XFree86 will
no longer need to touch any VTs to do anything.
> > If Linus is okay with it I will send him some patches.
> First check them... Do you remember your open once patch in 2.3.51-something
> which broke almost all fb applications I know?
The apps (Mesa, libsvga fbdev wrapper) I have did work fine. I didn't have
the apps that toke advatange of the brokeness of the fbdev layer. Now I
post to the general public to test my patches before I send them to linus.
Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.
James Simmons [jsimmons@linux-fbdev.org] ____/|
fbdev/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue May 23 2000 - 21:00:13 EST