Sharpening the Intel Driver
Apr 27, 2009, 10:02 (4 Talkback[s])
(Other stories by Keith Packard)
WEBINAR:
On-Demand
Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers
"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:
