We’ve been working busily at RandR 1.2, both cleaning up the extension specification and trying to build a infrastructure that will help people get support into all of the video drivers. I thought I’d let people know where things stand and what remains to be done.
First off, things that are fairly stable now:
RandR 1.2 protocol specification. This hasn’t changed in over a month now and its looking like we’re finished. The XCB binding work cleaned up a few mistakes, but no semantic changes. The master branch now includes 1.2.
Xrandr library. Except for failing to copy a structure field from the GetCrtcInfo reply into the application structure, nothing has changed here in over a month either. Here as well, the master branch includes 1.2 support.
X server RandR 1.2 support. Two minor changes in the last month on the randr-1.2-for-server-1.2 branch. I’m not quite sure how we’ll want to release things, but I’m hoping to do a 1.2 ABI-compatible release shortly after 7.2 that includes RandR 1.2 support and can use old or new drivers (of course, old drivers won’t offer any snazzy 1.2 features).
One piece that needs a few new features is the xrandr application. I just spent a day cleaning things up a bit (it could use a more cleanup, especially splitting the source across multiple files). I added the ability to position outputs relative to one another and also a global ‘—auto’ mode which turns on all connected outputs and turns off all disconnected ones. With that, I hooked up a new global hotkey in metacity to run ‘xrandr —auto’ so I can just plug in a new monitor, hit the key and expect it to light up. There are still a few more tasks to take care of here:
Handle the —extend option to place new outputs adjacent to existing outputs instead of at 0,0.
Receive and validate events for all of the changes; this would make testing the server event generation possible.
Control output properties and gamma ramps. Right now, there’s no way to test output property effects, and we’re hoping to use them for all kinds of stuff from backlight intensity to TV output settings.
On the driver front, we’re doing development in an unusual fashion (and we may regret it if we’re not careful). As our goal is to produce a single driver binary that will run against both 7.2 and newer X servers, we cannot depend on having any new functions in the server binary.
To avoid server dependencies, we’re building a bunch of new driver-independent functionality as if it were part of the server binary and linking that into the Intel driver. As much of this code started life as driver-dependent explorations of how to make RandR 1.2 work, it isn’t quite as independent as we’d like. We’ve done some piecemeal attempts to make it look a little better, but the result is actually fairly ugly at present with a mish-mash of function naming schemes and remnants of driver-dependencies in odd places.
Dave Airlie has been copying this code into the nouveau driver and hooking up RandR 1.2 support there. That’s great as it gives us a chance to make sure these new interfaces are right for more than one driver. I’m hoping someone will also take a look at how this will work in the radeon driver; with that, we’ll have a reasonably broad experience with the new interfaces and should be able to avoid nasty surprises down the road. Of course, drivers will still be able to completely by-pass this layer within the server, so at least we won’t make fixing it impossible, only painful.
I’ve also recently started on some xorg.conf support for output configuration. Right now, this consists of the ability to associate a Monitor section in the config file with each output of the device. From the monitor section, you can add new mode lines, specify DPMS support, override sync ranges and set a preferred mode.
We’ve also started adding some monitor ‘quirks’ to the EDID detection code; I got a trio of monitors from France that all had various incorrect data in their EDID blocks, including one monitor which reported a preferred mode of 640x350. I’d like to keep adding more quirks as we find broken monitors; that lets everyone share the same fixes. Of course, with the xorg.conf support now available, you can override most of the EDID data and work around things at run-time, but if you do have to do this, please submit a bug report and attach the broken EDID data (xrandr —prop will print it out for you).
Aside from general infrastructure cleanup, we’ve still got some features missing from the implementation that we’d like to play with:
Per-CRTC gamma tables. Given the existence of the XFree86VidModeExtension support for per-screen gamma tables, I think we’ll want to think a bit about how our per-CRTC gamma tables might be affected by VidMode applications, probably the right answer is that VidMode updates will write all CRTC gamma tables. It looks like this is mostly glue work though, the driver already exposes the needed functionality (albeit not per-crtc yet).
Output properties. Right now, we’re reporting EDID data back to clients as an output property, but I’d like to see an example of using properties to control an output in some fashion. One obvious example is the backlight brightness value; that seems really useful and should be fairly easy to hook up. Beyond implementation, it would also be nice to start building a list of standard output properties and their interpretation and placing those in the RandR specification. I expect to update the RandR specification regularly with new output properties; don’t be shy if you have something you’d like to use here.
Finishing the xorg.conf support to include layout and detection override options. Right now, the driver autodetects available outputs, and sometimes it gets it wrong. In particular, mobile Intel chipsets appear to have no way to detect whether an LVDS output is hooked up, so we’re starting to special-case a long list of products using mobile chipsets without a local LCD panel (mac mini, aopen boards, etc).
Xinerama ordering. Right now, you get Xinerama screens ordered by internal structure within the driver. I’m thinking we want to use output properties to order things instead; perhaps something as simple as ‘XINERAMA_HEAD’ values in each output that tell the server how to order things. This should be done entirely within the DIX randr code, not the driver. Some applications use this information to place dialogs and other details.
And, of course, it would be fun to see some applications starting to use this, in particular KDE and Gnome both have screen size setting applets which could see some significant enhancements now.