Kernel Log: What's new in 2.6.29 - Part 3: Kernel controlled graphics modes
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.
- agp/intel: add support for G41 chipset
- drm/i915: add GEM GTT mapping support
- drm/i915: Add support for integrated HDMI on G4X hardware.
- drm/i915: Fix stolen memory detection on G45 and GM45.
- drm/i915: Non-mobile parts don't have integrated TV-out.
- drm/i915: Register module dependencies for the modesetting code.
- drm: kconfig have drm core select i2c for kms
- drm: move to kref per-master structures.
- fbdev: fix typo in drivers/video/modedb.c
- fbdev/logo: check compatibility of main and extra logos
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:
- Kernel Log: main development phase for 2.6.29 ends, new X.org drivers
- Kernel Log: What's new in 2.6.29 - Part 2: WiMax
- Kernel Log: What's new in 2.6.29 - Part 1: Dodgy Wifi drivers and AP support
- Kernel Log: 2.6.29 development kicks off, improved 3D support
- Kernel Log: Higher and Further, The innovations of Linux 2.6.28
- Kernel Log: What's coming in 2.6.28 - Part 9: Fastboot and other remainders
- Kernel Log: What's coming in 2.6.28 - Part 8: Video4Linux/DVB, (Wireless) USB, hardware monitoring, and input devices
- Kernel Log: What's coming in 2.6.28 - Part 7: architecture support, memory subsystem and virtualisation
Older Kernel logs can be found in the archives or by using the search function at heise open. (thl/c't)
(trk)