Re: 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.
 

quoted

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