Currently control over display hardware is handed off directly to the X server. This means exporting direct access to the graphics hardware to userspace. This has the effect of making the kernel dependant on userspace to be working and active to change the display mode including switching virtual terminals. It also increases risk by exporting that hardware to unpriviledged zones.

The Kernel Mode Setting (KMS) work is driving the management and control of basic video modes out of userspace (out of the X server) and back into the kernel. This allows the kernel to take firmer control over the display, enabling it to switch virtual terminals without userspace intervention. It will also enable critial kernel messages to reach the user regardless of the display mode. Improving reliability and performance of graphics mode changes.

This specification is designed to track the implementation plan for KMS in the Ubuntu kernel.

Release Note

Something like this as a basis:

  • Kernel Mode Setting (KMS) has been enabled for the Karmic Kernel.
    This brings improved graphics handling, cleaner less flickery boot, and
    faster and more reliable suspend resume to those chipsets supporting KMS.
    For Karmic the Intel chipsets supported by the i915 driver will have
    KMS enabled.


We would like to see Kernel Mode Setting enabled in the kernel for Karmic as this will allow foundations to begin integration and testing of the userspace components required to make use of KMS. KMS is beneficial directly for the kernel for a number of reasons:

  1. better security -- keeping control of the display hardware in the kernel can only improve security
  2. better panic support -- with the display controlled by the kernel we are then able to switch to a text mode and display critical error messages even when the X server has crashed
  3. suspend/resume improvements -- suspend/resume should both be more reliable and quicker as the kernel can directly reinstate the graphics mode
  4. improved mode switching -- with KMS the kernel directly controls switching between virtual terminals improving performance and reliability (the chvt interface is no longer racy, failures of which leads to a number of suspend/resume failures)
  5. composited 3d applications will work -- compositing a 3d application currently simply does not work, KMS is part of the framework to fix this

We should also note that:

  1. KMS is a direct pre-requisite for the use of the plymouth boot splash which is a primary plank of the plans for improving the boot experience
  2. Even limited support for KMS on limited hardware would be beneficial to making progress on this even should KMS userspace not make Karmic.


We are assuming that userspace will be enhanced to make use of KMS either for Karmic or LL. Specifically this has interactions with the boot splash program (Plymouth), the X server, and mesa at a minimum. Updated versions would be needed to make proper use of this support.


We are planning on evaluating each of the KMS enabled drivers which are present in the Karmic kernel at Alpha 6. At this point we will enable KMS by default for those drivers which are deemed stable enough. We will plan to have a blacklisting mechanism to allow us to then disable support for chipsets which show issues within a particular driver; this is very likely going to have to be kernel side.

Intel i915

Implementing KMS in the kernel is a simple [sic] matter of enabling KMS for the graphics drivers which we aim to support. As of kernel v2.6.30-rc5 only the Intel i915 driver has support for KMS.

Specifically we would need to enable:


By default we plan to compile in this support but not to enable it. This will allow the consumers of this functionality to turn it on when they are ready for chipsets deemed reliable enough.

We will want to back out the 'default off' patch as current committed to the Karmic Kernel.

ATI Radeon

We are expecting to see ATI Radeon support hitting the kernel in the 2.6.31 merge window. We will need to enable:



We are not currently expecting Nouveau support to his the kernel in time for the Karmic kernel.

Early Testing

The ATI support is not likely to hit the tree before the 2.6.31 merge window. The Nouveau support is not likley to hit 2.6.31 at all. In order to get testing time on these, and to allow the X userspace to test their bits we are going to try and produce test kernels for Karmic including the ATI and Nouveau KMS branches. These will be offered via the x-edgers PPA. We are also looking at producing a bootable USB image containing these parts ready installed to allow touch testing without updating your system either to Karmic, nor to the x-edgers PPA contents.

Unresolved issues

Currently only the Intel i915 driver supports KMS. ATI and Nouveau patch kits are in progress but may not make the final Karmic kernel. Binary drivers especially the Nvidia ones may never support it. A lot of this support is likely to be very fresh when we release and may not be stable. The generic KMS support is relativly untested.

BoF agenda and discussion

  • Why do we care about KMS
    • KMS is clearly the way that the kernel is going overall
      • the more testing it gets now the more reliable it will be when it is used in anger
    • It improves our ability to get crash information
    • It improves the reliability and performance of suspend/resume
    • It improves VT switching performance and reliability
    • It reduces mode switching and thereby reduces flicker during boot
  • What are we planning
    • to build KMS for all enabled hardware assuming its reliable enough
    • to disable KMS at runtime by default
      • this allows us to opt-in drivers as we see fit
      • potentially enabling KMS for say tested cards only for a driver
  • Where are we right now
    • We have already enabled KMS for the Intel i915 driver
  • Whats coming
    • There is a lot of work going on on KMS in general
      • so expect buckets of patches, and problems
    • ATI support is the most advanced, expected to hit the kernel in .31
      • this is already being ported to and shipped with rawhide kernels
      • expected to be experimental in .31, stable in .32
    • Nouveau support is moving quickly along, but is not expected to hit till after .31
  • Issues if we stick at 2.6.30
    • ATI support very likely will not make it
    • Nouveau support will not make it
  • Issues if we stick at 2.6.31
    • ATI support will be very new
    • Nouveau support very likely will not make it
  • Binary drivers
    • we are not expecting binary drivers to support KMS any time soon
      • certainly the word on the street is that it is impossible for Nvidia binary drivers to interface with this
      • more a problem for userspace as they need to support KMS and non-KMS graphics
  • Considerations:
    • are we going to consider picking up support as patches for Karmic?
    • what will our criteria be to decide that this feature should be enabled for a driver
      • might we enable for some tested cards and not all cards supported by a drver
      • this is regardless of whether we have support for a driver natively or via patch
      • how do we determine if support is stable enough to recommend enabling
      • what is the ramifications of it not being enabled
        • we assume here that support for non-KMS is a userspace requirement

Summary of Discussion

The discussion centred primarily around what we would be able to support. This was deemed to be mostly dependant on what would be merged and released in time for the 2.6.31 release. Intel should be there, ATI may be there, and Nouveau will likely not be. It was stated that we should try and enable this as much as possible as it is a strong feature differentiator for Ubuntu if it is enabled.

The plan is to help with testing as much as possible to help get the kernel and userspace stack working as well as possible. To this end we will enable as much of this support as possible by default. We would then take a decision at the Alpha-6 milestone on what is likely supportable and what is not and use that to finalise the enabled support for the release.

To aid testing we would get the QA Team (Leann specificially) to put out a call for testing of this functionality. Additionally the kernel team will attempt to pull back the ATI and perhaps Nouveau support into test kernels to allow early adopters to test those branches too. It was suggested some kind of bootable image with these kernels and the x-edgers bits would be a good way to test this functionality.

It was noted that debugging this would be difficult as it spans the whole stack. As these are most likley to be reported as X bugs regardless of failing layer the X triage team will be reasssigning them to the Kernel team as they find them. We will need to ensure the X triage documentation has the required tips to make that occur. It is also likely we will need more information such as dmidecode inforamtion which may not yet be available in apport-collect; this needs investigation.


specs/KernelKarmicKMS (last edited 2009-08-18 10:12:10 by ogiannhs)