Re: Re: [RFC] Video Mode Handling

On Monday 09 August 2004 15:23, Geert Uytterhoeven wrote:

On Sun, 8 Aug 2004, Andrew Morton wrote:

quoted

"Antonino A. Daplas" [off-list ref] wrote:

quoted

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. 
 

quoted

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