linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>, Andrew Morton <akpm@osdl.org>
Cc: Antonino Daplas <adaplas@pol.net>,
	Linux Frame Buffer Device Development
	<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: Re: [RFC] Video Mode Handling
Date: Mon, 9 Aug 2004 16:26:30 +0800	[thread overview]
Message-ID: <200408091626.31353.adaplas@hotpop.com> (raw)
In-Reply-To: <Pine.GSO.4.58.0408090920511.14159@waterleaf.sonytel.be>

On Monday 09 August 2004 15:23, Geert Uytterhoeven wrote:
> On Sun, 8 Aug 2004, Andrew Morton wrote:
> > "Antonino A. Daplas" <adaplas@hotpop.com> wrote:
> > > Most fbdev developers are proposing to bring back the per-display var
> > >  structures to ease the difficulty of video mode handling.  This
> > > proposal is countered by a few (notably James) in that it severely
> > > increases the memory footprint of the kernel.
> >
> > Surprised.
> >
> > By how much does this increase the kernel's memory footprint?
>
> Indeed, you need a full mode database per driver.

Not necessarily.  For drivers which cannot change the videomode, a single
entry is tops. 
 
>
> > And how much simpler would the code be if we were to bring back the
> > per-display var structures?
> >
> > IOW: what's the tradeoff here?
>
>   - per-display var:
>       - increase memory footprint by
>         MAX_NR_CONSOLES.*sizeof(struct var_screen_info)
>       + simpler code
>       + 100% compatible with 2.4
>
>   - private modedb:
>       - increase memory footprint by full mode database per driver.

Note: the private modedb will start with a single entry.  Entries will be added
each time the user does an fbset.  A typical user will probably use less than 10
modelines. I personally use only 3.  In contrast, saving the modeline per display 
already amounts to approximately 64 modelines. 

Also, the private modedb is needed for the resize/stty path.  Without the private
modedb, fbcon will use the default modedb.  And the modedb contain entries
from a mixed hardware.   

>       - more complex (and larger) code

Yes, larger code. But we eliminate the the static mode database and instead of
saving sizeof(struct fb_var_screeninfo) per console, we save only 1/2 of that
per console.

>       - subtle differences with 2.4, because not the whole var is saved

With the patch, the whole var is saved except for xoffset, yoffset and activate.
The timings will be derived from the fb_videomode which  is only a pointer in
the display structure. There should be no difference between 2.4, unless
xoffset, yoffset and activate are critical to the driver's functioning. 
 
>         (BTW, which fields do you want to save, and which not, so I can
> 	 evaluate the impact on some drivers?)

All the fields in var are saved, one way or the other,  except for xoffset, yoffset and
activate.

Tony




-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com

  parent reply	other threads:[~2004-08-09  8:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-09  1:43 [RFC] Video Mode Handling Antonino A. Daplas
2004-08-09  3:50 ` Jon Smirl
2004-08-09  7:59   ` Antonino A. Daplas
2004-08-09 14:56     ` Jon Smirl
2004-08-09  6:04 ` Andrew Morton
2004-08-09  7:23   ` Geert Uytterhoeven
2004-08-09  8:03     ` Andrew Morton
2004-08-09  8:10       ` Geert Uytterhoeven
2004-08-09  8:41       ` Antonino A. Daplas
2004-08-09  8:26     ` Antonino A. Daplas [this message]
2004-08-09  7:59   ` Antonino A. Daplas
2004-08-09  8:08     ` Geert Uytterhoeven

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=200408091626.31353.adaplas@hotpop.com \
    --to=adaplas@hotpop.com \
    --cc=adaplas@pol.net \
    --cc=akpm@osdl.org \
    --cc=geert@linux-m68k.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).