Re: [PATCH] fbdev: Fix crash if fb_set_var() called before register_framebuffer()

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

On Sat, 2004-11-27 at 10:56 +0800, Antonino A. Daplas wrote:

> 1. Lack of per-display var which prevents full restore of the console on 
> mode switch
> 2. the stty utility does not work correctly for drivers that do not have
> mode validation

Ok, good.

 .../...

> 3.  For each correct fbset, (accepted by both driver and user), if
> the timings are unique, this will be also be added to the modelist. Also,
> in the unfortunate case that an illegal mode timing is accidentally entered
> into the modelist, there is a mechanism to remove that entry.

Ok, though I'm not too fan of this one, I'd rather have an explicit flag
in the var passed by fbset trigger the "remember" thing... oh well,
we'll see how things goes.

> Therefore, when doing an stty, fbcon will only look at info->modelist,
> finds the best matching mode, builds a var from that particular entry
> and passes the var to the driver.  There is no guesswork involved, and
> drivers will always operate on known working mode timings.

Yah, I know that problem, this looks like a good solution.

> Also, the graphics states per console are also preserved.  However, instead
> of saving a var per console, we only save a part of the var, the graphics
> state. The mode timings are saved as pointers to entries in info->modelist.
> In effect, we have the full functionality of a per-display var, but we save
> half the memory, that's around 5K.

I dislike the pointers tho. Remember that one day, we'll do monitor
hotswap, which means that at one point, the driver will
remove/add/rebuild modelist... 

> You'll probably notice that with recent kernels, if you switch consoles,
> your previous console settings are restored.  Also, doing an stty should, in
> theory, never produce a corrupt console, even if you enter insane numbers.
> Of course, the effectivity of stty depends on the number of entries in
> info->modelist.

Yah, sounds good.

> Anyway, the goal here is to fix as many regressions as possible.  And I
> think the 2.6 framebuffer is now behaving in almost the same manner as 2.4,
> with a few minor exceptions. 
> 
> BTW, a few drivers do fill up info->modelist before register_framebuffer(),
> rivafb and savagefb.

I'll add that to radeonfb too, I'm working on a big update of this
driver adding power management support for newer apple laptops plus a
few other things, I'll include that as well.

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/