[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fbdev-devel
Subject:    Re: [Linux-fbdev-devel] [PATCH] fbdev: Fix crash if fb_set_var() called before register_framebuffer(
From:       "Antonino A. Daplas" <adaplas () hotpop ! com>
Date:       2004-11-27 4:43:38
Message-ID: 200411271243.40230.adaplas () hotpop ! com
[Download RAW message or body]

On Saturday 27 November 2004 12:15, Benjamin Herrenschmidt wrote:
> 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.

You mean the mode entry deletion? That's okay, the code is minor, still
unused, and was submitted as optional, but still got merged.  It can be
easily removed.

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

Removing/adding/rebuilding the modelist should be doable with pointers. But
in the case people don't want pointers, this can be easily changed.  The
conversion code is entirely in display_to_var() and var_to_display() helpers.
  
Tony




-------------------------------------------------------
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/
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
[prev in list] [next in list] [prev in thread] [next in thread]