Hal and Xorg output devices

[Jon Smirl]

On Fri, 25 Feb 2005 04:31:32 +0200 (IST), Ely Levy
<elylevy-xserver at cs.huji.ac.il> wrote:
> I would like to propose the following design:
> Move the card memory allocation into xlibpci
> Move the rest of the pci probing into hal while making hal use
> libpci to get the info (since libpci is gpl we can't call it directly from
> X).
> Move rest of screen info into hal write a libddc lib and let hal use it
> for getting the information.
> 
> X should export a dbus api and should be able to call functions like
> array{InputDevices} ProbeForInputDevices()
> array{VideoCard} ProbeForVideoCards()
> array{Monitors} ProbeForMonitors(VideoCard card)
> (taken from davidz suggestion).
> 
> This stracture should enable easy adding/removing of screens.

This proposal continues with the old XAA 2D driver model for X. It
will also propagate some of the flaws in the XAA 2D model further.

Alternatively you might want to help us with XGL. XGL greatly changes
the device model of X. In the XGL model all low level hardware
manipulation is done in device drivers. The device drivers are
implemented using standard kernel calls for doing things like
accessing the PCI bus.

With XGL XAA is replaced with OpenGL. OpenGL is implemented via the
mesa library. Mesa then in turn uses fbdev and DRM for hardware
access.

Some issues with XAA....

1) Manipulating the PCI bus from user space has to stop on Linux. X is
changing things in PCI config space without letting the kernel know.
For example a kernel variable bridge_ctl shadows the hardware bridge
control, the kernel can store bridge_ctl into the hardware wiping out
changes X made. X can also make things like PCI ROMs appear in the PCI
address space. The kernel does not know X did this. Now a new hotplug
device comes along and the kernel assigns it an address on top of X's
ROM. Good chance you need to reboot your machine.

2) X is not the only client of video. We have things like framebuffer,
DirectFB, etc. Using device drivers for mode setting make this code
common to all users. X is often conflicting with these other users.

3) Moving hardware access into the device drivers removes the need for
X to run as root.

4) We are fixing the radeonfb driver to generate an interupt on
monitor change for things like KVM switches. This interrupt will turn
into a hotplug event that can be passed on to dbus.

5) In the XGL model card memory management is handled by the DRM device driver.

When the device drivers are finished all of the info you are looking
for will be easily accessible from sysfs. For example to enumerate the
video cards in the system use: 'ls /sys/class/graphics' To see what
modes the card supports 'cat /sys/class/graphics/fb0/modes' It will be
easy to write dbus functions that build the lists from the data in
sysfs.

-- 
Jon Smirl
jonsmirl at gmail.com