I am preparing my switch to a new laptop at work in the next weeks. I am considering adding encryption to part of the hard drive, but I don't want to dramatically decrease performance. Encrypting the swap device or some .foo directories in $HOME looks like a good idea to protect private keys, keyrings, ... But encrypting git clones of large projects is probably useless. So I am thinking of just having a small /home encrypted partition (a couple GB). I'd keep .foo directories in $HOME and only have symlinks to another non-encrypted partition where all my actual source code and other non-sensitive files would be. Does this make any sense?

Now that we have DRM from 2.6.33 in latest 2.6.32 kernel in unstable, I just uploaded Radeon KMS and DRI2 to unstable. xserver-xorg-video-radeon 1:6.12.192-2 even enables KMS by default. Please test it. In case of problems, you may for instance disable KMS by changing modeset to 0 in /etc/modprobe.d/radeon-kms.conf. You may also downgrade to testing where xserver-xorg-video-radeon 1:6.12.6-1 does not enable/support KMS. Make sure you run linux-image-2.6.32-4-$arch or later so that you actually have DRM from 2.6.33 and the radeon kernel module gets loaded early by udev. Otherwise, you may experience problems like this. You may need to add radeon to /etc/modules as a temporary fix.

Almost nothing interesting happened recently in X.org in Debian. But interesting things are coming soon.
First, radeon KMS and DRI2 will enter unstable soon. xserver-xorg-video-radeon 1:6.12.191-1 is currently in experimental. People seem to be happy with it so far, and upstream is taking very good care of bug reports as usual. The next 2.6.32 kernel will contain DRM from 2.6.33. It first means that the radeon KMS driver not in staging anymore. Once this new kernel is uploaded, I'll put the new xserver-xorg-video-radeon in unstable (6.13.0 is expected soon, but 6.12.191 already looks good so far). DRM from 2.6.33 will also brings nouveau support. It means that we will build libdrm-nouveau and upload a new xserver-xorg-video-nouveau. However, it also means that we need somebody to maintain this. And nobody in the team has a nvidia board to test packages so... If you want nouveau in Debian, please help.
While waiting for all these, we have been triaging the BTS a bit. Kibi is helping a lot by triaging recent intel bugs (many regressions fixed in recent kernels). I spent some time during the week-end triaging some old bugs. I closed more than a hundred of them, and pinged another hundred. We still have more than 1100 bugs open. It is not so bad compared to 1500-2000 when nobody maintains X (aka often), but still way too much. Some of my bug closing might look a bit rude. But we had so many bug reports a couple years ago that are irrelevant today. Keeping them open would be meaningless. For instance, many input problems are obsolete since a lot of the input code was rewritten, we switched to input-hotplug, and then hal to udev. Another example is intel lockups (we had a lot of them after driver 2.2 arrived). But XAA and EXA were dropped in favor of UXA, DRI1 was dropped for DRI2, and KMS arrived. So it's useless to keep these obsolete and irrelevant bugs that cannot be debugged nowadays.
As usual, the Debian X team needs a lot of help. Again, if you want nouveau in Debian, please help.

