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

[Jon Smirl]

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

All of your mode management code is still in the radeon driver so it
is in both places.  But if you are only parsing the EDID in the kernel
there is no way to merge entries in from a list in /etc/fb.modes. The
user space method allows modelists to be loaded for non-DDC monitors.

The only think you can eliminate is the hotplug event to the user
space app that does the EDID processing. The other three events are
required:

1) secondary card reset - must run user space helper unless you plan
on putting emu86 into the kernel.
2) modelist change - X has to know this, if X has a mode set for
another monitor and the KWM switch is flipped, there is no guarantee
that the new monitor will support X's mode. Not supporting this has
generated numerous complaints.
3) modeset - if someone pokes the sysfs variable or calls an fbdev
IOCTL to set the mode, X needs to be notified. This is a big hole in
the current system. Set a mode from an xterm and you can kill X.

The sysfs variables for modelist and mode are both needed to eliminate
the need to have root priv in order to set the mode.


-- 
Jon Smirl
jonsmirl at gmail.com