Re: [PATCH] radeonfb(): memmove() fix -- this one works ;-)

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

> No. Look the logic should go from the upper VT layer to the lower driver 
> to accomplish something. Not the reverse.
> 
> struct vc_data -> native console driver structure --> fbdev

But the upper VT layer has no clue about what a graphic mode can be and
we know well enough that we _need_ to be able to enforce graphics mode
or want to play with them by manipulating var structures, without losing
the console.

Your logic is only ever valid once every single fbdev is capable of
doing proper mode management & validation. And even then, there isn't
a 1:1 relationchip between a mode and an fbcon size.

> Not.
> 
> fbdev --> native console driver --> struct vc_data.
> 
> This was the way it uses to be. If this is the case then I suggest we 
> write our own vt.c and vt_ioctl.c for the fbcon layer. We shouldn't even
> use struct vc_data then. In fact each fbdev driver should be independent 
> console drivers. That is how 2.4.X was. Each driver was nearly its own 
> console driver. We need to go one way or the other. 

I agree we need to go away and I'm not proposing adding anything to
fb_info nor whatever in this regard. It has to be all self-contained
in the console subsystem, that is fbcon. And we already have a data
structure holding per-console fbcon-specific data, it's called
struct display.

Ben.




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