Hal and Xorg output devices

[Ely Levy]

On Thu, 24 Feb 2005, Jon Smirl wrote:

> 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.

So we agree on the model just that you say hal should use sysfs on linux
to see what the modes are instead of libddc?
I just don't see why that code needs to be in the kernel, after all you
don't need to be in kernel mode to access that information, and with linux
moving device handling to user level with hotplug and udev it only makes
sense to get the info in that way.
as for pci info libpci is done by kernel people and probebly already knows
how to find all that informaiton, I think kernel drivers should be kept as
simple as possible as they are very not portable and a lot harder to
debug.
> --
> Jon Smirl
> jonsmirl at gmail.com
>

Ely