Sponsors

Platinum Sponsors

  • Intel
  • IBM

Gold Sponsors

  • NetApp

Silver Sponsors

  • HP
  • Google
  • MontaVista
  • Sandisk

Collaborators

  • Portland State University
  • Linux Foundation

Press Partners

  • Linux Journal
  • Linux Weekly News
  • Linux Pro Magazine

Sponsorship opportunities

For more information on sponsorship opportunities, please contact Angela Brown. Linux Plumbers Conf sponsorship packages.

Graphics Drivers in the Kernel : 20 years late. - Dave Airlie & Jesse Barnes

Biography

Dave Airlie is a Snr Software Engineer in the Red Hat Desktop team working on X.org and kernel graphics. He has maintained the kernel drm layer since the last maintainers turned to harder substances, and hopes someday it will be a useful member of the community.

Jesse Barnes is a Linux developer at Intel's Open Source Technology Center. His attention is split between maintaining the PCI layer for the Linux kernel, fixing graphics driver bugs, and developing features for X.Org, Mesa, the kernel DRM layer, and the Intel X driver. In his spare time he works on new platform bring up and platform architecture with Intel's chipset & CPU groups.

Abstract

So back in the hazy dark days when there was lots of i386 UNIXes and nobody wanted to write kernel drivers, XFree86 started the trend of putting all the graphics drivers into userspace. Other non-x86 UNIXes kept going with putting GPU drivers into the kernel. Linux continued on (un?)happily for many years with this model, until a lot of the problems with having drivers in userspace became apparent.

  • Suspend/resume really wants a kernel driver that knows the complete state of the hardware. Doing a VT switch to text mode and praying the BIOS could resume the hardware isn't winning (too slow, doesn't always work..)
  • Multiple drivers for the same piece of hardware. To workaround the lack of text mode on non-x86 hw, fbdev was born. x86 people wanted nice graphics with out X, fbdev drivers came to x86 also. Direct rendering for 3D cards showed the need to have a kernel driver, so the drm was created. Having all these bits banging on the hardware in their own way was a recipie for disaster. Also having a kernel driver controlled from userspace like the drm was a real main to maintain.
  • boot up flickering and oops displaying. OMG my eyes, VT switch, flicker, MacOSX doesn't do this, you suck etc. We can't see an oops, so instead of a BSOD we get a dead X.
  • Doing graphics without X. One of the hardest things about replacing X is that you need to have drivers for all the myriad versions of GPUS as X includes the drivers. Moving this code to one place in the kernel will make future replacements for X a lot easier job.

So this talk discusses the hows of kernel modesetting, what pieces of the drivers are being moved into the kernel, the APIs being exposed to allow this, and some discussion on the future directions for Linux graphics once we have the drivers available in the kernel.