[ Apologies for the broad cross-post; I'd like to reach anyone potentially interested ]
First of all, it should be fairly obvious to anyone that ideally only a 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'd also like to comment on some points I noticed in the ksummit-2004-discuss archives: In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000388.html, Jim Gettys wrote: > In short, the X server would put a sequence of commands into a piece > of memory also visible by the graphics card, set up the DMA > transfer, tell it to go, and then continue setting up a second buffer, > and call into the UNIX kernel with the transfer address of the > second buffer, that transfer to be initiated at interrupt time > when the first buffer's commands had been processed; this then blocked > the X server, so it had good "interactive" behavior under many > circumstances. > > It may be that system calls are now cheap enough to do this rather than > having to do it in user space [...] Yes, that's basically what the r128 and radeon X drivers do when the DRI is enabled, and it's considerably faster than direct register banging. In http://thunk.org/pipermail/ksummit-2004-discuss/2004-May/000391.html, Jon Smirl wrote: > The modelines would be passed into the plug-in libs which would turn them into > 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? -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- 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