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

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

>   But we do have the proper data already. Its called modedb. I have two 
> reasons for why I hate to have a var in struct display. One is that it
> makes fbcon heavier. You now have a extra var in every struct display. 
> Usually the user has several if not all VCs at the same resolution. That 
> means there is alot of duplication of the same data for now reason. If we 
> use modedb to fill in the extra data then we don't need the extra data in
> each struct display. The bonus there is permentally stored data to represent 
> that one mode to everybody!! Much lighter.

I don't agree... again. What is the semantics _users_ are the most
comfortable with ? an stty size or a resolution ? All OSes so far
let user pick up resolutions (w/h/freq), this is the thing users are
getting used to :) That's how we should, via fbset or whatever other
tool we have, set a resolution. The actual fbcon size is just a side
effect of the resolution and font size.

Modedb isn't always a solution with some fancy displays too...

Also, if I ever start doing dual head, I'll have interesting side
effects to deal with, which means for example  that enabling mirroring
will possibly change the resolution of the primary head. That means that
I'll have to trigger a mode change in console based on ... a resolution,
not a console size. I just want the console size to adapt.

Now, wether this mode is common to all VCs or per-VC is a different
story, I tend to like when it's per-VC for various reasons, one of them
beeing that if I set something that doesn't work, I can always go back
to my working VC :)

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