Brice Goglin's Blog
Jul. 14th, 2009
A couple news from the mostly-offline X Strike Force team:
The previous upload of xserver-xorg-core (2:126.96.36.1991-3) severely broke DRI2 and more. 2:1.6.2-1 has been uploaded, it should hopefully fix all this.
Intel driver 188.8.131.522 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 184.108.40.2062 is broken when NOT using Kernel Modesetting, see #537052.
May. 11th, 2009
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.
Feb. 14th, 2009
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.
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 :)
Jan. 24th, 2009
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.
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).
If you have a touchpad and want to use the synaptics driver,
installing the xserver-xorg-input-synaptics will bring
another fdi file.
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
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.
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.
The release Xserver 1.6 is expected in the near future. 1.6-rc1 (220.127.116.111) 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 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.
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).
Jul. 29th, 2008
After the addition of ioremap_wc() in 2.6.26, MMU notifiers have now been merged in 2.6.27-rc1. It means that everything we have been wanting in the past to help HPC support is finally available upstream. We thought IB being merged (back in 2.6.11) would make things go fast, but it looks like these important features were not that obvious to people that did not work on HPC for a long time.
Back in 2004, I was trying to get a safe registration cache working in the kernel for distributed storage over Myrinet. User-space regcaches are known to be a mess because they need to intercept malloc/free/munmap to invalidate cached segments. It works sometimes, but it is often a mess. In the kernel, you just can't intercept anything. So I wrote a patch called VMASpy which allowed other subsystems to be notified when part of a "registered" VMA is unmapped or forked. I never submitted it since it couldn't be accepted unless somebody in the kernel (i.e. IB) used it. Given posts like this, we see that IB people weren't conscious of the problem (nowadays they are interested but something in the IB specs apparently prevents them from using this).
KVM needed some kernel support for its shadow pages, so MMU notifiers were written by Andrea Arcangeli (thanks a lot to him for keeping working on this despite many people not liking it). After a couple months of trolls, here we go with 2.6.27-rc1, we can now register a notifier per mm_struct and get a callback when part of the address space is unmapped. The implementation is very different from my VMASpy and of course much better :) But the final API provides similar features, so it should be great news for people working on registration caches or so.
The myri10ge driver (Ethernet driver for Myri-10G boards) is broken in 2.6.26. It may not do anything at startup. It may also oops when opening the interface. The breakage appeared because the big pile of updates sent for 2.6.26 has been only partially applied (multislice RX is only applied in 2.6.27), and I did not test it intensively enough. Apologies.
2.6.27-rc1 is not affected by the breakage. And 2.6.25 works fine as well. Two patches have been sent to the stable release team for inclusion in 18.104.22.168. In the meantime, you may use Myricom's tarball, take the driver from 2.6.27-rc1 or from 2.6.25, ... or just not use 2.6.26 :)
Jun. 22nd, 2008
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.
Jun. 14th, 2008
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.