> Yes. But then change ioctl numbers! Current API allows you to retrieve
> videomode of arbitrary VT->fb session by issuing following code. Do:
> (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.
> So create new API. But do not remove old working one unless there is new
> one. Old API is well established...
If linus allows it I have no problem with that. It's a matter of a few new
ioctl calls in vt.c.
> > With a fbcon
> > 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
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
text console programmer would be interested in. He would expect his
application work on all consoles no matter what hardware drives it.
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
VT when we have today virtual desktops provided by X window managers.
> > 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.
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