Re: [RFC] Video Mode Handling

["Antonino A. Daplas" <adaplas@hotpop.com>]

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