Brice Goglin's Blog

01:52 - Debian/X.org notes - i865 fixed, Xserver 1.6 entering testing soon

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.

09:28 - Debian/X.org notes - Quick Updates

Another round of quick notes about X in unstable while the XSF team is on vacation.

Intel Driver and PAE kernels

If upgrading to xserver-xorg-video-intel broke X or made it very slow, make sure you are not using a PAE/bigmem kernel. The Intel driver now enforces UXA for acceleration. But UXA requires GEM support in the kernel, and GEM is not compatible with PAE before 2.6.31. So if you have PAE in your kernel (CONFIG_HIGHMEM64), i.e. for instance if you are using a -bigmem kernel, your Xorg.0.log will say:

  (EE) intel(0): [drm] Failed to detect GEM.  Kernel 2.6.28 required.
  (EE) intel(0): Failed to become DRM master.

Obviously, 2.6.30 should be enough when 2.6.28 is required. But 2.6.30 with PAE is not.

Return of the DRI2 breakage

It looks like the DRI2 breakage in Xserver 1.6.1.901-3 wasn't enterily fixed in 1.6.2. According to #538637, Xserver 1.6.2 didn't work with KDE4.2 effects when built against Mesa 7.4.4. Fortunately, Mesa 7.5 is in unstable now, and the new Xserver 1.6.2.901-1 was built against it.

16:41 - Debian/X.org notes - Intel 2.8.0 in Sid, enforces UXA and DRI2

The Intel driver 2.8.0 has been uploaded to unstable. The biggest changes in there is that support for DRI1, XAA and EXA has been dropped. It means that the driver now always uses UXA and DRI2 now.

KMS (Kernel Modesetting) is still optional (and the non-KMS crash from 2.7.99.902 has been fixed in 2.8.0). But you might want to use a recent kernel, which means 2.6.30 or 2.6.31-rc.

There are still some problems with UXA/DRI2 on old boards such as my i865. So if you encounter any big problem, you might want to downgrade to driver 2.7.1 (some old packages are available at here) and switch away from UXA.

00:54 - Debian/X.org notes - DRI2 fixed in unstable, and more

A couple news from the mostly-offline X Strike Force team:

The previous upload of xserver-xorg-core (2:1.6.1.901-3) severely broke DRI2 and more. 2:1.6.2-1 has been uploaded, it should hopefully fix all this.

Intel driver 2.7.99.902 has landed in experimental as well.

As expected, the arrival of Linux kernel 2.6.30 helped a lot. So if you had problems, especially performance problems with 2.6.29, make sure you try 2.6.30. If you're playing with kernel modesetting, upgrading to kernel 2.6.31 and latest intel driver in experimental is probably a good idea as well.

Update: Intel driver 2.7.99.902 is broken when NOT using Kernel Modesetting, see #537052.

09:07 - Debian/X.org notes - Why some X drivers like firmware-linux

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.

10:41 - Debian/X.org notes - Howto get DRI2 on Debian?

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 and then play with transset to put transparency on 3D applications.

Update: Added kernel requirements, added how to make Compiz not slow, removed -a from xcompmgr.

10:25 - Debian/X.org notes - X behavior changes in experimental

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 :)

22:00 - Debian/X.org notes - Howto Input-hotplug?

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

Ignoring a device

If you do not want Xorg to use one of your input device, in the past you would just have not talked about it in xorg.conf. Now, hal notifies the server of all devices, and all of them are enabled by default. To disable it, you can use something like:

  <match key="info.product" contains="myname">
    <remove key="input.x11_driver"/>
  </match>

For more information

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, added a way to ignore a device, and organized things in sections. Thanks to everybody's comments.

21:56 - Debian/X.org notes - Xserver 1.6, Intel 2.6.1, ... what's up in XSF?

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

14:44 - Debian/X.org notes - xserver-xorg-video-radeon in unstable

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.

13:29 - Debian X.org notes - X.org in Lenny (and more)

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.

