Re: [PATCH] neofb patches

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> Firstly, all of the graphical apps you're describing should be VT-aware. 
> If they aren't, you shouldn't be using them on anything other than
> dedicated framebuffers anyway, really.  It's not hard to make an app work
> with VTs and it really is the correct way to do things for anything that
> is likely to be run in a VT-console environment.

A good idea would be to produce a library that implement most of the
ground VT handling work in fact... That would simplify things for
apps tremendously. Though it should probably sit between the app
and the kernel for console input as well.

It would basically callback into the app for things like beeing swithout
out and back in.

> With this issue solved, all that needs to be done is to make it so that
> apps which open up a new VT, automatically get it on the same framebuffer
> as the currently active console (or better yet, the console associated
> with the app) is on (which is really the most intuitive thing anyway, and
> should probably be done on general principle).  Problem solved.
> 
> You really don't need all the complex machinations of a magic /dev/fb
> device to achieve this.  If the rest of the system is designed well the
> right behavior should be automatic without this extra effort.
> 
> -alex
-- 
Benjamin Herrenschmidt <benh@kernel.crashing.org>



-------------------------------------------------------
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