Re: [Linux-fbdev-devel] Current discussion about the future of free software graphics

> single kernel driver should muck with the hardware directly. However,
> I'd like to point out again that it doesn't follow that the DRM and the
> framebuffer device must merge to a single entity (which 'has to be' the
> DRM if you ask some people, the framebuffer device if you ask
> others...). E.g., they could both use the same mini-driver which deals
> with the hardware. Let's try and keep our minds open to all possible
> solutions.

I agree. The disagreement is about where to put mode setting.
 
> > register values. Finally the plug-in lib would use a private IOCTL to set the
> > state into the video hardware. 
> > 
> > There are numerous pros and cons for both a both schemes. The user space code is
> > swappable, easier to debug, and does not need to be run as root.
> 
> It does, or the ioctl must verify the register data, which could require
> about the same amount of code as computing it in the kernel in the first
> place (possibly even more; the problem changes from computing a valid
> combination of register values for a specific requested mode to limiting
> the huge number of register value combinations to those that don't lock
> up the chip or worse). I've pointed this out several times before, but
> nobody has presented a solution yet. Will the userspace code live in a
> daemon that runs as root? Or will only privileged processes be allowed
> to change display properties?

So in reality having mode switching would be just as expensive in 
userspace as having it in the kernel? 




-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3