Brice Goglin's Blog

21:10 - Debian X.org notes - X.org 7.4 plans - What we expect for Lenny

The release plan for Xserver 1.5 and Xorg 7.4 was discussed during the X.org Developers' Summit in Cambridge (September 10-12th). This is what we expect to ship with Lenny, so here are some details about the upcoming.

Timeline

As usual, there will be a 6 months release cycle. So Xorg 7.4 is expected on March 1st, 2008. There won't probably be any new Xserver release before that since some changes (already merged) require all drivers to be updated anyway. So Xserver 1.5 is expected on the same date.

Since there are already some known problems in Xserver, they also plan to release Xserver 1.4.1 on November 1st.

PCI Rework

The master branch of Xserver already contains the long-expected pci-rework which is supposed to fix all the PCI domains and other non-trivial PCI hierarchy support (important for ia64, but also for some powerpc and sparc users).

RandR

People having Intel, ATI or recent Nvidia boards learnt to love the RandR 1.2 extension which provides the ability to enable/disable, resize, rotate, move outputs within a single big virtual screen. More transformations should be possible with RandR 1.3. Hopefully, there will also be some standardization regarding output names in various drivers, or at least a way to retrieve the type of each output (LVDS, DVI, VGA, TV, ...). And the server should get an abstraction object to describe GPUs, which might make the support for multiple boards easier.

Input

On the input side, XKB 2 and XGE should be merged, which shouldn't be really visible to end-users but should make internals much better. Then MPX (Multi-Pointer X server) might be in Xserver 1.5 too (if all semantics issues get fixed first). It would mean support for multiple independent keyboard/mouse pairs or so. See the MPX page for details.

Compositing

Compositing still gets a lot of attention. Several distributions are actually thinking of enabling Compiz by default. EXA (the new acceleration architecture that has been designed for compositing) got improved a lot in Xserver 1.4. Several drivers including Intel and ATI r300 already work great with EXA (no need to use XAA + XAANoOffscreenPixmaps anymore) which means Compiz works very smoothly, even when resizing windows. XAA won't be removed soon though since lots of things needs to be fixed before that. There are also several videos available online, like this one.

But one big piece is still missing for compositing: directed rendering to redirected windows. So far, if you start glxgears in Compiz, you will see that the gears completely ignore wobbli-ness of windows, other windows overriding them, cube rotation, ... they keep rendering of top of everything without any effect. Getting true support for compositing such windows requires lots of work in all parts of the DRI stack. Kristian Høgsberg got it to work (and we even get a great demo). See Kristian's blog for details. Upstream devs are now working on integrating all modifications nicely in upstream Xserver, drivers, DRM module, Mesa, ... Once this works, you can get GLX_EXT_texture_from_pixmap for both direct and indirect rendering, and full support for GLX 1.4 in the server (only 1.2 is supported as of now).

Also, redirected windows (let's say a wobbly window on a side of Compiz' cube) should get input events correctly thanks to input transformation in Xserver 1.5 (event coordinates will be converted into the redirected window coordinate space before being passed to the client application).

Kernel-related reworks

Compositing improvements actually require a large rework of the memory management in the server. Basically, we need a global management for both 2D and 3D object allocations, so that you can get both to work fine without having to change config options (things like XAANoOffscreenPixmaps or FbTexPercent). All this is related to the TTM (Translation Table Maps, see these slides for details) which has been under development for a while. It requires to change the interface with the kernel DRM modules, and it won't happen before 2.6.24. The Xserver part of the work is not big, so it might still be done before 1.5 is released. Fortunately, once all this is ready, people should stop complaining about memory allocation failures, Compiz being slow because one option is not enabled by default, ...

Another hot topic in the X.org/kernel area is about moving modesetting in the kernel. When you get a kernel panic, you only actually see it if not running X (or if logging kernel messages through the network). So your machine freezes, you don't know why, you have no way to know, and you just reboot. Getting panic messages on X would be much better. To do so, the kernel needs to now which mode is currently in use on the monitor and then it will render the message on the framebuffer. This require lots of work, so it will unlikely be in Xserver 1.5 though.

