[RFC] Video Mode Handling

[RFC] Video Mode Handling

[Antonino A. Daplas]

Hi,

Video mode handling in fbdev-2.6 is becoming better, but is still not in
the same league as with fbdev-2.4.  The reason is that the upper vt layer
does not have any information about the video mode itself which leaves
the lower fbdev layer to fill in or replace the fields in a
partial/incorrect fb_var_sreeninfo structure (var).  This limitation is
partly alleviated by using fb_find_mode() to pass a complete var. 

fb_find_mode() will look for entries in a database in which most entries
are not compatible with the graphics/display combination.  The driver will
still need to "massage" the contents of var to make it work with the
particular combination.  Secondly, the current system does not preserve
the entire graphics per-console settings (such as bpp, virtual resolution,
etc). Thirdly, fb_find_mode() requires that the mode database need to stay
in the memory for the entire lifetime of fbdev/fbcon, increasing the kernel's
memory footprint. Finally, this requires that all drivers are capable of
guaranteeing a working display without any user intervention.

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.  

How about a compromise then?

The fb_var_screeninfo structure contains the following:

	a. settings of the graphics card
	b. settings of the attached display
	c. fields used internally by core fbdev/fbcon which has no
	   relevance in video mode setting (ie, xoffset, yoffset)

Instead of saving the entire var, we just save the settings of the
graphics card.  Settings of the attached display will be replaced by
pointers to entries in a mode database.  Internally used fields will not be
saved, as these are typically handled by fbcon for each mode switch.

One requirement is the creation of a mode database that is valid and private
to the driver. This database must also be capable of adding new entries to its
list (such as when a user does an fbset), and optionally deleting entries which
might be entered by accident (such as when a var passes the driver's check_var()
function but the resulting mode is not acceptable).  

So when using 'stty', all fbcon needs to do is search the drivers private
mode database, and build a var using a combination of the previous graphics 
settings and the best fitting videomode.

When switching consoles, fbcon will rebuild the var using the settings in 
struct display and the saved pointer to a videomode structure.

Implementation:

The current modedb array is not sufficient for the task, as it's quite difficult
to manipulate array entries.  A more flexible format isneed. The mode database
can be made in the form of a double-linked list
((struct list_head) info->monspecs.modelist) to make the task easier.

Drivers can choose to add their own entries to the modelist. We have functions
that can convert a modedb array to a mode list. Or the driver can choose to
leave the modelist uninitialized/empty. In this case, fbdev will add a single
mode entry to the list, the values of which are gathered from the current var
(info->var).

Whatever approach is taken, the driver now has a private modelist with a minimum
of 1 entry where all entries are supposed to be guaranteed to work for the attached
display/s. The upper layer (fbcon) can then use this private modelist during
resizing or it can save an entry pointer in struct display, to be used when
switching consoles.

The modelist is required to grow in size since we cannot avoid users using their
own timings.  For each fb_set_var(), a struct fb_videomode is created from the var,
and if the mode is unique, it will be added to the modelist.

If a non-working mode entry is accidentally or unaccidentally added to the modelist,
we give the user the option to remove this from the list.  To make it simple, all
the user needs to do is an fb_set_var ioctl where the var contains the invalid
timings and var->activate = FB_ACTIVATE_INV_MODE.

The end-effect of all of the above is a behavior that approaches that of fbdev-2.4. 
Graphics/display settings are preserved per console. The 'stty' path, in theory,
should always work as it will only use entries in the driver's private mode list.
Although it has additional code size and complexity, this is more than compensated
for by the possibility that static data can be marked __init.  Instead of saving
the entire var structure per console, approximatedly half of the var's size is saved.
Another advantage is that the requirement for foolproof mode handling by drivers is
de-emphasized.

I'm going to follow-up with patches for the kernel and a patch for fbset to demonstrate
the proposal. The patch should not require any changes to low-level drivers nor break
compatibility with userland apps.

Let me know of comments or bugs.

Thanks.

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

Re: [RFC] Video Mode Handling

[Jon Smirl]

There was a lot of discussion about mode handling at OLS. Here's some
of the lwn coverage...

http://lwn.net/Articles/94202/
http://lwn.net/Articles/94763/

I'll attach a list of points discussed. Mode setting needs to cover
multihead cards, and devices that only use the BIOS for mode setting.
There also needs to be coordinated memory management when multiple
heads are involved. Point 7 talks about a design where most of the mode
setting code is moved to user space via hotplug.

Can your design be adjusted to work in the framework outlined below?