Now that libdrm-radeon1 is in unstable, I just uploaded a snapshot of the radeon driver to experimental (xserver-xorg-video-radeon package version 1:6.12.99+git20100201.a887818f-1). So you may now get KMS and DRI2 working, assuming you have a recent kernel (I am running 2.6.32-trunk-686 here). This driver even contains some early support for r8xx boards. To check whether KMS is working, look for radeon kernel modesetting in dmesg. To check whether DRI2 is working, look for DRI2 in /var/log/Xorg.0.log. Make sure the radeon kernel module is loaded early (which means: don't let X load it late in the boot, otherwise you may experience this bug). I had to add radeon to /etc/modules and put options radeon modeset=1 in /etc/modprobe.d/. In the past, I also needed agpmode=-1 there but it didn't seem to make any difference with latest packages. Then, actual DRI2 support requires Mesa packages rebuilt against libdrm-radeon1. This is in experimental as well now. Look for libgl1-mesa-dri and other Mesa packages version 7.7-3. Don't forget that these packages are in experimental for a good reason, they may not work. But at least basic things seem to work fine on my Radeon X300 (rv370). And don't forget that the X team needs help, otherwise these packages may never make it to unstable...

Ok so there were some reactions to the Call for help post. I had three direct offers for help in pkg-xfce, not sure if other teams had such propositions. Some people asked me to correct various number for the active contributors . Basically, the numbers are what the feeling I got from people working in those team. Julien Cristau wants me to correct the number of debian-x active contributors to 0. (yes, zero, that means nobody, nadie, personne). Basically he doesn't have time anymore, and Brice Goglin can't really keep up. So, for those who care about shiny X effects, and stuff like that, you help would be gladly appreciated (and no, you don't have to own each and every chipset in the world to give some time). Aurelien Jarno wants me to add that at the moment there are 2 (two) active libc contributors, plus one on GNU/Hurd and one on kfreebsd. Frans Pop wants me to add that there are ~85 people working on d-i and that the problems the team might face aren't only related to the lack of manpower (and I don't really want to enter politics) Finally, it seems that some people (well, only one at the moment, but it's enough for to feel the need to precise) though the numbers previously given would dismiss contributions for the active contributors. That wasn't my intention, so I apologize if you are an active contributor in one of that team and thought I dismissed your contribution. If it wasn't clear enough, my point is to show that quite some teams are lacking manpower (some team miss other things too, like leadership, coordination or whatever) and users shouldn't be scared to contribute to them. Those are core teams, without them Debian wouldn't work at all (not to mention derivatives), so it's a good idea to join them. Now, what if you do want to help, but don't know how. On the previous post I gave links to teams website, wiki page or QA page. You should be able to find a mailing list or contact mail you should be able to write to. Just write that you want to offer some help, that you don't know how and where to start. Add what you're interested in, what you find fun, and your technical knowledge. Don't be shy, and you don't need to be a Debian Developer (nor even a Debian Maintainer) to contribute. Thanks!

No Xorg update entered testing since Lenny was released. The last big remaining bug in unstable was the Intel driver locking up on i865 when the UXA/GEM acceleration is used (and 2.8.x only supports UXA so there is no work around). See #541307. Fortunately, Eric Anholt found out that it was caused by a kernel bug in the intel-agp driver. The fix is not in vanilla 2.6.31, so you'll have to apply the patch or wait for an updated 2.6.31.x kernel to be released. Anyway, the Intel driver 2.8.1 as well as Xserver 1.6 and Mesa 7.5 will enter testing soon. If you have a i865, make sure your kernel contains the above fix or you'll likely experience lockups soon after X startup. Update: If building the intel-agp driver as a module, you will also need another small patch to export the clflush_cache_range() function to modules. Update: Everything just entered testing of real.

We got many bug reports about X being slow. Many of them are caused by some MTRR/PAT problems in kernel 2.6.29. But some are not. It appears to be caused by Debian 2.6.29 kernels not containing ugly binary graphics firmware anymore. Indeed, radeon, r128 and mga driver need a firmware for 3D, but also for some 2D and Xv features (basically everything that's hardware accelerated). So if you use one of these X drivers and you have some problems, a quick look in the kernel logs might tell you that a firmware is missing. Installing the firmware-linux package may help then. We are adding the corresponding Suggests line to X drivers. Moreover, some people are upgrading to 2.6.30 pre-release because it contains DRM support for R600 boards. A ugly binary firmware is needed as well and it has obviously been removed from Debian 2.6.30 experimental packages. But firmware-linux does not seem to contain this firmware yet. So if you want 2.6.30 for R600 DRM, you want to either build your own 2.6.30 kernel, or wait for an updated firmware-linux package to be available with R600 firmware. See bug#523467 for an example.

Now that the final Mesa 7.3 is available in experimental (and built on most architectures), it is actually easy to get DRI2 in Debian if you have an Intel board. First, make sure you have a recent kernel, otherwise it may fail miserably. I am running 2.6.29-rc here, and I am not even sure 2.6.28 would be enough. Hopefully, one day the driver/server will properly detect and report problems when it runs on a old kernel :) Enable the new UXA acceleration architecture with Option "AccelMethod" "UXA" in the device section of your xorg.conf. Restart X. You should see DRI2 enabled in the log. Now start Compiz and it works. You can see a wobbly glxgears! Well, on my i945, Compiz was very slow by default. I add to disable Sync to-VBlank in the display settings in Compiz' general options. If you don't want Compiz, you may also try running xcompmgr -a and then play with transset to put transparency on 3D applications. Update: Added kernel requirements, added how to make Compiz not slow.

Apart from interesting features such as DRI2, KMS or input-hotplug, there are some minor changes in X in experimental that actually appear to disturb many users. The first one is that Ctrl-Alt-Backspace does not kill X anymore. There is no easy consensus here, but many people were annoyed of killing X by mistake, so it's disabled by default now. To reenable it, add to the ServerFlags section of your xorg.conf:

        Option "DontZap" "off"

Another one is the background during X startup. Say goodbye to the old well-known grey background. Now you get a black background by default. To revert to the old behavior, pass -retro on the server command line (for instance in /etc/X11/xinit/xserverrc). Note that this option also reenables Ctrl-Alt-Backspace killing the server. Finally, you might also see glxgears reporting very low frame rates (60) on some hardware. Well, please remember that it is not a benchmark, the output basically means nothing. This is why some distros even removed the fps output by default. The thing is that recent DRM stacks will just synchronize frame rendering on vertical blanks (can anybody here see 1000fps with human eye?). So if you have a 60Hz refresh rate, glxgears will report 60fps, that's it. But it has nothing to do with DRI or 3D being slow. Please try some relevant 3D programs or benchmarks before complaining :)

I have been wondering for a while how to get X.org "input-hotplug" to work, but I never actually tried before today. It is actually fairly easy, once you know what to do. Requirements First, make sure you have the evdev X driver installed (xserver-xorg-input-evdev). You might want to use X packages from experimental since things are much more recent than in Lenny or Sid these days, and upstream improved input management in the meantime. Then, if you are not running a pre-packaged kernel, check the the evdev driver is enabled and loaded in your kernel (CONFIG_INPUT_EVDEV). Telling hal what to do with input devices Now, you need to tell hal how to configure your input devices. Actually, you do not have much to do since latest xserver-xorg-input-evdev packages bring what you need. hal reads all fdi files under /usr/share/hal/fdi/policy to find out how devices should be configured. If you run lshal and look for input, you should see that the evdev is planned to drive your input devices. However, if you look at keyboard devices in lshal (look for input.keys), you will see that the US layout is used. To switch to another layout, you can add some overriding rules as a new *.fdi file in /etc/hal/fdi/policy/. For instance, to get French layout:

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.keys">
      <-- Enforce XkbLayout=fr and XkbVariant empty -->
      <merge key="input.xkb.layout" type="string">fr</merge>
      <merge key="input.xkb.variant" type="string" />
    </match>
  </device>
</deviceinfo>

Thanks to this, you can enforce XkbLayout, XkbVariant and friends as usual in /etc/X11/xorg.conf. Don't forget to restart hal after modifying some fdi files. Then run lshal, and look for Xkb, you should find your setup there. Note that you can add some matching rules to configure some devices with different setups if needed. Just need to read the output of lshal and find something like a hardware identifier to match on. You can find some documentation about these rules by looking at the existing fdi files in /usr/share/hal/fdi/policy/20thirdparty/, and in the upstream x11-input.fdi (note that input.xkb.foo is the actual recommended syntax instead of input.x11_options.XkbFoo). Touchpads If you have a touchpad and want to use the synaptics driver, installing the xserver-xorg-input-synaptics will bring another fdi file. /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi matches input.touchpad in the device capabilities in hal. Now the synaptics driver will be automagically loaded for your touchpad (instead of evdev for regular mice). Again, you can override this rule in /etc/hal/fdi/policy/ and you can add many configuration options for synaptics as well. See /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi to get an example. Fortunately, you will not have to manually take care of the above /etc/hal/fdi/policy/ file for ever. The plan is to have hal look at the Debian console configuration and get at least the keyboard layout from there automatically. Telling the Xserver to talk to hal Now, you need to tell the Xserver to use what hal wants. Basically, you want to remove everything about keyboard, mouse and other input devices from your xorg.conf. Just drop all InputDevice sections and all references to them within other sections. With recent Xserver versions, options AllowEmptyInput and AutoAddDevices are enabled by default (otherwise, you might have to add them in the ServerFlags section). For more documentation, you want to read Peter Hutterer's blog, especially this post and this one. By the way, if you don't want this input-hotplug thing and you want to run a recent Xserver anyway, you should set AllowEmptyInput and AutoAddDevices to off in the ServerFlags section. Update: Fixed the way to manage fdi files, fixed the syntax of input.xkb.foo rules, added a paragraph about synaptics, and organized things in sections. Thanks to everybody's comment.

It has been a while since my last post here. Not because nothing happened, but mostly because I did not have time to do much for X. Fortunately, Julien is taking good care of X in Debian so we are still close to latest upstream bits. Obviously, due to Lenny's freeze, everything is happening in experimental these days. Xserver 1.6 The release Xserver 1.6 is expected in the near future. 1.6-rc1 (1.5.99.901) entered experimental recently. Both video and input driver ABIs changed and very few drivers have been rebuilt so far. So if you're not running Intel or Radeon, you might not be able to upgrade yet. Please be patient :) You might have heard that many things are happening in X.org these days: DRI2, kernel-modesetting (KMS), RandR 1.3, ... Everything is not ready yet, but it's getting close for real. Radeon 6.10.0 and Intel 2.6.1 Radeon driver 6.10.0 was released in early 2009. As usual, it brings many fixes, and improvements for modern boards (see Alex Deucher's blog for details). However, Radeon is not ready for above DRI2 and KMS yet. Most of the development for these new features is first done in the Intel driver, which got recently bumped to 2.6.1 as well. DRI2 DRI2 is the new Direct Rendering Infrastructure. The most noticeable change from the user point of view is support for Redirect Direct Rendering, which basically means that your 3D application can be wobbly/transparent in Compiz. See Kristian H gsberg's blog for details. If you want to try DRI2 on Intel, you have to enable UXA as the acceleration architecture in xorg.conf (Option "AccelMethod" "UXA" in the Device section). DRI2 will then be enabled automatically. Then, it may or may not work, depending for instance on the hardware. I get a black screen at startup on i865 while i945 works fine until I start Compiz (the server suddenly exits for some reason then). Note that you probably want to upgrade your Mesa packages to experimental as well here (7.3 has been released recently). Of course, running git snapshot of various components (Mesa, libdrm, kernel drm, Intel driver, ...) may help since the released versions seem to not be entirely ready yet. But, things should may be ready to use for everybody in the near future. Kernel Modesetting The other nice feature that makes a lot of noise in X.org these days is Kernel modesetting (KMS). It moves the management of mode (aka resolution+rate) into the kernel. It helps support for switching between different users' sessions, enables reporting of kernel messages (oops, panics, ...) while X is running, and reduces the need to blank the screen during boot (since the kernel can setup the display early and X doesn't have to change it later independently). KMS testing requires a bleeding-edge kernel (2.6.29). Using a git snapshot of the drm stack is probably a good idea as well since I couldn't get KMS to work on 2.6.29-rc2 here. Again only Intel will support KMS soon, but other drivers will follow. Panning is back (aka RandR 1.3) Xserver 1.6 brings support for the 1.3 version of the RandR X extension. Among other improvements, it reintroduces one feature that many users miss since it was removed back in Xserver 1.3 or so. "Panning" (often referred to as "Virtual Desktop") gives the ability to move the display within a larger screen when the mouse approaches from the border. Instead of being configured with the Virtual option in xorg.conf (this option means something else nowadays), it may now be enabled/tuned with xrandr --panning. You'll need the latest libxrandr2 and xrandr utilities to do so (the latter is not uploaded yet).

As you may now, the r128 and mach64 drivers were split out of ati recently. However, for Etch->Lenny transitional reasons, xserver-xorg-video-ati still depends on xserver-xorg-video-r128 and -mach64. If you're bored of having to install these packages on your Radeon machine, beware that there is now xserver-xorg-video-radeon for you in unstable. It just contains the radeon driver and does not depend on any other driver. xserver-xorg-video-ati still exists, for transitional reasons. It also provides the "ati" meta-driver which takes care of loading "mach64", "r128" or "radeon" depending on your hardware. If you actually remove xserver-xorg-video-ati, don't forget to update your xorg.conf into Driver "radeon". Update: And of course, right after posting this, I get a bug report about the missing Replaces: ati. It will be fixed in 1:6.8.191-3.

Xserver 1.4.2 for Lenny We originally planned to ship Xorg 7.4 and Xserver 1.5 since they were expected in February. However, Xserver 1.5 (and Mesa 7.1) are not released yet, so we are going to keep some updated X.org 7.3 for Lenny. A new Xserver 1.4 snapshot with some security fixes will enter testing soon. Once this is done, the final Xserver 1.4.2 will be uploaded. It is not perfect but it is the one you will get for Lenny. Many people suffered from Xserver 1.4 bugs in the last months, especially on the input side. Fortunately, many of them have been fixed. Lots of them were also caused by obsolete config files (that have to be manually fixes unfortunately). So we hope this Xserver 1.4.2 will be good enough for Lenny. XaaNoOffscreenPixmaps by default It is worth noting that XaaNoOffscreenPixmaps will now be the default (when XAA is enabled, i.e. by default for all drivers but Intel). It helps Compiz and seems to prevent various rendering problems from happening. Ubuntu and Fedora have been running such a patch for a while, so it looks like we are going to do the same for Lenny. To revert to the old behavior, use Option XaaOffscreenPixmaps in the Device section of your xorg.conf. ATI 6.8.191, Intel 2.3.2, Mesa 7.0.3++ Apart from the server, some big components are getting updated these days: A new Mesa has been uploaded so that it enters testing before the libs are frozen. It contains the latest Mesa 7.0.x git snapshot, including lots of bugfixes, especially for Intel hardware. Mesa 7.0.3 was already pretty solid, this new one (7.0.3-2) will be even better. ATI is still getting a lot of work upstream as usual. 6.8.191 (aka 6.9-rc1) has been released this week. It brings r6xx support, acceleration for r5xx, EXA Composite for r3xx/r4xx/r500, textured video support, ... It also fixes many bugs everywhere. Given the big testing that we had in experimental in the last months, I consider it much better than 6.8.0, so I decided to put it in unstable even if it's only a release candidate. This new ATI does not include the r128 and mach64 drivers anymore. So the new xserver-xorg-video-r128 and -mach64 packages finally entered unstable as well. Due to unexpected upstream version numbers for mach64 and r128 and me messing up with epochs, they have a lower version number (6.8.0-1) than the previous snapshots from experimental (1:6.8.1~git...). There's almost no code difference though, but people might want to install the unstable packages anyway. The old snapshots will be removed from experimental soon. On the Intel side, a new 2.3.2 is expected soon, without many big improvements from what I have seen. X.org post-Lenny Future Xorg 7.4/Xserver 1.5 prereleases should arrive in experimental soon. It requires Mesa 7.1, which still needs some build fix and requires a new yet-to-be-released libdrm. Once all these are properly fixed and released, you should for instance be able to experience some interesting improvement in EXA. It may finally make XAA useless for real. Also, Xorg 7.4 will simplify the Xserver package maintenance since its build won't need the whole Mesa source anymore (the GLcore module that AIGLX uses will be built/shipped within Mesa). Stop build-depending on xutils! Also, we've been trying to cleanup the dependency mess in many X packages for a while. We removed the obsolete dependency from xutils to xutils-dev which was only needed for Sarge->Etch upgrade (xutils-dev was split out of xutils). However, many packages still wrongly build-depend on xutils. Lucas reported that removing this useless dependency in the latest Xorg upload caused 84 FTBFS. So, we're going to revert the change to avoid adding 84 RC bugs. However, everybody build-depending on xutils, please check whether you actually need xutils or xutils-dev so that we can quickly fix this after Lenny.

After xf86-video-ati 6.8.0 got released, George Sapountzis split the old r128 and mach64 subdrivers out of the common ati wrapper. So, starting from 6.8.1, the xserver-xorg-video-ati package only contains the radeon subdriver. The other subdrivers have been moved to their own xserver-xorg-video-r128 and -mach64 packages. All of them just landed in experimental. Your existing xorg.conf should work as before. I don't have any Mach or Rage board, so please test these new packages and report back if they don't work. Note that if your xorg.conf contains Driver "ati", you'll need to keep xserver-xorg-video-ati installed. If you only have the mach64 or r128 package installed, you need switch to Driver "mach64" or "r128" in xorg.conf. On the radeon side, the upstream developers are still very active. The last feature that has been added is Textured Xvideo. The Xvideo extension is usually implemented using the hardware overlay, which basically inserts the video on screen at the very end of the rendering. While working very well, this feature conflicts with compositing managers such as Compiz which cannot transform the Xvideo image. The radeon driver now exposes a Texture Xvideo adaptor which is composite-aware, which means you can have wobbly Xvideo players in Compiz. The Overlay adaptor is still the default since the Textured video isn't considered stable enough yet. To enable it, you can use something like:

    mplayer -vo xv:port=74 foo.avi

Where do I get this port 74 from? Just look at the output of xvattr or xvinfo:

    $ xvattr
    Found Xv 2.2
    Adaptor: 0
    Name: ATI Radeon Video Overlay
     Port: 73
     [...]
    Adaptor: 1
    Name: Radeon Textured Video
     Port: 74
     Port: 75
     [...]
    $ xvinfo
    X-Video Extension version 2.2
    screen #0
     Adaptor #0: "ATI Radeon Video Overlay"
      number of ports: 1
      port base: 73
      [...]
     Adaptor #1: "Radeon Textured Video"
      number of ports: 16
      port base: 74
      [...]

We are getting many bugs about wrong DPI configuration and DisplaySize not working. In most of the cases, it is actually caused by a confusion between Monitor sections in xorg.conf and RandR 1.2 outputs. With a default config, RandR 1.2 drivers will basically associate the unique Monitor section with their first output, even if not enabled. Bug #461501 is a good example of this issue. RandR 1.2 drivers (intel, ati, nv for G80, mga in experimental, radeonhd so far) require that you specify which output is attached to which monitor. If you have a Monitor section with identifier "Foo" connected on output "BAR", then you want the following in your Device section:

    Option "Monitor-BAR" "Foo"

Or (easier), just rename identifier "Foo" into "BAR". You need to add such a section for each output that you want to tweak (DisplaySize, ModeLine, PreferredMode). Then your tweaks will be applied to the right monitor/output. See the HowToRandR12 sections III.1 and III.3 for details.

One year ago, I started triaging the X.org BTS (by replying to #163057 iirc). I closed almost 1600 bugs since then, bringing the remaining ones to about 900 today. I am kind of proud of Ender's graph (when the URL works...). Even if the actual BTS triaging is done now, I still try to take care of X.org bugs. And it's not that easy unfortunately... Almost 650 new bugs were opened this year against X.org packages. 250 of them are already fixed, more than one hundred have been forwarded upstream. It doesn't mean that 300 bugs still apply to our packaging. Most of our X packages are simple (apart from the xserver-xorg postinst mess that David is cleaning). But, there are lots of problems that we have no clue about, or that miss some info because people can't upgrade to unstable, ... I am sometimes tired of getting so many bugs without being able to do much about them. Maybe because upstream doesn't care enough about some problems (lots of drivers are unmaintained and get broken more and more when new features are added for a couple more important drivers). So, I sometimes tend to concentrate my work on what I like and trust. Some people noticed that xserver-xorg-video-ati get very often updated these days (6 uploads in the last 20 days). Of course, the reason is that I own a r300 board :) But also because its upstream devs are very good, it's very nice and easy to work with them. Of course, we have a lot of work and few people to do it. That's kind of sad since playing with X is very interesting. Most users are very happy when discovering things like RandR 1.2 or Compiz. Getting a chance to test them early and understand their internals is very cool. But, as said in some other posts, hacking on X.org doesn't seem to look fun. If you're interested anyway, taking care of the bugs is a very easy way to learn a lot. I had no clue about X one year ago and I learned a lot by taking care of the BTS. I would be glad to get some help now :)

I finally uploaded the ATI RandR 1.2 driver to unstable. This is xserver-xorg-video-ati 1:6.7.197-1. Lots of people were already using the experimental packages to get the RandR 1.2 support. And it looks pretty good, at least not worse than the obsolete 1:6.6.193-3 that has been in unstable during the last months or the prehistoric 1:6.6.3-2 still in testing. Things are (again) moving fast upstream. Right after the 6.7.197 released, they merged 2 important branches in master:

• atombios-support brings support for r500 and r600 boards using AtomBIOS. Yes, this is for the same boards as the ones supported by the old avivo and the recent radeonhd driver, but the implementation differs a lot. See Dave Airlie's blog entry.
• zaphod-lolz brings back support for the old Zaphod mode that lots of people have been missing. If you like having two screens (:0.0 and :0.1), you might like this. See Dave Airlie's blog entry for some details.

Given how important all this is, I also uploaded a new snapshot of upstream master into experimental. This is xserver-xorg-video-ati 1:6.7.198~git20071221.be7f8fd3-1. Merry Christmas! Update: Looks like this is Radeon day. A new version (1.1.0) of the radeonhd driver has been released, so I just uploaded it to unstable too.

Once ftp-master is back, several important X updates should arrive. The first one is a Xserver pre-1.4.1 snapshot (the official 1.4.1 is expected soon). It will bring many input fixes, for instance for broken LEDs (reported 12 times). Unfortunately, there are still some input bugs in there, for instance upstream bug #13114 which is kind of annoying (I can't play xmoto anymore). A new release of the Intel driver is coming soon. The first release candidate, 2.1.99, has been uploaded to experimental. The most noticable changes include some fix for VT switch and the support for some rare LVDS chipsets (ch701x). Also EXA is now enabled by default, which is good news since XAA had some bugs that won't ever be fixed (for instance when using XV in Compiz, see upstream bug #10912). Before 2.2 is released, we might get a fix for backlight support which got fixed on some boards while broken again on some others in the past (see upstream bug #11527). The new Mesa 7.0.2 release might be worth taking a look too since it brings many fixes, including a working __gluInvertMatrix() which should solve many GLU-related problems that have been reported, and some fixes for several Blender crashes. Not much activity on the xserver-xorg-video-ati side recently. But given how well it works these days, I am seriously thinking of uploading the next snapshot to unstable (1:6.6.193-3 didn't help a lot there).

Given the massive changes implied by multiple RandR 1.2 drivers being available, and looking at how many bugs were reported because of wrong X configuration, I wrote a RandR 1.2 guide on the wiki. It should at least be useful for people upgrading from old drivers...

I just upgraded my X server at work. Oh my god. I had a working configuration with multi-head (without Xinerama). I was happy. Oh yes I remember yesterday everything was so fine. And now it screwed everything up. I've got 3 LCD screens and 2 Matrox G450 PCI cards. After restarting X.Org 7.3, all I've got was two screens (connected on the first card) in clone mode. Very useful.... After 1 hour of googling I managed to use xrandr to setup a Xinerama display on this 2 screens.... I don't want Xinerama and I want my other Matrox card back. I don't know why but reading Brice Goglin post around, I understand that the old behaviour is no more available. GREAT, now I'm stuck with Xinerama that a lot of window managers don't handle correctly and I still don't know why my other Matrox card doesn't work. Is X.Org 7.3 a piece of shit or what?