> 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 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
