Last night, I visited Simon in order to discuss some
new stuff we want to put into displayconfig, one of the applications in guidance.
Besides discussing some minor issues, we made good progress with respect to the user
interface and code design of displayconfig, especially of the configuration of multiheaded setups.
We discussed how we wanted to design the user interface, so that it’s not only possible to do
“simple” things, such as switching resolutions. We’re planning to implement functionality to
configure a dual screen Xorg setup from within KDE. One of the results of yesterday night’s session
is the screenshot of a mockup, that should give some idea how that’s going to look like.
Moreover, we had a look at different solutions to detect hardware. Basically we need to know
the number of graphics adapters, which is pretty simple since they’re attached via the PCI bus in
most cases. More complex is the problem of detecting the number of monitors attached, the actual
size of monitors, the technical capabilities of the screens (such as refresh and sync rates). There
are a couple of tools which can help with that, but all of them have their problems and limits.
Mandrake ships ddcxinfo, which did a pretty good job detecting Simon’s TFT display and its
capabilities, but it pretty much sucked on my notebook, which was in that case reporting a display
size of 90″ (!!). xresprobe, which is shipped by e.g. Debian and Kubuntu let my notebook
screen flicker, which scared me a little, and it only managed to return my native resolution, but
not for example the sync and refresh rates. Then, there’s ddcxinfo-kanotix – obviously not packaged
for Debian in that incarnation. It printed out a lot of modelines, which is probably not too bad,
but also not sufficient for what we need. In other words: We still need a good way to get an idea of
the hardware topology of all display-related devices, suggestions – of course – are welcome (contact).
Also the configuration of the X server is a pretty complex complex issue since a lot of the
setup depends on the driver used. The most generic solution for a dual screen setup is
Xinerama. However, Xinerama has the disadvantage of limiting 3D / hardware
acceleration capabilities. Vendors like nvidia and ATi work around that in their drivers by
providing support for e.g. proper window placement from “merged framebuffer” mode, which is
a quite different setup with respect to xorg.conf compared to traditional Xinerama. So we
have to decide which way we want to do the configuration for the user, depending on the driver used,
the resolutions chosen and so on (Xinerama does work with different resolutions and color depths on
the respective ‘heads’, merged framebuffer does not seem to be capable of that) …
All in all, sticking our heads together was quite productive. Things are much clearer now
and there’s lots of code to be written. Sounds like we’re making good progress. :-)