Autoconfiguration of non-PCI devices during Xorg startup

Michael Casadevall michael.casadevall at canonical.com
Thu Jan 15 08:08:37 PST 2009


I've been recently working on resolving issues with Xorg's
autoconfiguration mechanism with respect to non-PCI based graphic cards.
Although Xorg -configure currently can handle these types of devices
(assuming the individual driver probes work correctly that is), there is
no automatic mechanism in xf86AutoConfig.c to handle non-PCI cards on
Linux (there is a little bit of support on Sun by reading the
framebuffer device).

The main issue I'm trying to resolve is that on the ARM architecture,
many boards which do have video out often have it hooked directly to the
processor or otherwise bypassing a carded bus like PCI. In these cases,
autoconfiguration fails since there is no mechanism for these devices.
To further complicate the matter, there also is no standardized
interface for seeing these type of display devices.

What I would like to implement is a lookup mechanism similar to PCI
based lookup files, expect it would use the information available from
/proc/fb, or /proc/cpuinfo to associate a display device with a specific
video driver. For instance, on X startup, it would probe /proc/fb, read
the ID tag of the framebuffer device, and then load the correct driver
based off that. The drawback of checking /proc/fb however is that it
depends on the framebuffer driver being present in the kernel.

To avoid this, since on ARM we're dealing with an architecture that is
often space limited, the lookup could fall back upon /proc/cpuinfo, and
read the Hardware and Revision tags from there, and then look up against
 another set of data files. As many ARM boards have a one board == one
video device relationship, this works well for a vast majority of boards
without requiring framebuffer devices compiled into the running kernel.

Since this work will benefit the users of X on ARM in general, I'd like
to get the work I do merged upstream, and have it in a way that will be
acceptable for merging at the get-go. Any comments or criticisms of the
design are greatly welcomed.
Michael



More information about the xorg mailing list