From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>, adaplas@pol.net
Cc: Linux Fbdev development list <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [PATCH] fbdev: Fix crash if fb_set_var() called before register_framebuffer()
Date: Sat, 27 Nov 2004 12:43:38 +0800 [thread overview]
Message-ID: <200411271243.40230.adaplas@hotpop.com> (raw)
In-Reply-To: <1101528953.4668.7.camel@gaston>
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/
prev parent reply other threads:[~2004-11-27 4:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-24 17:15 [PATCH] fbdev: Fix crash if fb_set_var() called before register_framebuffer() Antonino A. Daplas
2004-11-26 0:20 ` Mario Gaucher
2004-11-26 0:45 ` Antonino A. Daplas
2004-11-26 23:17 ` Mario Gaucher
2004-11-26 23:35 ` Antonino A. Daplas
2004-11-26 22:38 ` Benjamin Herrenschmidt
2004-11-27 2:56 ` Antonino A. Daplas
2004-11-27 4:15 ` Benjamin Herrenschmidt
2004-11-27 4:43 ` Antonino A. Daplas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200411271243.40230.adaplas@hotpop.com \
--to=adaplas@hotpop.com \
--cc=adaplas@pol.net \
--cc=benh@kernel.crashing.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.