Revision as of 19:52, 12 August 2008

Kernel Modesetting and Memory Management

Summary

Currently, most graphics modes are initialized during the X server startup. Kernel Modesetting (referred to as KMS hereafter) moves this process from the X server's DDX drivers to the kernel, and it enables several new features including:

Improved Graphical Boot
Faster fast user switching
Seamless X server switching
Graphical panic messages

Memory Management, while a separate feature in its own right, is included here because it is a requirement for Kernel Modesetting.

Owner

Name: DaveAirlie, AdamJackson

Current status

Targeted release: Fedora 10
Last updated: 2008-08-08
Percentage of completion: 35%

Detailed Description

With KMS, output setup services move from being the job of the 2D X driver, to being the job of a kernel driver. Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode. Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session.

With KMS, a simple default policy is loaded into the kernel for initial output setup, which means connected displays should go to their native resolution as early as possible. Graphical display services, like the X server and the new Plymouth boot manager, simply reuse the existing display settings if they match what is desired. This allows for a seamless transition between bootup and login screen. Fast user switching can also take advantage of this; if both users have the same screen resolutions, then there's no need to blink to transition, and even if they're different, the kernel can make the switch exactly once (instead of twice like before).

Finally, since the kernel is aware of which regions of video memory are being displayed, it can print panic messages to the display, which will assist with troubleshooting.

Benefit to Fedora

Graphical panic messages allow kernel developers to collect information about crashes and lockups that happen while graphics are active. Historically, this kind of bug was difficult to diagnose, because the panic message would effectively not be printed anywhere. While it was possible to collect this kind of crash data with network or serial consoles, it wasn't trivial for a user to set up.

The enhanced graphical startup and user switching experience makes Fedora feel more like a polished, professional product. It's eyecandy, but it's such delicious eyecandy!

Scope

KMS requires per-driver kernel support. The initial targets are ATI and Intel graphics chips, as sufficient documentation exists to implement kernel drivers for them. The design of the kernel's KMS API is still in flux, and interacts with any kernel video memory management subsystems that may be in play (GEM, TTM, etc.). Plymouth, and the corresponding 2D X drivers, also need to be updated to use the new KMS APIs when they are available.

Test Plan

KMS is highly hardware dependent. At least the following configurations need to be tested:

Intel 915/945
Intel 965 and above
Intel 865 and below
Radeon R500 and above (ie, ATOM BIOS enabled)
Radeon R400 and below (ie, not ATOM)
Everything else

Plymouth testing is expected to be described on Features/BetterStartup. For each of the above configurations, plymouth should do the expected thing, whatever that is: either graphical splash if KMS support lands for that hardware profile, or text splash if not.

For each configuration, X startup and shutdown needs to work as expected, both when plymouth is enabled and when it is disabled. Additionally, fast user switching must be tested and working.

Graphical panic support will likely get tested "for free", since it's hard not to accidentally panic at least once while developing the appropriate kernel code. However, manual testing can be achieved by starting X and then echo 1 > /proc/sys/kernel/panic as root.

User Experience

For KMS-enabled hardware, the user should spend much less time watching their monitor blink while the system starts up. Fast user switching will be faster and smoother, making Fedora more pleasant for non-technical and casual users.

Dependencies

Plymouth and the X server will both consume the KMS services provided by the kernel. Plymouth really does not want to be in the business of having multiple drivers, so a consistent API between kernel drivers is desirable.

Contingency Plan

If kernel modesetting is not present, user modesetting is performed by the appropriate X server DDX driver as in past releases.

Documentation

Release Notes

Probably. If it's possible to disable KMS support for a DRM driver, that information should go here.

@@ Line 2: / Line 2: @@
 == Summary ==
-Currently, most graphics modes are initialized during the X server startup.  Kernel Modesetting moves this process from the X server's DDX drivers to the kernel, and it enables several new features including:
+Currently, most graphics modes are initialized during the X server startup.  Kernel Modesetting (referred to as KMS hereafter) moves this process from the X server's DDX drivers to the kernel, and it enables several new features including:
 * [[Features/BetterStartup|Improved Graphical Boot]]
-* Fast user switching
+* Faster fast user switching
 * Seamless X server switching
