Sharpening the Intel Driver

"For the last year or so, we've been busy rebuilding the driver, adding new ways of managing memory, setting modes and communicating between user space and the kernel. Because all of these changes cross multiple projects (X/Mesa/Linux), we've tried to make sure we supported all of the possible combinations. Let's see what options we've got:

"Mode Setting
User mode. The entire output side of the driver stack is in user mode; all of the output detection, monitor detection, EDID parsing etc. This has some significant limitations, the worst of which is that the kernel has no idea what's going on, so you cannot show any kernel messages unless the X server relinquishes control of the display. In particular, panic messages are lost to the user. If the X server crashes, the user gets to reboot the machine. A more subtle limitation is that the driver couldn't handle interrupts, so there wasn't any hot-plug monitor support. That's becoming increasingly important as people want hot-plug projector support, and as systems start including DisplayPort, which requires driver intervention when the video cable gets kicked out of the machine.

"Kernel mode. All of that code moves into the kernel, where it is exposed both as a part of the DRI interface and also through the frame buffer APIs for use by the fb console or any other frame buffer applications. Lots of benefits here, but the development environment is entirely different from user mode, and so porting the code is a fair bit of work. Dave Airlie has some pie-in-the-sky ideas about making the kernel mode setting code run in user mode by recompiling it with suitable user-mode emulation of the necessary kernel APIs."

Complete Story

Related Stories:

• Intel Drops A Load Of G45 Programming Documentation(Apr 16, 2009)
• RandR 1.3 Explained, Demonstrated (Video)(Feb 09, 2009)
• Intel UXA Acceleration Performance(Dec 29, 2008)
• Intel GMA X4500HD Review(Jul 31, 2008)