[opensuse-factory] Kernel Mode Setting (KMS) for openSUSE.

3 Dec 2009

      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__KMS needs to be set to 'y'.
At the moment we will support KMS only for Intel hardware,
thus only the variable CONFIG_DRM_I915_KMS needs to be changed.

In the sample build this has been enabled for the -default,
-desktop, -pae, -debug, -trace and -vanilla kernels for the
i386 and x86_64 platforms.

The kernel boot splash has already been fixed for KMS for
openSUSE 11.2.

3. mkinitrd
-----------

This package writes the initrd file. To add KMS support to the initrd
mkinitrd needs to perform the following tasks:

1. Check the sysconfig variable NO_KMS_IN_INITRD, if set, don't attempt to
   install a KMS DRM capable driver.

2. Obtain a list of PCI devices installed on the system.

3. a. In the list of PCI devices identify those devices which are of class VGA
      and look for a matching driver.  b. Before a driver is matched check the
   PCI vendor, device, subvendor and
      subdevice ids against a blacklist in /etc/kms/blacklist should this file
      exist.  This file contains one vendor, device, subvendor and subdevice
      id per line, '*' serves as a wildchar, trailing wildchars may be
      ommitted, '#' at the beginning of a line serves as a comment.
   c. Use the standard modprobe alias mechanism to find a matching DRM driver
      module.  This way standard blacklistings of kernel modules will be
      honored and update modules will be searched if they are available.  KMS
      capable DRM drivers provide an alias list (in contrast to non-KMS
      capable DRM drivers which are to be loaded explicitely by the Xserver).
   d. If a driver is found check for a black listing in
      /etc/kms/.blacklist. The same rules as in 3 b. apply.

4. If a KMS capable DRM driver is found search for an agp driver:
   a. Obtain a list of all known agp drivers for the specific kernel
      and collect their alias lists.  
   b. Match all installed PCI devices against the alias lists of each 
      agp driver. If a match is found add the driver to the lists of modules
      to be loaded. Make sure that this driver is loaded prior the the DRM
      driver.

Two scripts setup-kms.sh and boot-kms.sh are added to mkinitrd.
The former performs the tasks listed above, the latter provides the
required module dependencies in the required order, parses the boot
command line for the 'nomodeset' option and adds the apropriate entry to
/etc/modprobe.d/options.
The linuxrc script is extended to search the boot command line for
<drivername>.<option>=* strings for each driver loaded in initrd and add
the <option>=* part to /etc/modprobe.d/options.

4. udev
-------

Udev loads any modules which are not loaded by linuxrc scripts directly.
It is possible to let udev load the required DRM and AGP modules provided
it is made sure that this happens in the correct order. Since there is
no explicit dependency of DRM modules to AGP drivers as there is no general
one to one match between the two drivers a udev rule must exist to enforce
the correct order for all cases where a AGP module is required.
This is true for Intel DRM drivers and any other driver for an AGP graphics
chip.
For this a rule file 79-waitfor-agp.rules is added which is run before
80-drivers.rules. It checks if either an Intel graphics (class VGA) device
is processed or if the graphics device is an AGP device. The latter condition
is tested by an auxiliary tool (is_agp) which is passed the kernel name of
the event device. If either condition is true udev will wait for /dev/agpgart
to appear before proceeding to load a DRM driver module.
'is_agp' checks the capabilities flags in the PCI config space of this device
for AGP.

The changes to udev are not strictly required to make KMS work, still they
augment the default module load process

Installation
============

Modified packages for Factory of
 - kernel-source,
 - mkinitrd,
 - yast2-bootloader, 
 - perl-Bootloader, 
 - mkinitrd
 - udev 
can be found in my build service home on OBS under home:eeich:Factory-KMS.
For installation add
http://download.opensuse.org/repositories/home://eeich://Factory-KMS/openSUS...
to your installation repository and update the packages in question (going
thru the usual vendor change hassle).

It is advisable to update mkinitrd before updating the kernel. Then when
the kernel is installed the modified mkinitrd will be used and all steps
required to install KMS will be performed.

TODO
====

- The kernel bootsplash sometimes produces wrong colors (WIP).  Add KMS
- Add KMS support to the RadeonHD driver.

Cheers,
	Egbert.

-- 
Egbert Eich (Res. & Dev.)                SUSE LINUX Products GmbH
X Window System Development
Tel: +49 911-740 53 0                       http://www.suse.de 
-----------------------------------------------------------------
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-factory+help@opensuse.org

Petr Baudis

Petr Baudis

Jakub 'Livio' Rusinek

Jakub 'Livio' Rusinek

Karsten König

Jakub 'Livio' Rusinek

tags

participants (18)