---------------------------------------------------------------
After talking to many people at OLS this seems to be the consensus for
rearchitecting fbdev/DRM. It has been proposed that this design be a
five year goal and there is still disagreement about the exact path to
get there.

This is a first pass for lkml people. I will incorporate comments and
repost for the final pass. I'm sure everyone will let me know if I've
misinterpreted some of the design points.

First a basic definition. There are two consoles, the kernel one
(printk, kdbg, OOPs, etc) and user one (normal console logins). In
Linux these are currently implemented with the same code. There may be
advantages to splitting the implementation in a future design.

1) PCI ROMs - these would be exposed via sysfs. A quirk is needed to
track the boot video device and expose the contents of C000:0 for that
special case. See the lkml thread: Exposing ROM's though sysfs, there
are already proposed patches.

2) VGA control - there needs to be a device for coordinating this. It
would ensure that only a single VGA device gets enabled at a time. It
would also adjust PCI bus routing as needed. It needs commands for
disabling all VGA devices and then enabling a selected one. This device
may need to coordinate with VGA console. You have to use this device
even if you aren't using VGA console since it ensures that only a
single VGA device gets enabled.
Alan Cox: what about hardware that supports multiple vga routers? do we
care?
JS: no design work has been done for this device, what would be it's
major/minor? would this be better done in sysfs?

3) Secondary card reset - Handled by an initial hotplug event. We need
a volunteer to write clean vm86 and emu86 apps for running the ROM
initialization. Resetting needs #1 and #2 to work since resetting a
card will enable it's VGA mode. I have an implementation of this but it
needs a lot of clean up.

4) DRM code reorganization. There were several requests to reorganize
DRM to more closely follow the Linux kernel guidelines. This
reorganization should occur before new features are added.

5) Multihead cards will expose one device file per head. Many IOCTLs
exposed by these devices will be common. Some, like mode setting, will
be per head.

6) Mode setting before early user space - this was decided to be a
platform specific problem. With minor adjustment the kernel can be made
to boot without printing anything except errors before early user space
starts. Platform specific code will need to handle these error messages
if any. This includes INT10, Openfirmware, mainframe serial consoles,
VGA mode. Suppressing informatory printing before early user space
starts allows a clean boot straight into graphics mode.

7) Mode setting from normal user space - devices will have a standard
IOCTL accepting a mode string like fbdev currently uses. This IOCTL
will lock the device and optionally trigger a hotplug mode event. Mode
setting for some fixed devices is simple enough to avoid the hotplug
event. In the hotplug event the mode line will be decoded, DDC queried,
etc. Some classes of devices (for example Intel 810,830,915) have to
have their mode set using vm86 and the video BIOS. Others might use a
small C app to query DDC and then use a device specific IOCTL to set
the mode registers. Early boot and normal user space will use the same
hotplug apps so they need to be as small as possible (good luck IA64
and emu86).

8) Merged fbmode - per head mode lists will include merged fb modes if
the other heads aren't in use. Setting a merged fb mode will lock out
the other head devices. It was decided that this was a better design
than having a control device.

9) printk - setting the mode will also record the fb location, size,
stride. Combining this info with the current fbconsole code will allow
printk/oops to print in all modes.

10) a new system console UI is proposed. SysReq blanks the current
screen and replaces it with the system console. System console will
also support runing kdbg. Hit SysReq again and whatever you were doing
is restored. This operation does not change the video mode.

11) OOPs will cause an immediate screen clear and painting of the
system console including the OOPs data. It is not needed to change the
video mode. Further drawing to the screen will be blocked until SysReq
returns to normal operation if possible.
Alan Cox: No consensus on the screen clear bit - there are actually
reasons to argue against it.
JS: Maybe save the contents at OOPs time and hotkey back to it? This
assumes the system is stable enough to do the copy and access the
keyboard. Another idea: start painting the OOPs from the top without
clearing, hope useful userspace data is at the bottom?
Nicolas Mailhot: Don't forget about power management, unblank the
screen and don't let it blank again since you may not get it back.
Graphics mode lets more OOPs info fit.

12) interrupt time printk - certain hardware implements
non-interruptible operations. Most modern hardware does not do this.
For older hardware these non-interruptible operations will need to be
wrapped by the device driver. The complete data needed to finish the
operation will be provided in the IOCTL. Doing this enables an
interrupt time printk to call into the driver, make sure the hardware
is free by completing the pending operation, and then write to the
framebuffer. No older hardware currently implements this protection;
without this protection there is potential for locking the machine.

