specs/KernelKarmicKMS

KernelKarmicKMS

Revision 3 as of 2009-05-15 19:33:11

Launchpad Entry: kernel-karmic-kms
Created:
Contributors:
Packages affected:

Summary

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.

Rationale

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:

better security -- keeping control of the display hardware in the kernel can only improve security
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
suspend/resume improvements -- suspend/resume should both be more reliable and quicker as the kernel can directly reinstate the graphics mode
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)
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:

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
Even limited support for KMS on limited hardware would be beneficial to making progress on this even should KMS userspace not make Karmic.

Assumptions

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.

Implementation

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:

```
CONFIG_DRM_I915_KMS
```

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.

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
- 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

CategorySpec

Ubuntu Wiki