News, tips, partners, and perspectives for the Oracle Solaris operating system

Moving x86 video drivers into the kernel

Alan Coopersmith
Senior Principal Software Engineer

Since Keith's recent talk on X at linux.conf.au, I've been asked a few times and seen discussion elsewhere (such as in the comments on the linked article) what Sun thinks about moving various portions of the Xorg video drivers from the current userspace shared objects into true kernel drivers, as most people assume this means Linux kernel drivers and reducing the portability of Xorg to non-Linux platforms such as Solaris/OpenSolaris and the BSD's.

While I'm of course too far down the food chain to claim to speak officially for Sun, as the lead engineer for the Xorg integration to Solaris and someone who has talked to a number of the other Solaris engineers about it, I'd say the Solaris engineering teams agree having in-kernel drivers for video cards is something we want and need.

On Solaris, we've long had in kernel graphics drivers for all our SPARC frame buffers, since that was a small and controlled set, and writing the driver for it was simply part of the cost of producing the card. On the x86 side though, we had for years the same model as most other x86 Unix-like OS'es - a generic set of kernel modules, and all device-specific logic in the X server. The Solaris x86 kernel modules were vgatext and xsvc. vgatext provides the text console, using standard/ancient VGA interfaces which virtually all PC graphics boards support. xsvc (which was closed source due to legal encumberances, but has recently been replaced with a newly written open source version by the Solaris Xen project team) provides the mappings to the PCI bus that allow Xorg to probe the bus hardware to find devices, and then map in the video card once it's found.

Recently, new kernel modules have started appearing in Solaris - the first two for 3-D rendering acceleration, nvidia's driver and the DRI driver for Intel graphics. Two more are coming soon from the Suspend-and-Resume project, to provide the hooks to save and restore necessary state across system suspends - they'll initially support the ATI Rage XL from the Sun Ultra 20 and ATI ES-1000 in the Ultra 20 M2. (Dave and Jay gave a talk on their implementation at last years' X Developer's Conference.)

Additionally, our security guys have been pushing for more kernel frame buffer drivers to reduce our need for running Xorg as root. They'd also like to find a way to close the now infamous Ring 0 security weakness. (We've invited them to drop in to this week's X.Org Developer's Conference to talk about this - they're planning to show up Thursday morning for the Secure X talk, so we may try to have a breakout session on this topic at that time to discuss this.)

Now, we still can't write drivers ourselves for every x86 video card on the market, which is one of the big reasons we chose to move from Xsun to Xorg on Solaris, so we'd still prefer if a model could be found that allowed sharing drivers between Solaris, Linux, and BSD (which means agreeing on both licensing and interfaces with the kernel), similar to what we already have in DRI. If we can work out a model like that, then I think Sun would support it - either way, we're going to have to have more graphics driver functionality in the kernel, and sharing would be better than going our own way.

Join the discussion

Comments ( 2 )
  • Patrick Georgi Monday, February 5, 2007

    A common video driver framework was once attempted by kgi. some brave soul ported it to freebsd relatively recently and enabled it to be truly OS independent.

    Unfortunately, those 3 letters will very likely spark some flamewars on several lists, but maybe its design or parts thereof could be adapted in whatever succeeds it?

  • Patrick Georgi Wednesday, February 14, 2007

    The problem with such an interface is that those cards are too different.

    Some might provide a fillrect(x1,y1,x2,y2,rgba,rgba_border,border_width) function, others might only have a
    fillrect that fills rgb without borders - but they could provide a different way to get the same result in a very fast way (eg. 2 rgba triangles and 4 rgba lines)

    Different cards might want to get the data in different data representations - converting everything in kernel (after it was probably converted in the X server on top already) will slow things down and won't improve security, to say the least.

    As for OpenGL, very few cards actually implement its state machine in hardware - most drivers do extensive optimizations on the data (that are sometimes specific to the way that card works) and management of state.

    As for state, a graphic context is a huge beast, esp if you include 3d. either that driver only provides support for a single client at a time, or it has to take care of that.

    For such reasons, KGI only provided resource management in the kernel module, and put the accelerated driver that makes use of that in a common graphic library (libggi). That way, the kernel module still stays relatively simple but specific to the card (so they could validate some critical data points) and the advanced driver logic stays in userspace, but separate from any specific application.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.