13) all of the features being discussed are implemented by a single
device driver plus a supporting set of library drivers. Multitasking of
multiple controlling device drivers for a single piece of hardware is
not allowed.

14) A new framebuffer memory manager is needed for mesa GL support. Ian
is working on it. The memory manager will be part of the support
library driver code. 

15) Over time user space console will be moved to a model where VT's
are implemented in user space. This allows user space console access to
fully accelerated drawing libraries. This might allow removal of all of
the tty/vc layer code avoiding the need to fix it for SMP.

16) accelerated, kernel based console drivers are not easily written in
this model. The only in kernel operations are simple ones like
CR/scroll, clear, print text. It is possible to call existing DRM entry
points from a kernel thread, but the code needed is complex. Note that
only things like printk use this console so is there a real need for
acceleration?

17) A user space console implementation also makes supporting multiple
users on multiple heads/card easier. The kernel will not need to be
modified for multi-user VT support. User mode console allows pretty
text and Asian scripts.

18) A coordinated system for grouping console devices needs to be
designed. This will be bad if each distro does it differently. One
proposal is to use udev to create: /console/1/mouse,
/console/1/keyboard, /console/1/usb_hub, /console/2/mouse,
/console/3/keyboard, /console/4/usb_hub, etc.
Alan Cox: Another is to use namespace mounts

19) SAK - secure attention key. We forgot to talk about this so we need
a design.
Alan Cox: Falls straight out of having the kernel + helper mode setting

20) A PAM login would assign ownership of the console group devices to
the logged in user. A mechanism needs to be designed for assigning
ownership of secondary heads for the merged fb case. X should run as
the logged in user and not require root if the hardware allows.

21) It was also discussed the X should stop implementing OS level
features and instead use the features of the underlying OS. If the
underlying OS is lacking support the support would be implemented in a
library external to X. Examples of moving from X to OS support include:
PCI bus, input, console groupings, etc.

22) A goal this design is to discourage user space video driver
implementations when a kernel one exists. An example of this would be
X's radeon XAA driver. X would instead use the DRM driver via mesa.

23) The old schemes are not going to be removed. If your ancient 2D
card only has an fbdev and XAA driver it will still work. We're not
going to remove old drivers if new ones don't exist. But don't expect
the composting X server to turn your clunker 2D card in to a Radeon
X800.












=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


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

Re: [RFC] Video Mode Handling

[Andrew Morton]

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

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?


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

Re: Re: [RFC] Video Mode Handling

[Geert Uytterhoeven]

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.

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

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: [RFC] Video Mode Handling

[Antonino A. Daplas]

On Monday 09 August 2004 11:50, Jon Smirl wrote:
> There was a lot of discussion about mode handling at OLS. Here's some
> of the lwn coverage...
>
> http://lwn.net/Articles/94202/
> http://lwn.net/Articles/94763/
>


> I'll attach a list of points discussed. Mode setting needs to cover
> multihead cards, and devices that only use the BIOS for mode setting.
> There also needs to be coordinated memory management when multiple
> heads are involved. Point 7 talks about a design where most of the mode
> setting code is moved to user space via hotplug.
>
> Can your design be adjusted to work in the framework outlined below?
>

Sure, if I correctly understand the pertinent parts of the discussion,
they mostly pertain to moving mode handling to userspace.  The patches
that I submitted are just that, move more of the mode handling away from
the kernel and let userspace determine the numbers to give to the kernel.
The job of the driver is to de-normalize the numbers, and write them to the
registers.

Currently, the main problem is "are the values coming from userspace safe to
use?" The fbdev drivers have a check_var() that does the verification.
However the function is severely limited because not all details are known
about the hardware and the display/s.  Drivers take different approaches,
accept everything as gospel truth, be paranoid and reject everything, or
check the numbers to varying degrees of effectivity (by using EDID, kernel
boot options, etc).

I guess most people will agree that writing to the hardware belongs in the
kernel, while choosing the correct values to write belongs to userspace.  The
unanswered question is the middle part, who does the verification?

As for hardware that depends on the BIOS for mode setting, this is basically
unsupported in the current fbdev framework (vesafb).  Either we allow BIOS
code to run in the kernel (search for vesafb-tng) or run BIOS code in
userspace (search for vm86d, vesafbd). 

Multi-head cards can be configured as multiple fb_info's sharing a single par
if each output is independent from the other (in which case each head has
its own private mode list) or a single fb_info with multiple pars if each
output are dependent on each other (in which case they share a common
mode list which are filtered so all entries will work for all heads).

