In association with heise online

17 January 2009, 07:36

Kernel Log: What's new in 2.6.29 - Part 3: Kernel controlled graphics modes

  • Twitter
  • Facebook
  • submit to slashdot
  • StumbleUpon
  • submit to reddit

With the release of 2.6.29-rc1 last weekend, Linus Torvalds concluded the first phase, called the merge window, of the development cycle. This phase allows for incorporating the substantial changes intended for the next kernel version into the source code management system of the Linux kernel. As a result, 2.6.29 is now in the second, stabilising phase, which usually takes eight to ten weeks and gives the kernel developers the opportunity to correct mistakes and make minor changes that are unlikely to cause further flaws. As major changes are only rarely discarded during the stabilising phase, the kernel log can already discuss the most important changes expected for 2.6.29 in the "What's new in 2.6.29" series.

Kernel-based mode setting

Almost 21 months after its first major announcement, the support for kernel-based mode setting (KMS) for recent Intel graphics hardware has been integrated into the main development branch of Linux (for example 1, 2, 3). This technology gives the kernel noticeably more control over the graphics hardware. When KMS is active, the kernel sets the graphics mode suitable for a monitor as soon as all the required hardware components (ACPI, PCI, graphics hardware etc.) have been initialised.

From a user's perspective, this approach is initially no different from framebuffer graphics with suitable drivers. However, in contrast to framebuffer graphics, the kernel also sets the screen resolution during operation, taking over this, and other tasks, from the X server. If the X server and a text console, managed with KMS, use the same screen resolution, the kernel no longer needs to reset the graphics chip and screen resolution when switching between the graphics interface and the console; this was previously required every time the user switched to X and VGA text or framebuffer consoles, because the kernel didn't know the X Server's configuration of the graphics chip. As a result, switching with KMS – for example while booting, when the X server first starts up – is considerably faster and is no longer afflicted by screen flickering or short display disruptions.

Because the kernel controls the graphics hardware in KMS, problems that arise when the VGA console and framebuffer driver, the Direct Rendering Manager (DRM) and various userspace programs, including the X server, compete for access to the graphics hardware, can be eliminated. With KMS, when waking up from suspend mode, the kernel also handles the entire graphics hardware re-initialisation, which is designed to solve some of the problems with using the suspend modes.

With KMS, X servers will reportedly also operate without root privileges; this and several other improvements associated with KMS are to facilitate the parallel operation of several X servers, allowing users to switch backwards and forwards (fast user switching). KMS will also allow Linux to snatch control from the X server in case of a serious kernel problem (kernel panic) and display troubleshooting instructions similar to those displayed for the dreaded blue screen in Windows – some developers have talked about a "Blue Penguin Of Death", but this isn't possible with the code incorporated in 2.6.29.

To avoid hardware access disagreements between the X server and the kernel, the X server and its graphics driver must also support KMS. However, X and kernel hacker Dave Airlie, who is responsible for the kernel's DRM code, explicitly says in his patch integration request that these parts are still being developed and currently are only intended for developers; therefore, KMS should not be enabled during kernel configuration, without the required userspace support.

It is likely to be some time until the kernel is ready for KMS with Radeon hardware: Although the KMS code for Radeon GPUs is already available, it is based on the TTM Memory Manager rather than the more recent Graphics Execution Manager (GEM) incorporated with 2.6.28 and so far that is geared to work with Intel hardware. However, according to Dave Airlie the TTM code is not mature enough to be integrated into the official kernel yet. It will probably be even longer until KMS becomes available with a standard kernel and Nvidia hardware, unless the developers of the Nouveau driver, which was created using reverse engineering, can pull some mature KMS code out of their hats, or Nvidia decides to provide KMS support. The latter is particularly likely to improve the reliability of the suspend modes, which often malfunction with the open source drivers for Nvidia hardware.

More graphics

The Graphics Execution Manager (GEM), which is still set to work with Intel hardware and manages the main memory as well as the access to the GPU's processing units, has been extended to include new features in 2.6.29 (1, 2). Several further changes involving the graphics hardware and included in 2.6.29 can be found in the following links and in the two integration requests by Dave Airlie (1, 2) and in the source code management system of Linux itself.

Further background and information about developments in the Linux kernel and its environment can also be found in previous issues of the kernel log at heise open:

Older Kernel logs can be found in the archives or by using the search function at heise open. (thl/c't)

(trk)

Print Version | Send by email | Permalink: http://h-online.com/-739697
 


  • July's Community Calendar





The H Open

The H Security

The H Developer

The H Internet Toolkit