On 16 May 00 at 23:37, James Simmons wrote:
> On Tue, 16 May 2000, Petr Vandrovec wrote:
> > I'm glad that he skipped matroxfb) and then, maybe, he'll write fbcon
> > layer. But we had long discussion about this on linux-fbdev couple of times
> > during last couple of months, so I'll shut up.
> Fbcon already handles VTs with different different video modes. If you are
> talking about the lack of retrieving fbdev specific info from the /dev/fb
> interface on non active VTs then realize that /dev/fb lacks this now. The
> peices of info we want (palette and color map) should be express in
> a fbcon indepedent way. This means it should be retreived from the console
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)
> layer. Why? In the future we could have multihead systems that are a
> mixture of fbdev drivers and non fbdev drivers. Actually we could do this
> now with a fbcon and mdacon setup. We could write a program and run it on
> a fbcon console and what if we want say the video mode on the non visible
> mdacon console. Since mdacon lacks a /dev/fb interface we couldn't get
> this info via the /dev/fb interface as you purpose.
So create new API. But do not remove old working one unless there is new
one. Old API is well established...
> 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...
> 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...
> The matrox driver days are numbered. He He!!!
Anybody wants to take over matroxfb development?
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:12 EST