Folks -
In yesterday's discussion about the future of SaX2 it has been requested
that changes that will affect users in the future are communicated to
the openSUSE community early. KMS (kernel mode setting) integration would
be such a feature, thus I would like to announce this here and
one step further dive into a technical discussion about a possible
solution.
Furthermore test packages are available to try things out on Factory.
I would like to encourage people interested in development and technical
discussions in general to participate in the discussion and the development
efforts.
Kernel Modesetting (KMS)
========================
All of you who are using a graphical desktop on Linux have been using
the X Window Sytem.
The X Window System Server (XServer) is the instance which receives
requests from your desktop applications to draw all the widgets (windows,
buttons, images etc.) you see on your desktop. It also processes input
from your keyboard and mouse and sends them to applications as events.
Traditionally on Linux the XServer does not only draw images to the screen
(ie writes them to some sort of frame buffer) but it is in charge of
initializing, setting up and driving the graphics hardware.
This paradigm which has been true since the X Window System has been
ported to Linux is about to change: Much of the initialization, set up
(video mode setting) and control of the graphics hardware is about to
move to the Linux kernel.
There are a number of advantages to this:
- A central instance is in charge of the graphics hardware, other
user mode applications (not just the Xserver) can take advantage of mode
setting.
- The Xserver will no longer require full root privileges as it doesn't
talk to the hardware directly any more.
- Faster boot process: The Xserver doesn't need to (re)initialize the graphics
hardware any more, this is all done by the kernel very early in the boot
cycle.
- Smoother (flicker free) boot experience: The screen doesn't flicker and
changes resolution any more when the Xserver starts.
- One central entity is in charge and manages the resources of the graphics
hardware - like the video memory which makes sharing of these resources
between several applications (like Xserver and several DRI (Direct Rendering
3D) applications much easier.
KMS is integrated in the DRM drivers.
In the near future most graphics driver will switch to KMS:
- Intel already ships a fully working KMS driver. Future Intel chipsets will
be supported by the KMS driver only.
- KMS in the Radeon DRM driver is still work in progress but it is already
working well on some chipsets.
- Noveau is relying heavily on KMS for their free 3D driver for NVIDIA
chipsets.
The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the
near future.
Integration in openSUSE
=======================
Now this begs the question what we have to do to integrate it into openSUSE.
Originall I had plans to look into this for openSUSE 11.2 already - but then
I got side tracked by other stuff it fell on the floor and noone else beat me
to it either ... oh well.
Now I had the chance to play around with KMS a little and came up with some
ideas and a proof of concept.
It turned out that the changes to openSUSE needed to fully support KMS are
quite small. Key is to load the KMS aware DRM driver as early as possible in
the boot process to avoid video mode changes later in the boot cycle -
preferrably in the initrd.
The Boot Process
----------------
On openSUSE the boot loader is configured for two boot scenarios: default
and failsafe. The user can select the failsafe boot scenario in case the
default scenario does not work for him. In the failsafe scenario certain
features are deactivated which have shown to cause problems on some systems.
Since KMS is a new feature it is a candidate for deactivation during a
failsafe boot. Instead the system should then boot into the VESA framebuffer
mode. Should this also fail the kernel will automatically fall back to a VGA
text mode.
To disable KMS on boot a new boot parameter is introduced: 'nomodeset'.
This parameter is to the boot command line for the failsafe mode.
The user may add this parameter by hand for any other boot mode.
The kernel command line is parsed in initrd and an appropriate
entry is created in /etc/modprobe.d/options. Furthermore the graphics
driver module and - if required - the agp module(s) are added in the
correct order (agp modules first) to the list of modules to be loaded
initially.
Changes to individual packages
==============================
1. yast2-bootloader & perl-Bootloader
-------------------------------------
The boot parameter 'nomodeset' is added to the failsafe boot
paramter lists in each of the modules. (I have not been able
to find out which module provides the entry relevant for which
situation, therefore I've whacked both.)
yast2-bootloader updates the variable FAILSAFE_APPEND in
/etc/sysconfig/bootloader appropriately.
2. kernel-source
----------------
To use KMS for a certain DRM driver the kernel config option
CONFIG_DRM_