15:52 - Debian X.org notes - Radeon Textured Xvideo in experimental, r128 and mach64 split out

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

11:02 - Debian X.org notes - No, DisplaySize and DPI are not (always) broken

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.

12:53 - Debian X.org notes - One year of X.org BTS maintenance

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 :)

08:55 - Debian X.org notes - ATI 6.7.197 in unstable, AtomBIOS r500/600 support in experimental

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.

13:45 - Debian X.org notes - Upcoming Xserver 1.4.1, Intel 2.2 and friends

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

13:04 - Debian X.org notes - RandR 1.2 guide

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

08:23 - Debian X.org notes - RadeonHD driver in experimental

The driver for ATI r5xx/r6xx boards that Suse developers have been working on for about 2 months with the recently released specifications has been pushed to the freedesktop repository as xf86-video-radeonhd. So David packaged it and uploaded it in experimental as xserver-xorg-video-radeonhd.

Of course, the driver is still very young, probably similarly stable than the now deprecated xserver-xorg-video-avivo. So if you want to test it, debug it and get it to work, you might want to join the corresponding IRC channel (#radeonhd on Freenode) and subscribe to the mailing list (radeonhd on the OpenSuse server, details are in the topic of the IRC channel). If not on IRC or on the mailing list, bugs should be reported at http://bugzilla.freedesktop.org, product xorg, component driver/radeonhd.

23:39 - Debian X.org notes - MGA driver gets RandR 1.2 too

Now that David pushed X.org 7.3 to unstable, experimental is available again for release candidates. So I just pushed xserver-xorg-video-mga 1.9.99. This is the first release candidate of the MGA driver with RandR 1.2 support. For the record, it means enabling/disabling/resizing/moving outputs dynamically.

If you're planning to test it, you might want to read the upstream announce first. Tilman Sauerbeck did a very good job, but he doesn't have all kinds of board to test this. At least, the dual DVI G550 is known to not work. It might be good to report problems, either to us or directly to Tilman (IRC might be faster than reporting a bug...).

As usual, you might want to refer to this and this to update your xorg.conf for RandR 1.2, and also this post if the server doesn't choose the right mode by default.

22:04 - Debian X.org notes - Got specs?

So, this time it was for real! AMD really meant it when they announce the release of specifications of ATI boards last weeks. During XDS2007 at Cambridge, we received the actual specs, 2 PDFs files, 460 pages for the M56 (Mobility X1600, r5xx board) and 436 pages for rv630. The files are now online, but I am not going to give the link here since the web server already suffered too much today (and the URL is easy to find anyway).

People should NOT understand this as if we were going to get an open-source driver for all ATI boards next weeks. First, these are only 2D specifications for r500 and r600. 3D specs are expected in a couple weeks once AMD fixes the remaining issues. r300 specs might arrive later. Also, these specifications are pretty hard to use, as expected. There are something like 9000 registers in r6xx boards, and these PDF files are just description of these registers. It's of course far away from being a "How-to write a driver?". So if you want to help, there will be lots of things to do.

We also got a demo from some Suse guys of the driver there are working on. They got these specs about 2 months ago. And they already have some part of modesetting working. It means you might get your X server to start. There are about one hundreds different chipsets with their own quirks, so still lots of work to do. And then lots of performance things, 3D, ... to do. This driver is called "Radeon HD" so far. It will remain separated for now, but it might end up being merged with the upstream ATI driver later since the 3D engine are very similar (I personally hope it will happen).

The reverse-engineered Avivo driver is dead now then. Fortunately, Jerome Glisse has been aware of the event for a couple months now, so he didn't waste to much time working on it. xserver-xorg-video-avivo will remain in Debian experimental until the new driver arrives. The good thing about Avivo is that it (and the ongoing Nouveau driver for Nvidia) led to the development of very nice reverse-engineering tools (revenge, renouveau, mmio trace, ...). They will be very useful for other graphic boards, or even some network hardware.

Of course, many thanks to AMD for making this happen!