On 17 May 00 at 10:40, James Simmons wrote:
> > (sleep 5; fbset > /dev/tty5) & chvt 5
> > and wait 5 seconds. It will print resolution of VT where you typed your
> > command to tty5! Not tty5 resolution! (in C you can use TIOCSCTTY to define
> > on which VT/fbcon pair you'll operate)
> 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.
> > > independent way you could retrieve this info no matter if the non visible
> > > console is fbdev driven or mda driven :) Does the console system have this
> > > functionality. From what I can see no :(
> > Sorry, but you cannot retrieve MMIO start / depth / I do not know what
> > if device is not framebuffer one, so I do not see your point...
> fbcon was designed with the intent to create a graphical console
> system. Meaning video cards that lack hardware text modes, only pixel
> based modes, would have a text emulator layer (fbcon) to ensure that a
> linux system would have a text console system. To the text console
> programmer each type of console system should appear to be the same no
> matter what video hardware is driving it. The two pieces of hardware data
If it is some character based application, such as midnight commander,
telnet, vi, then I have no objections against simple (existing) API which
allows me to retrieve columns and rows of display. 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... Because
of msdosfs does not support lowercased filenames longer than 8.3 we should
remove this functionality from ext2/hpfs/ntfs/iso9660/... ? No.
> 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 - 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.
> 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).
> > > So it does need to be implemented.
> > > I just prefere that it be done via the console layer instead of the fbcon
> > > layer because of the reason above.
> > Yes, I have nothing against access through console layer. But first do
> > this and then remove support from fbdev. Your proposed scheme must be
> > able to work by always passing con=64 (64 does not exist currenty) to
> > fbdev, so first do fbcon and then fbdev...
> 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?
Petr Vandrovec
vandrove@vc.cvut.cz
-
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