xorg/ ModeSetting

Mode Setting Design Discussion

Contents:

  1. Introduction
  2. Terminology
  3. API
  4. Implementation

Introduction

The current design of having the X server drivers/frame buffer drivers all doing mode setting in the system is starting to cause issues, especially around areas like suspend/resume and with the development of new types of rendering mechanisms for X (like Xgl).

Mode setting in the kernel is possible for most cards, however a few cards require the use of VBE to set modes especially with external LVDS/TMDS and tv-out controller chips that are undocumented. Mode setting in userspace causes other issues such as at times like suspend/resume and interaction with kernel drivers.

It looks like a userspace modesetting system with an in-kernel component driver is the best possible solution. Current and future drawing system can interface to this modesetting library and use it to all their modesetting leaving the rendering application (X or Xgl) free to just render. This will also need to tie in with an in-kernel memory management system possibly.

This document will be in two sections, Modesetting API and some ideas for an implementation of it.

Terminology

setter: application using the modesetting library (not the human sitting at the machine)

screen: a physically viewable object (monitor, TV, the Matrix)

device: a piece of hardware or software that provides access to 0..n screens (0 screens means nothing plugged in at the moment)

API

Requirements

  1. Must be extensible and allow new types of display not handled by the core.

  2. Allow user to enumerate current devices, and screens attached to those devices.

  3. For each screen, allow the setter to enumerate the currently available modes and enable/disable output.

Currently open questions

  1. Show screen surface setup go via the modesetting library?

the EGL_MESA_screen_surface has the ideas of setting up screen surfaces on a particular screen, in my mind this is more to do with memory management than mode setting. A unified namespace between parties is definitely needed so we can tell what a modesetting device corresponds to. The memory manager would need to be told, that the setter needs an area of VRAM of a certain size and then the mode setter needs to be told to set the mode on the screen and point to the VRAM.

Comment by MichelDaenzer: EGL_MESA_screen_surface is intended to be the connection between memory management and mode setting. IMO, neither should the mode setting instance do any memory management, nor should the memory manager (have to) know anything about mode setting.

Implementation

Decisions made so far

  1. Initial implementation can be backended onto a fbdev driver, while an cut-down X server can be worked on to just modeset and not render.

  2. The DRI is necessary for this to work. You don't need a full DMA implementation for a card or anything just a stub driver doing memory management.

-- ?DavidAirlie