Miscellaneous

Xserver 1.5 will also contain XACE (security framework), the cleanup of the ABI (explicit _X_EXPORT required), and possibly glucose (OpenGL acceleration for X, see Zack Rusin's blog).

I asked whether there was actually some work on building the GLcore server module as a part of Mesa so that building Xserver does not require the whole Mesa source anymore. People seem to agree the current situation is a real pain for distributions and we should make this change happen. But the actual work has to be done in Mesa anyway, we'll see what happens.

15:51 - Debian X.org notes - Known issues in Xserver 1.4

xserver-xorg-core 2:1.4-1 entered experimental yesterday (and should arrive in unstable in the near future). This Xserver 1.4 brings some nice improvements (like input-hotplug and better EXA), but it also has a couple minor bugs that I guess you will quickly notice. So before I get dozens of bug reports about them, here's a list with links to existing bug reports:

• X crashes during exit, causing the VT console to not be restored properly. Not directly visible when using a display manager since it will restart X before you notice a problem. But very boring when starting X manually (for instance with startx) from a VT console. Reported at #440547, fixed in 2:1.4-2.
• The LEDs (caps-lock, ...) do not work anymore. Upstream is aware of the problem but there are no known fix as of now. Reported at #442887.

Nothing really bad so far then. Upstream plans to release Xserver 1.4.1 on November 1st. It's far from here, but it means there will be fixes committed on the server-1.4-branch in the meantime, so it will be easy for us to upload intermediate releases if needed.

00:03 - Debian X.org notes - Which ATI driver version for Sid?

As you may have noticed, X.org 7.3 has been released yesterday. This means that the new Xserver 1.4 will land in unstable in the near future. All input and video drivers will have to be rebuilt since the ABI changed. Which xserver-xorg-video-ati version do you want us to rebuild and upload to Sid?

The latest upload of xserver-xorg-video-ati (6.6.3) to Sid occurred on October 14th 2006. This release was pretty solid, but it might be too old to deserve another rebuild with a recent Xserver. No new stable release happened in the meantime. Several release candidates arrived in experimental (6.6.19[123]), the latest one was pretty stable too, with better support for some boards. Then, the randr-1.2 branch got merged upstream and a new cycle of release candidates started (6.7.19[12]), but I personally think they are NOT stable enough for Sid (various lockups here).

So I think we will upload the current head of the ati-6.7-branch in Sid. It means, 6.6.193 with several fixes. The new RandR-1.2-aware + TV-out-aware driver (6.7.192) would remain in experimental for a little while.

If you want to give a try before the big upload of xserver-xorg-core 1.4 and updated drivers, a bunch of them are available on alioth, see this.

08:53 - Debian X.org notes - ATI 6.7.191 with RandR-1.2 and TV-out support in experimental

No, I am not confusing version numbers. Yes, xserver-xorg-video-ati 6.7.191 follows 6.6.193. Upstream thought it was useless to try fixing the dead-end 6.7 branch (where 6.6.193 came from) since they were already mostly working on the randr-1.2 branch. So 6.7 will probably never happen. The randr-1.2 support has been merged in master and will be released as driver 6.8. 6.7.191 is its first release candidate.

With RandR-1.2 support, you get mode auto-detection and so, as in the Intel driver 2.x. So you may clean your xorg.conf as described here. If you don't get your desired resolution at startup, see here. However, the old dual-head support code (zaphod) is dead, so some people might have to get used to xrandr instead.

Several people will also be happy that the GATOS TV-output support code has been merged and improved to support more cards. You will see a S-video output and you can enable it as usual with xrandr. Not sure how well tested it has been, but at least it seems to work fine on my rv370 (Mobility X300).

Don't forget that this is a release candidate. I personally consider the code as highly experimental since I seem to get more GPU lockups when playing xmoto than in 6.6.193. The code is still under heavy development. Multiple ATI boards have strange behaviors that may not be supported yet (but it shouldn't be worse than in 6.6.193). Fortunately, upstream people are very responsive and doing a great job at fixing bugs, so feel free to ping them on IRC or report a bug directly on http://bugzilla.freedesktop.org.

