Using HAL for X Server Config Properties?

[Benjamin Herrenschmidt]

On Fri, 2005-10-07 at 14:38 -0400, Jim Gettys wrote:
> There are a number of things going on here:
> 
> 1) I think we are mostly agreed on probably using dbus to talk to the X
> server to control configuration.  There isn't any particular Linux
> dependency to dbus that I can see.
> 
> And configuration can get complicated, with many different input devices
> and potentially more than one seat on a system.

 .../...

I've been discussing the purely output device aspect of things a few
times in the past with Keith and others, and it seems a good approach
here would be to go toward something like this (I'm throwing here a
bunch of the things that we have discussed, it's open for correction of
course). Maybe we could start from that, define each points more
precisely, and move toward a more formal definition, though I have the
gut feeling that a prototype implementation is worth 10 architecture
documents :)

 - The actual hardware mode setting interface split from the server
itself.

 - The above interface is provided by a daemon/server (protocol to be
defined, possibly dbus based) which itself has loadable backend modules.
It interfaces to whatever operating system interface can notify it of
addition/removal of display adapters.

 - The mode setting server itself broadcast (possibly via dbus), events
indicating addition/removal of screens. This is not a 1:1 relationship
to display adapters. Adapters cause drivers to be loaded/initialized in
the mode server, those drivers can then provide mecanisms for probing
the various CRTCs/outputs and create/remove screens. 

 - Simple back-ends initially could be VBE (maybe via vm86/x86emu) and
fbdev. In the long run, the mode setting part of the existing X drivers
should be moved/rewritten to fit in the new model

 - To avoid most of the current mess with mode validation, the mode
setting server includes all the infrastructure for proper monitor
management. The back-end driver provides port information, including
things like EDID if available, extended EDID, simple electrical presence
detect, register-probed panel size, availability of a HW scaler, of dual
link DVI output... The server would have the logic for generating mode
lists (using EDID, GTF, CVT for panels, ...).

 - The server would manage a database of monitors. From experience,
we'll have to bite the bullet here. There are nicely defined EDID
extensions for getting things like subpixel format, panel color
resolution (bits per component), aspect ratio, etc etc etc... However it
seems pretty much nobody implements them (yet). Most monitors come with
a floppy or a CD with windows configuration files. I think we should be
able to define our own format (maybe XML based) and a way to convert
those windows definition files to it

 - There need to be some kind system-wide configuration that defines
access permissions to subsets of the HW (to deal with multiseat) with a
granularity that is under driver control (allowing two seats to share
two heads of a single card might lead to extreme complexity, at least I
would leave that out of an initial implementation).

 - Within a seat/user environment, configuration is under user control.
The "screen set" starts either blanked or with a default mode & gray
background until a full configuration is fed to the mode server by the
client (typically a display manager).

 - Configurations are XML-like objects (maybe using xmlrpc ?) that
contain the whole configuration of all screens of a given user screen
set. The API to the server is transactional, of the form: request
configuration / commit configuration. A user configuration application
typically request the full configuration, uses API helpers to browse it
and/or change bits & pieces, and commit it at once. The actual
configuration obtained may not be the one commited, the user should
request it again to check what actually happened (some HW limits may
have been applied by the drivers at commit time, fully validating
configurations in advance would be too complex). We could have a
validate configuration call that does as much validation as possible,
but there is still the possibility that some resources that were
available at validation time aren't available anymore at commit time.
Using some XML-like format here would make it easier for display/desktop
managers to store the whole configuration along with geometry
informations (relative positionning of screens).

 - A client (like X server) uses whatever protocol (dbus based ?) is
defined to talk to the mode server and uses the DRM for actually mapping
in the framebuffer and queueing rendering commands. The form is similar
to current DRI. For old/legacy cards, the DRM might provides the
facility to do an exclusive mapping of the chip registers for "old
style" type acceleration, though it would be preferable to have the
kernel driver implement the acceleration primitives via ioctls for
security reasons.

Hope this is useful, I'd like to start working on this myself but
experience shows that I have way less time to dedicate to these things
that I'll like to and thus can't guarantee any result.

Ben.