Xgl page - http://www.freedesktop.org/Software/Xgl

[Benjamin Herrenschmidt]

> modprobe card driver
> card driver checks if post needed, if so uses a new version of
> request_firmware() to post
> sys/graphics/fbX is added for each head
> udev builds /dev/fbX for each head
> 1) driver locates monitors
> creates sys/graphics/fbX/monitor(edid)
> creating this causes a hotplug event
> root priv hotplug event parses edid merges etc/mode file
> sets legal modes back into sys/graphics/fbX(mode-list)
> altering the modelist causes an event hal/dbus can see
> user space mesa/X reads the mode-list, strings like 1024x768-60
> set the one you want back into sys/graphics/fbX(mode)
> this causes another hal/dbus event

I think the above is way too complicated. The kernel driver should
probably build a default mode list and pick a default mode (easy), even
if userland may decide later on to change it to something else. You
require way too much bits interracting with each other just to get a
mode on screen. Node that in pretty much all OSes I know, mode
management is a kernel thing.

> If the card supports an interrupt on monitor change, flipping a KVM
> switch will restart the process at #1.
> 
> Mode lists are generated at root priv.
> Pam assigns ownership of mode variable to user
> This allows a non-root user to safely set the mode
> 
> Patches for about 60% of this have been posted to fbdev. I'm working
> on the rest.
> 
-- 
Benjamin Herrenschmidt <benh at kernel.crashing.org>