-* Multiple simultaneous X servers
+* Graphical panic messages
-* ...
 Memory Management, while a separate feature in its own right, is included here because it is a requirement for Kernel Modesetting.
 == Owner ==
 * Name: DaveAirlie, AdamJackson
 == Current status ==
 * Targeted release: Fedora 10
 * Last updated: 2008-08-08
-* Percentage of completion: XX%
+* Percentage of completion: 35%
 == Detailed Description ==
-<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
+With KMS, output setup services move from being the job of the 2D X driver, to being the job of a kernel driver.  Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode.  Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session.
+With KMS, a simple default policy is loaded into the kernel for initial output setup, which means connected displays should go to their native resolution as early as possible.  Graphical display services, like the X server and the new Plymouth boot manager, simply reuse the existing display settings if they match what is desired.  This allows for a seamless transition between bootup and login screen.  Fast user switching can also take advantage of this; if both users have the same screen resolutions, then there's no need to blink to transition, and even if they're different, the kernel can make the switch exactly once (instead of twice like before).
+Finally, since the kernel is aware of which regions of video memory are being displayed, it can print panic messages to the display, which will assist with troubleshooting.
 == Benefit to Fedora ==
-<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
+Graphical panic messages allow kernel developers to collect information about crashes and lockups that happen while graphics are active.  Historically, this kind of bug was difficult to diagnose, because the panic message would effectively not be printed anywhere.  While it was possible to collect this kind of crash data with network or serial consoles, it wasn't trivial for a user to set up.
+The enhanced graphical startup and user switching experience makes Fedora feel more like a polished, professional product.  It's eyecandy, but it's such delicious eyecandy!
 == Scope ==
-<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? -->
+KMS requires per-driver kernel support.  The initial targets are ATI and Intel graphics chips, as sufficient documentation exists to implement kernel drivers for them.  The design of the kernel's KMS API is still in flux, and interacts with any kernel video memory management subsystems that may be in play (GEM, TTM, etc.).  Plymouth, and the corresponding 2D X drivers, also need to be updated to use the new KMS APIs when they are available.
 == Test Plan ==
@@ Line 41: / Line 53: @@
 -->
+KMS is highly hardware dependent.  At least the following configurations need to be tested:
+* Intel 915/945
+* Intel 965 and above
+* Intel 865 and below
+* Radeon R500 and above (ie, ATOM BIOS enabled)
+* Radeon R400 and below (ie, not ATOM)
+* Everything else
+Plymouth testing is expected to be described on [[Features/BetterStartup]].  For each of the above configurations, plymouth should do the expected thing, whatever that is: either graphical splash if KMS support lands for that hardware profile, or text splash if not.
+For each configuration, X startup and shutdown needs to work as expected, both when plymouth is enabled and when it is disabled.  Additionally, fast user switching must be tested and working.
+Graphical panic support will likely get tested "for free", since it's hard not to accidentally panic at least once while developing the appropriate kernel code.  However, manual testing can be achieved by starting X and then <code>echo 1 &gt; /proc/sys/kernel/panic</code> as root.
 == User Experience ==
-<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
+For KMS-enabled hardware, the user should spend much less time watching their monitor blink while the system starts up.  Fast user switching will be faster and smoother, making Fedora more pleasant for non-technical and casual users.
 == Dependencies ==
-<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this feature depends?  In other words, completion of another feature owned by someone else?  Other upstream projects like the kernel (if this is not a kernel feature)? -->
+Plymouth and the X server will both consume the KMS services provided by the kernel.  Plymouth really does not want to be in the business of having multiple drivers, so a consistent API between kernel drivers is desirable.
 == Contingency Plan ==
 If kernel modesetting is not present, user modesetting is performed by the appropriate X server DDX driver as in past releases.
 == Documentation ==
 Related links:
 * http://kerneltrap.org/node/8242
 == Release Notes ==
-<!-- The Fedora Release Notes inform end-users how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
+Probably.  If it's possible to disable KMS support for a DRM driver, that information should go here.
 ----
-[[Category:FeaturePageIncomplete]]
+[[Category:FeatureReadyForWrangler]]
 <!-- When your feature page is completed and ready for review -->
 <!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
 <!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
 <!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Search

Features/KernelModesetting: Difference between revisions