|Line 19:||Line 19:|
* Targeted release: Fedora 10
* Targeted release: Fedora 10
* Last updated: 2008-
* Last updated: 2008--
* Percentage of completion:
* Percentage of completion: %
Details: For AMD/ATI hardware, R300
Details: For AMD/ATI hardware, R300 KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so default to disabled (this targeted for Fedora 11). For Intel hardware, we default to disabled for .
== Detailed Description ==
== Detailed Description ==
Revision as of 19:12, 24 October 2008
Kernel Modesetting and Memory Management
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.
- Name: DaveAirlie, AdamJackson
- Targeted release: Fedora 10
- Last updated: 2008-10-24
- Percentage of completion: 100%
Details: The infrastructure is all in place. The driver details are as follows: For AMD/ATI hardware, R300 and newer has KMS enabled by default; R100-R200 does not yet have 3D support with KMS, so is default to disabled (this has been targeted for Fedora 11). For Intel hardware, we default to disabled (targeted for Fedora 11).
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!
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.
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.
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.
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.
Kernel modesetting can default to either enabled or disabled in the DRM driver, and it can be enabled or disabled at boot-time. Both Plymouth and the DDX drivers will detect whether KMS is present and enabled, and if both present and enabled, they will take advantage of them. If either KMS is not present or it is present but disabled, then Plymouth will automatically fall back to the text splash and the DDX driver will automatically fall back to user-space modesetting (as in past releases).
We will need to document how to enable/disable a driver at boot-time and will need to document any known bugs or performance issues.