The package is in now in debian experimental. But the Xserver release candidate is there too. So you will need to upgrade xserver-xorg-core too. If you don't want to do so, just rebuild the driver against unstable, you should just need to downgrade xserver-xorg-dev build-depend to 1.3.0 or so.

13:55 - Debian/X.org notes - Where are Compiz shiny effects?

Several people complained that Compiz 0.5 did nothing for them, while it is supposed to bring lots of shiny effects. The reason is that most plugins are disabled by default. They should be enabled using gconf (for instance using gconf-editor or gconf-tool), in key /apps/compiz/general/allscreens/options/active_plugins.

One correct config may be set with

    $ gconftool --set /apps/compiz/general/allscreens/options/active_plugins \
      --type list --list-type string \
      '[gconf,png,svg,decoration,wobbly,fade,minimize,cube,rotate,zoom,scale,move,place,switcher,screenshot,resize]'

At least gconf, png, svg, decoration, cube, rotate, place, plane, wobbly, scale are usually interesting. But, there are dependencies between plugins, so you need to place them in a correct order in the list. Each plugin has a require option which tells you which other plugins should be loaded earlier.

The decoration plugin is pretty important since it takes care of adding window decorations (i.e. borders). Disabling it is generally a bad idea if you want to get a usable window manager.

There are many other options.

Update: Now that compizconfig-settings-manager is in unstable, you might want to install it and use ccsm to configure all this through a graphical interface instead of playing with gconf.

13:50 - Debian/X.org notes - Testing a new upstream git snapshot of a driver

Replace intel below with your favorite driver name.

To build an input driver such as xserver-xorg-input-mouse, replace video-intel with input-mouse below, and install in /usr/lib/xorg/modules/input/ instead of /usr/lib/xorg/modules/drivers/.

Testing a new upstream git snapshot of the X.org driver may help. It happens for some other drivers too. Instead of waiting for us to package a new version, people can easily test development drivers without having to build a new package or so. Since there is a single (or very few files) file to install, you can just build the upstream source and install manually. Here's what to do for the Intel driver.

You'll need the git source control management tools, some Xorg related macros and some development headers/libraries:

    $ apt-get install git-core xutils-dev autoconf automake libtool
    $ apt-get build-dep xserver-xorg-video-intel

Then you can grab the git tree and enter it:

    $ git clone git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel
    $ cd xf86-video-intel

If you need to try a special branch (for instance xf86-video-intel-2.2-branch) instead of the master branch:

    $ git checkout -b xf86-video-intel-2.2-branch origin/xf86-video-intel-2.2-branch

If you have to test a patch mypatch.diff:

    $ patch -p1 < mypatch.diff

Then you build with:

    $ ./autogen.sh
    $ make

