Re: [PATCH] neofb patches

[John Zielinski <grim@undead.cc>]

Benjamin Herrenschmidt wrote:

>You don't need a /dev/fb for that do you ? You need to map the current
>vt to it's fb via the existing fbdev ioctls, isn't that possible ? (just
>asking , I've never actually done that).
>
>  
>
But how does the app find this out?  It would have to figure out if it's 
running on a real console then figure out which console is mapped to 
which fb and then try to find out which /dev/fbx device points to that 
fb.  Programmer's are lazy, they'll just make it a command line switch 
to specify what device to use which is not very user friendly.

What I'm proposing is that you open /dev/fb.  If it fails you're running 
on a serial line or shh or whatever.  If it succedes you issue 
KD_GRAPHICS ioctl on the /dev/fb device and that's it.  Very simple for 
the programmer.

The kernel does all the work.  It figures out what vt you're on and 
prevents access from serial or a pty.  It also would figure out which 
framebuffer device to connect to based on the con2fb map specified by 
the fbdev ioctls.  It would pass the KD_TEXT/KD_GRAPHICS calls to the 
appropriate vt.

This makes it very user friendly.  The user just switches to the vt 
that's on the moitor they want and starts the app.  The kernel figures 
out how to route this to the appropriate fb driver according to the 
con2fb map.

I might also be possible to use /dev/tty as the starting point if you 
want to make everything start at the vt layer and work down.   The fb 
ioctls would just have to be passed down.  Once a KD_GRAPHICS was issued 
on /dev/tty then read/write/mmap would pass down to the fb layer as well. 

John




-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click