Brice Goglin's Blog
Mar. 22nd, 2010
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.
Mar. 7th, 2010
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.
Feb. 2nd, 2010
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...
Sep. 13th, 2009
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 for real.
Jul. 27th, 2009
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 184.108.40.2061-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 220.127.116.111-1 was built against it.
Jul. 21st, 2009
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 18.104.22.1682 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.
Jul. 14th, 2009
A couple news from the mostly-offline X Strike Force team:
The previous upload of xserver-xorg-core (2:22.214.171.1241-3) severely broke DRI2 and more. 2:1.6.2-1 has been uploaded, it should hopefully fix all this.
Intel driver 126.96.36.1992 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 188.8.131.522 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 :)
Navigate: (Previous 10 Entries)