Once it is built, run make install prefix=/usr as root (or copy src/.libs/*_drv.so in /usr/lib/xorg/modules/drivers/ (or /usr/lib/xorg/modules/input/ for input drivers)) and restart X (logout/login is usually not enough, Ctrl-Alt-Backspace or xdm/gdm restart is ok).

To revert to your old driver, just reinstall its package with aptitude reinstall xserver-xorg-video-intel or dpkg -i xserver-xorg-video-intel_foo.deb.

13:39 - Debian X.org notes - Autoconfiguration with xserver-xorg-core 1.3

Thanks to Xserver 1.3 autoconfiguration, very few lines are required in /etc/X11/xorg.conf now. Only the following might be required:

• Module section if the default modules are not ok with you (it should)
• keyboard InputDevice section to choose your keymap (unless american qwerty is ok for you)
• Device section if you really need a specific option such as EXA, ...
• Screen section with Display subsection for a Virtual line for xrandr multiple heads
• Screen section to change the default depth
• DRI section if you don't want DRI devices to be available to all users (default mode is 666 now)
• Extensions section to enable Composite (for AIGLX stuff such as Compiz)

Actually, it is possible to just remove the xorg.conf file entirely, Xserver 1.3 will probably boot anyway and give you a working setup (apart from the US keyboard layout).

13:21 - Debian/X.org notes - Intel driver 2.0 does not find my nice mode/resolution

The way to choose a resolution in xorg.conf changed with randr-1.2. With earlier X servers and drivers, you had a Mode option with a list of resolutions in your xorg.conf (and maybe some ModeLine options to choose the refresh rate). All this is almost useless nowadays with randr-1.2, you can drop all these options. The driver/server will detect all modes automatically and choose the preferred one (if the monitor says which one it prefers). The available modes for each outputs may be seen by running xrandr without arguments.

However, if there is no preferred mode or if it is not the one you want, you can change it for the currently running X server with the following command. Such a command may for instance be added to your .xsession file so that it is done every time you start the X server.

    xrandr --output VGA --mode 1280x1024

But, it may also be done automatically through the server configuration. This is one of rare cases where ModeLine is still useful these days. Assuming you want to force 1280x1024 at 75Hz at startup, add something like the following to the Monitor section of your xorg.conf:

    Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync
    Option "PreferredMode" "1280x1024_75.00"

The ModeLine line may be obtained by looking at your current Xorg.0.log if the mode is already detected (when it appears in the output of xrandr). Or you may generate a new one using:

    $ gtf 1280 1024 75
    Modeline "1280x1024_75.00"  138.54  1280 1368 1504 1728  1024 1025 1028 1069  -HSync +Vsync

See this bug for an example.

13:08 - Debian/X.org notes - Modesettings/RandR-1.2 improvements with Intel driver 2.0 and others

RandR-1.2 and modesetting enable autodetection of modes (resolutions, modelines, ...) in drivers. The Intel driver 2.0 is the first one to support this, nv came soon after for G80, ati and mga will arrive in the near future.

They make lots of configuration useless, so /etc/X11/xorg.conf may be simplified:

• drop ModeLine, HorizSync and VertRefresh from the Monitor section
• drop Modes line from the Display subsection

Additionally, thanks to the X server autoconfiguration capabilities, most trivial sections become useless. The only really required one for a regular setup is the InputDevice section for the keyboard since you still need to configure the layout (there is no way to detect this automatically).

Regarding the Intel driver 2.0 itself, note that the i915resolution package become useless (it modifies BIOS tables that the new driver does not use).

12:56 - Debian/X.org notes - Dual-Head config breaks with xserver-xorg-video-intel

The Intel driver 2.0 brings RandR 1.2 support, enabling dynamic multiple heads configuration. Some old Xinerama/dual-head configs cause the server to crash at startup. Basically, the new driver only supports the new config syntax, and it might not ever get fixed.

To solve this problem, you need to update your /etc/X11/xorg.conf:

• drop dual Device/Screen/Monitor sections, keep a single one
• drop MonitorLayout option and Screen lines from the remaining Device section
• drop dual Screen lines from the ServerLayout section
• drop RightOf/LeftOf indication to the remaining Screen line in ServerLayout section
• add a Virtual 2048 2048 line in SubSection "Display" to create a large virtual screen where physical monitor will be placed (note that boards <= i945 will disable DRI if you use more than 2048 in one direction)
• use xrandr --output VGA --right-of LVDS to place you VGA screen on the right of your internal LCD (see xrandr manpage for details)

See this Debian bug for an example for configuration update and this upstream bug.

Note that other driver are being ported to RandR-1.2 (nv 2.1 for G80, ati and mga coming soon), so the bug might be non-Intel specific in the near future.

12:48 - Debian/X.org notes - Slow xserver-xorg-core 1.3 + free ATI driver + EXA

When xserver-xorg-core 1.3 entered unstable, we got several reports from people complaining that their ATI system became very slow (with the free ATI driver, i.e xserver-xorg-video-ati). It was caused by AccelMethod being set to EXA in /etc/X11/xorg.conf. Removing this configuration line or switching to the XAA acceleration method fixes it.

EXA has been supposed to bring many improvements for a while, but it is still not mature enough to surpass the old XAA in all cases. EXA is designed towards compositing (Compiz, Beryl, ...). But, under some circumstances, EXA is even slower than no acceleration at all. It depends a lot on the driver, the Intel one is very good, the ATI is not yet. The upcoming Xserver 1.4 might improve all this.

Fortunately, unless you want to use Compiz or so, there's probably no absolute reason to use EXA for now. So reverting to XAA (and adding XAANoOffScreenPixmap for Compiz) should be fine for most people.

12:35 - Debian/X.org notes

When I get several bug reports about the same problem in Debian X.org (Xinerama broken, ATI slow, keyboard broken, Compiz does nothing, ...), I usually add an entry in the XSF Wiki Release Notes so that I can easily point people to it instead of re-explaining things multiple times. However, this page is probably not read by anybody (especially before reporting bugs). So I think I am going to move its contents to a flux in this blog and put it on Planet Debian so that much more people see it automatically.

16:42 - Debian account

One week after getting a Freedesktop account to push some fixes from Debian bugs into upstream Xorg, I just got my Debian account too. That's very good news since I have been kind of annoyed lately when pushing some fixes in the Debian git repositories without actually being able to upload the corresponding package update in the archive.

When I submitted my application to become a Debian developer 9 months ago, I wasn't sure what I would work on (apart from my own packages, llgal and lltag). Maybe some kernel stuff, maybe something else, we'll see later. Now, looking at what happened on this blog since then, it appears clear I'll probably spend most of my time on the packaging of Xorg. The X Strike Force team is actually great to work with, and working on this software in very interesting (even if it's sometimes horrible to debug/understand/help).

Of course, the Debian account has been created the exact same day several new X modules got released, so I will have several opportunities to upload packages in the next days, as I just did with xserver-xorg-video-ati 6.6.193-1 in experimental.

09:03 - XSF BTS triaging/cleaning done

As announced on the debian-x mailing list, my triaging and cleaning of X-related bugs in Debian in now done. I started in early January, so it took me about 6 months to close more than 1200 bugs. Thanks to Julien Cristau who took care of lots of old wishlists recently, there's now about only 750 bugs remaining. That's still huge, but at least we know most of these bugs are real and still reproducible. 150 of them have already been notified to upstream developers. I am going to look at lots of them more deeply in the near future.

The result of the triaging/cleaning is visible on the above graph (although it misses about 3 weeks in January, back when there was more than 2000 bugs open). Per source/binary package and per bug number statistics on closed bugs are also available here.

As we say in France, one good news never comes alone. So, the same day I finished this, my freedesktop.org account has been created. So I am now in position to commit things directly in upstream X.org instead of forwarding lots of our Debian bugs. I started fixing some very minor typos in various manpages, I'll look at less trivial things soon.

08:18 - 1000 XSF bugs closed, 1000 to go

It's been 5 months since I started cleaning the X-related bugs in Debian. There was about 2000 bugs open at this time, I just closed my 1000th one. I have set up a page with statistics about all already-closed bugs.

Unfortunately, there are still about 1000 bugs open, and I won't be able to close many of them since about 800 of them have already been confirmed as still happening by their submitter. The status of the remaining pinging/closing is regularly updated on the Wiki. I expect to finish pinging all remaining bugs within a month and closing within 2.

Thanks to Ender, the bug count may be observed from there. It shows there are still about 750 important or normal bugs, and 400 minor or wishlist. More than 120 of them have already been forwarded upstream, and more than 110 have been marked as "wontfix" since we consider that they do not matter.

08:31 - Debian packages for ATI driver RandR 1.2 branch, goodbye MergedFB

Since Xserver 1.3 (xserver-xorg-core 2:1.3.0.0.dfsg-*) entered Debian unstable, there have been several bug reports about dual-head setup (with MergedFB) not working anymore on ATI board (with the free ATI driver). This driver has not been updated upstream for a while. Officially, it is still at 6.6.3. There is a release candidate snapshot 6.6.191 (currently in Debian experimental), but it is not clear that it solves all these problems, and it seems that it even introduced some new bugs. People need to wait for the final 6.7 driver release to get this fixed (but it might take time). So people basically need to either downgrade to xserver-xorg-core 1.1.1 (the one in Debian Etch/stable and still in testing), or stop using dual-head setups, until ATI driver 6.7 is released.

Funny things will arriver after 6.7. There is currently a very active randr-1.2 branch in the upstream git repository to add support for RandR 1.2 extensions in the ATI driver. It means that the MergedFB hack will be removed and replaced with a standard way to add/remove/place multiple monitors at runtime (using the xrandr command). It already works with the Intel driver 2.0 and people really like it (managing multiple outputs in Xorg with free drivers has always been a mess before Randr 1.2). This support in the ATI driver will be merged in upstream master branch after 6.7 is released. So, my plan is to upload 6.7 to unstable as soon as it is released and then put this randr-1.2 branch into experimental.

However, since 6.7 might not arrive very soon, while this randr-1.2 branch already works pretty well, I build an unofficial Debian package of it regularly (say once a day). If anybody wants to try them, drop me an email, I'll tell you where to take the package (the URL isn't stable enough to be released here for now).

01:27 - XSF BTS cleaning

There are several projects in Debian whose BTS needs to be cleaned: during several years with many packages and users, they got tons of bug reports, some being unreproducible, fixed later without being closed, ignored, fixed by mistake, ... it is quite horrible to manage. For instance, the BTS of KDE contains almost 1000 bug that are still open. When you want to report a new bug, are you really going to read hundreds of bug titles to be sure your bug has not been already reported?

The TODO list of the Debian X Strike Force (the guys working on Xorg and co. in Debian) contains "Clean out the BTS so that it's usable for mortals" for several months now. So, I started working on it. I began with the bugs reported against the old xserver-xfree86, i.e. a large part of the old Xfree86-related bugs. There were almost 500 bugs open (the less you see there, the more work I did :)). So, I am currently pinging the submitters to know whether their problem still occurs with a recent Xorg. Most of these bugs will probably be closed in a couple weeks, especially because people email address are often invalid or they don't have the hardware to reproduce anymore. Then, there will remain about 1300 other X bugs :) This work might be considered boring, but I am actually not so bored right now. We'll see in a couple weeks, I might have changed my mind :) At least, sending dozens of mails like that helps my Google score :)

23:58 - Debian packages for Mesa CVS and X.org ATI 6.6.2 Driver

Dave Airlie announced the availability of X.org ATI 6.6.2 driver on Friday. So I gave a try in case it fixed my "Neverball crashes the machine after a couple seconds" problems. The support for my card (Radeon X300) is still under development, so any improvement is welcome. As it did not seem to improve much, after talking on #debian-x, I decided to try with a recent Mesa build. The current one in unstable is very old. The one in experimental is 3 months old.

It was the first time I built a new release of a package. I just took the debian patches for the previous package version and the latest upstream code, and pray for them to merge gracefully. After a couple fixes (and an hour of compilation), I finally got my new bleeding-edge packages. Even if I didn't see any improvement regarding the support of my X300, it is always good for the community to try such things.

In case you're interested:

• the package and sources for the X.org ATI 6.6.2 driver is here;
• the Mesa build (CVS from 2006/08/27) are there;
• you should also upgrade to libdrm 2.0.2 using these.