Re: Re: [RFC] Video Mode Handling

Geert Uytterhoeven [off-list ref] 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.

Sorry, that's way outside my area of knowledge ;)

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)

I see no var_screen_info.  sizeof(struct screen_info) is 56 bytes, and
there are 63 of them.  This is a negligible amount of memory!

      + simpler code
      + 100% compatible with 2.4

  - private modedb:
      - increase memory footprint by full mode database per driver.
      - more complex (and larger) code
      - subtle differences with 2.4, because not the whole var is saved
        (BTW, which fields do you want to save, and which not, so I can
	 evaluate the impact on some drivers?)

Well gee.  If we're talking about 3k, or even 10k or 30k, let's go with the
simplest code?


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