The big fat X.Org supermodule

I've been using a git supermodule for nearly 2 months now and it works great. So here it is, do with it what you will.

git://people.freedesktop.org/~whot/xorg.git

It includes all the modules I care about to get a server running.

The advantages of git submodule are simply that I have a known working tree I can easily share between my test machines. Whenever I update a component, I can test it and easily revert back to the previous working version if needed.

Advantages for you: if you pull from that tree, you're running a version that at least compiles and runs on my hardware. That doesn't mean it's bug-free of course, but it's a start if you want to get into X server testing.

Disadvantages: I update input stuff often, other stuff when needed. So if you care about the latest and greatest graphics patches, you will need to maintain your own tree. Such is life.

Updating is easy: git pull and git submodule update.

The git submodule interface is missing one important feature to make this workflow better (automatic rebasing), but that'll hopefully be fixed in a future git version.

git-format-patch for a single commit

One thing that always annoyed me was the weirdness of getting a patch from a single commit somewhen back in the history. Turns out I was just ignorant and reading the man page actually helps, git-format-patch accepts a -<n> option, where <n> is the number of patches you need since the commit (inclusive).

So, because I'm a big fan of tig, add this to your $HOME/.tigrc:

bind generic E !git format-patch -1 %(commit)

Start tig, mark the patch you want, hit "E" to get a nice patch file. Doesn't get much simpler than that.

[update Jun 05 2012]
As SEJeff and Michael point out in the comments

git show $sha

shows a single commit. The output of git show is different to git format-patch though (it cannot be applied via git-am).

Zapping the server

Some amount of bad blood was spilled last week (read LWN's writeup for a better summary than I'll provide here).

In short, zapping through Control-Alt-Backspace was disabled and some people are not happy. It is a useful combination and I (need to) use it regularly. Should it be enabled by default? No.

Let's think about this: Assume that the server never supported zapping in the past. Now we add a feature that immediately and without asking terminates your session, shuts down all applications, logs you out, brings down your wireless network in the process, shuts down your VPN and generally makes the computer giggle at you. Of course, we documented this shortcut in the Xorg man page.

I guess we would see the same flame-wars. Potentially even by the same people.

The correct thing to do for a UI feature like this - like with any UI feature - is to consider who will benefit from such a change and make it accessible to those. Experienced users will benefit from zapping. So make it accessible to them. Those who want to use the computer but not have to know about it's internals should not be able to accidentally trigger it. Not the other way round.

Anyway. The correct solution was rather easy, and thankfully, Julien Cristau has written the patch for xkeyboard-config and there's a patch for the X server too. Which, amongst from other things, shows that time spent reading and replying to flame-wars is spent less usefully as time spent writing patches.

The following command enables server zapping.

setxkbmap -option "terminate:ctrl_alt_bksp"

I'll leave it as an exercise to the reader to figure out how to click the matching checkbox in the keyboard configuration tools.

So for the future: If you are unhappy with a particular change, take the issue to the appropriate mailing list and/or persons, in polite tone and based on real arguments (made-up facts only count when you're on TV) and it may just get fixed. It's pretty much a no-brainer, but maybe even such a minimum requirement is too high. In the end, Julien's patch was the reason why the whole issue got sorted out, not the flame-wars.

Rawhide users:
There's a dependency chain in keyboard configuration that made me weep inside a little. Update to fedora-setup-keyboard-0.3-4, xkeyboard-config-1.5-5 and xorg-x11-server-1.6.0-18, then restart HAL and restart X. Zapping will work on a plain X server and in gdm, but only if enabled in the gnome session.

[update]
Option DontZap is restored with this change to it's previous functionality - it disables zapping altogether (if enabled). Even if DontZap is disabled (the default), zapping only works if it is present in the xkb map.

Synaptics 1.1 and what your touchpad can do now

I just stumbled over this and I realized that I never wrote about the synaptics driver. So, here's a list of things that have changed recently with version 1.0 and 1.1.

• Perhaps the most important changes have to to with auto-scaling. Synaptics obtains the touchpad dimensions from the kernel and adjusts speed, acceleration, the edges and more depending on these dimensions. As a result we support a lot more models and touchpads should just work and feel approximately the same on the different touchpad models. More or less, anyway.



• Multi-touch support and two-finger scrolling: the driver detects whether the touchpad can detect multiple fingers. Not all touchpads can do this*, for example my T61 has one that only does single-finger detection. If your touchpad has multi-finger support, the driver enables two-finger scrolling instead of edge scrolling.



• Tapping is disabled by default. I've gotten some flak about this but I maintain that it is the better choice. Tapping is enabled for those touchpads that don't have physical buttons though.



• synclient and syndaemon updates to device properties. Both programs do not require the SHM area anymore and thus also just work without extra configuration. So any option available in the synaptics man page can be modified at runtime.



• Touchpad integration into gnome**. With the help of Matthias Clasen, we took the Ubuntu patches, fixed/updated them, pushed them into rawhide and sent both of them upstream. So gnome-mouse-properties now has a touchpad tab for the basic configuration settings. In rawhide anyway, and hopefully also upstream soon.
  

There's a lot of minor changes, but these are the big things.

* Unfortunately, the driver doesn't export yet whether the device has multifinger support or not. The only way to be sure is to check the Xorg.log and look for the line "(II) SynPS/2 Synaptics TouchPad: buttons: left right middle". If this line also says double and/or triple, your touchpad can detect two finger and/or three fingers.


** I started by fixing gsynaptics in rawhide, but that's now discontinued.