As for memory management, yes, that's needed.  The i810fb for example explicitly
avoids the framebuffer address that is used by X/DRI.  It's also fortunate that
the i810 hardware has 2 ringbuffers, one is used by X/DRI, one by i810fb.  Add
another application that needs the ringbuffers, and the hardware will definitely
crash.

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

Re: Re: [RFC] Video Mode Handling

[Antonino A. Daplas]

On Monday 09 August 2004 14:04, 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?

Each var is approx 140 bytes multiplied by the number of consoles, which
is 64. James is in the embedded systems market, so I can see his point.

>
> And how much simpler would the code be if we were to bring back the
> per-display var structures?

The switching code will be much simpler.  All that needs to be done is
grab display->var and pass it to fbdev.  However, the stty/resize route still needs
to be addressed. 

>
> IOW: what's the tradeoff here?

Absence of a per-display var or similar mechanism is simply unacceptable.
Without it, mode setting is basically a mess.  It's possible that by simply
switching consoles you can be left with a corrupt display.

With  the per-display var, console switching is a breeze.  No need for mode
verification or creation.  The downside is the increased memory footprint.

The stty/fbcon_resize path is the other problem.  This is a request coming
from the upper layer (which has no knowledge whatsoever about graphics/
video) asking fbdev to change the video mode of the hardware.  Drivers can
'guess', but not all drivers are good at that, or get the mode from a known,
working modelist (which the 1st and 2nd patch addresses).  A simple solution
is to just remove stty/fbcon_resize support. But James might disagree.

BTW:  The series of patches addresses all of the above.  It can save the
settings per display, but with only half the memory requirement of a per-display
var, and makes the stty/fbcon_resize path work correctly.  It also eliminates 
the need for a static mode database as well.  The downside is increased code
complexity.

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

Re: Re: [RFC] Video Mode Handling

[Andrew Morton]

Geert Uytterhoeven <geert@linux-m68k.org> 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.

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

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

Re: Re: [RFC] Video Mode Handling

[Geert Uytterhoeven]

On Mon, 9 Aug 2004, Antonino A. Daplas wrote:
> On Monday 09 August 2004 14:04, 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?
>
> Each var is approx 140 bytes multiplied by the number of consoles, which
> is 64. James is in the embedded systems market, so I can see his point.

IMHO embedded is much better off with configuring MAX_NR_CONSOLES to a smaller
value, or disabling virtual consoles completely.

Even on desktop systems, most people don't need more than 8 VCs.

> BTW:  The series of patches addresses all of the above.  It can save the
> settings per display, but with only half the memory requirement of a per-display

But it doesn't save the full var, which may cause subtle differences.

BTW, if size matters, you can save the full var without the reserved fields.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Re: [RFC] Video Mode Handling

[Geert Uytterhoeven]

On Mon, 9 Aug 2004, Andrew Morton wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> 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.
>
> Sorry, that's way outside my area of knowledge ;)

Each driver needs a list of supported video modes.

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

Sorry, struct fb_var_screeninfo.

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

I agree!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


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

Re: Re: [RFC] Video Mode Handling

[Antonino A. Daplas]

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

Re: Re: [RFC] Video Mode Handling

[Antonino A. Daplas]

On Monday 09 August 2004 16:03, Andrew Morton wrote:

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

The simplest code is adding per-display var and removing stty/resize support.
If stty/resize support is needed, then we need a per-driver mode database.
Using fb_find_mode() + default modedb is no guarantee.

Best to wait for the other developers to respond.

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

Re: [RFC] Video Mode Handling

[Jon Smirl]

--- "Antonino A. Daplas" <adaplas@hotpop.com> wrote:
> I guess most people will agree that writing to the hardware belongs
> in the kernel, while choosing the correct values to write belongs to
> userspace.  The unanswered question is the middle part, who does the
> verification?

At OLS we talk about a system like this:
1) user owns graphics devices
2) user sets mode with string (or similar) format using ioctl common to
all drivers.
3) driver is locked to prevent multiple mode sets
4) common code takes this string and does a hotplug event with it.
5) hotplug event runs root context in user space 
6) mode is decoded and verified, this may involve a little process that
maintains the DDC database and reads a file of legal modes. Other
schemes are possible.
7a) mode is set using VBIOS and vm86, signal driver mode is set
7b) the register values needed to set the mode are passed into a root
priv ioctl.
8) driver is unlocked.

In this model all of the verification happens in user space. If you
want to set modes other than the ones from DDC you have to add them to
the config file. There is no need for DDC support and mode verification
in the kernel.

To give credit this is Alan Cox's design.

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


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