I have a laptop with Synaptics touchpad, and one of the biggest annoyances in its implementation is how the "wheel" strips act upon the GUI element where the mouse is pointing regardless of the current focus. It took years to beat focus-follow-mouse people into a marginal submission, yet they still find every crack to seep through, like kerosene. Naturally, this behaviour is not tunable.

Another retardity in this area is the behaviour of the panel. Some genious came up with an awesome idea to flip windows if panel receives a wheel click. The problem with that is, a strip on the laptop is difficult to make to deliver just one click, so the function is useless to me. Also, it is too easy to hit the strip accidentially (which would not be a big deal if not for the enforced focus-follow). So, for one reason or the other, I would like to disable this behaviour. I don't even want to seek excuses for this wish. Just do it. But it's impossible.

So far the only group that displayed a clue in this was, strangely enough, Mozilla. They fixed bugs I filed and in general had an understanding of various input and display technologies, despite only being browser people. You'd think desktop developers would know how a touchpad differs from a wheel mouse.

UPDATE: Chris pointed out in comments that a fundamental reason exists why wheel behaves this way: the extra button events are mouse buttons, and those go where pointer points. I knew it, but it didn't click. I still think that applications should be able to work around this, although perhaps at the cost of some extra events being delivered.

The Penny-Arcade game a.k.a. RSPoD is out today and it bombs on me with: "Could not find a compatible display device // Make sure your display device supports OpenGL 1.2 and the following extensions: ARB_multitexture ... ARB_texture_compression EXT_texture_compression_s3tc". On my system, OpenGL is provided by MESA 7.1-0.29.fc9, and according to glxinfo, some required extensions are missing. That wouldn't be so bad, but I have no idea what how this may be corrected. Hardware OpenGL in the video card, I guess. I have "Radeon Xpress 1100 IGP", which is a low-end mobile card.

UPDATE: Received the following e-mail:

Hi I had the same problem on Vista, because on my laptop the latest installed drivers were the ones I got from windows update. I then installed the ones that came from the manufacturers site and voilà..

. . .

UPDATE: See Anholt's entry.

The issue with random applications failing to start (Firefox, Nautilus) or blowing up (panel, gvim) with BadName took me about 3 months to find (the bug was filed at the end of January). I'm not sure if my fix is any good, need to poke Ajax about it.

So... Wasted a lot of time, learned several mildly interesting things about the code and people involved.

The sad part is how much it takes to start moving around any modern codebase, and that's with the same language and toolchain. I remember times when no part of the system was off-limits, but these days... not so much. If anything breaks in OpenOffice, I'm not even going to try fixing it.

A minute ago I pulled a mouse out of my laptop and the X server crashed. The last messages in Xorg.0.log were:

(EE) Read error: No such device (19, -1 != 24)
(II) Microsoft Microsoft USB Wireless Mouse: Off

This happened because Xorg server 1.4.99.1 force-loads evdev contrary to my xorg.conf, and we all know that evdev is a crash city.

It's a good thing I was born and raised back when this sort of thing was expected every day, so X cannot catch me with a half-entered bug report in a browser. Also, it seems that Vim finally learned to remove dead .swp files without annoying users.

One side effect of the multiply-repo organization of Xorg is that I cannot clone a local repository without editing git_xorg.sh. In kernel, I usually have just one repository which tracks Linus (linux-2.6), then clone and blow away repositories as needed (linux-2.6-ub, linux-2.6.24-rc7, linux-2.6.23-253424). In X, git_xorg.sh has a variable on top which encodes the parent, which is not so bad. But still... Obviously they just do it differently, but how? Keith was saying something about extensive use of branches, so maybe that's it.

Also, since we're on topic, git_xorg.sh itself is not in the git. Now that's really odd, because how do I know if it's changed? I don't even remember now whence I downloaded it.

P.S. Another thing, before blowing away a repo, I would look quickly with "git diff" if anything interesting was left in it. Needless to say, this is impossible in Xorg, so it's just more evidence that they never clone anything.

UPDATE: The BadName below turned out to refer to a font name. My speculation about the DirectColor was bogus. GNOME is not picky!

I mentioned it in passing before, but did not elaborate. I have two identical Rawhide systems, a laptop and a desktop. Everything works dandy on the laptop, but a number of GNOME programs (including Firefox) abort immediately with "BadName (named color or font does not exist)" on the desktop. What could be different?

It looks like the diff of xdpyinfo(1) outputs has a clue:

@@ -78,14 +79,7 @@
     red, green, blue masks:    0xff0000, 0xff00, 0xff
     significant bits in color specification:    8 bits
   visual:
-    visual id:    0x22
-    class:    DirectColor
-    depth:    24 planes
-    available colormap entries:    256 per subfield
-    red, green, blue masks:    0xff0000, 0xff00, 0xff
-    significant bits in color specification:    8 bits
-  visual:
-    visual id:    0x4a
+    visual id:    0x3a
     class:    TrueColor
     depth:    32 planes
     available colormap entries:    256 per subfield

The problem only started hapening after the libpciaccess thing, but it does not tell us if DirectColor existed in the previous X server or not. The libpciaccess rework caused a big gap in my updates, and possibly Cairo or GTK regression slipped into it. In fact, I seem to recall that Firefox worked on top of my patch for SiS, although I'm not sure.

Most of the GNOME continues to work, so it's not the same issues as the abandonment of 8-bit visuals, apparently.

I guess I'll just have to file a bug and see where it takes us, although... what component to use?

From Wincent (via apenwarr):

I knew Torvalds was smart, but seeing as I was never really more than an occasional Linux user I never realized just how smart; I'd thought he was just a good programmer who happened to be in the right place at the right time and had a few good ideas.

I learned it a few years ago, when Linux had a particularly thorny bug somewhere in its process management... Something was leaking on a process exit in case of some obscure error and nobody could figure it out. IIRC even Ingo took a stab and failed, and we all know that Ingo is excellent. Eventually Linus lost patience, went in for a day, fixed it. I had an Advogato diary at the time, but did not post anything, only made a mental note. Linus likes to pretend that he is just a project manager, but it's a sham.

BTW:

Git breaks the mould because it thinks about content, not files. It doesn't track renames, it tracks content. And it does so at a whole-tree level. This is a radical departure from most version control systems. It doesn't bother trying to store per-file histories; it instead stores the history at the tree level. When you perform a diff you are comparing two trees, not two files.

I wonder if X people (e.g. Keith) made a wrong move when they split their tree into a bunch of smaller git repositories instead of having one big repository like kernel does. I guess that it has to do with their phylosophy of being modular (remember, they have a stabe module API which kernel lacks), so they do not foresee code sharing (and thus movement) across their numerous modules and corresponding repositories. Maybe it reduces network traffic at their central git server.

When I read an entry at Chizumatic, I thought that it would be nice to have a PDA with the dictionary, yet use it for lookups off a PC. If we generalize the problem, all we need is to share clipboard between two systems.

Here's how I do it. First, we write a scriptlet, called blitz:

blitzchunk=$HOME/blitz-chunk
# Use a file for trace / debugging. A pipe is too anonymous.
/bin/cat > "$blitzchunk"
# The xclip places itself into background by default, but does
# not daemonize correctly, so ssh hangs. Therefore, we background
# it by hand from shell.
# The option -quiet makes xclip to run in the foreground.
DISPLAY=:0.0 /usr/bin/xclip -quiet -selection clipboard "$blitzchunk" \
  >/dev/null 2>&1 </dev/null &

Then, if you have a clipboard which you want to share, run: xclip -o | ssh targethost.domain.com blitz (normally you'd have it off a menu in your GNOME, "Share Clipboard to...").

The ssh with public key authentication does the job of an RPC method. Also, you need xclip on both systems.

I have to say, blitz is godsent, although I'm the god. I only wonder if I am reinventing a wheel here...

From: xorg-owner@lists.freedesktop.org
To: zaitcev@redhat.com
Subject: Patch for sis and libpciaccess
Date: Fri, 14 Dec 2007 20:18:59 -0800
Sender: xorg-bounces@lists.freedesktop.org

You are not allowed to post to this mailing list, and your message has
been automatically rejected.  If you think that your messages are
being rejected in error, contact the mailing list owner at
xorg-owner@lists.freedesktop.org.

Snapped a minute ago on Rawhide (look at the corrupt icons):

I reported this bug a year ago, IIRC. But it's still with us. I really should get off my ass and fix it, but since it involves GNOME, that would require some major learning. Which would probaly be probably a good thing, actually... But I'm always busy with some stuff. And who isn't?

UPDATE: Actually, it was two years ago.

UPDATE 2: Ajaxxx says that ssh tricks X into thinking that pixmaps are in a shared memory segment. And they are... on a different host.

The alternative, as far as absolute mode is concerned, is either to add absolute mode to mouse, or add automatic configuration to evdev. It seems "obvious" that adding absolute mode to the mouse is the way to go, given how immature evdev is. However, this is not the whole picture, and since evdev promises tons of features, everyone but me seems settled on fixing the evdev's problems. The biggest of them is lack of autoconfiguration: users have to guess the evdev number for their devices (A bunch of hacks around it exist, starting from evdev options like "Name", and up to ad-hoc daemons (like hpmouse) multiplexing into a named pipe.). The lesser one is how it crases and takes the X server with it. This should be fixable. After all, synaptics plugs into the same API and works fine.

I thought what the next step ought to be for me and probably it's going to be a) make a standard set of udev rules to create /dev/input/evdev (instead of letting evdev to poke around sysfs and bloat even more with a confusing hodge-podge of ad-hoc code), and b) debug evdev crashes and get someone to take fixes into X.

At least a few of the goals are as follows:

1. BIOS-free Suspend/Resume support
2. Text-mode panic
3. Flicker-free graphical boot
4. Fancy animated user switching

[...]

While we may mock Windows and the BSOD, many people would be far happier with that than the current state of an Xorg system where kernel panics are not announced at all; instead, the screen simply freezes and the user has no idea what has happened. Even the ability to escape from this state is limited to those with the secret handshake knowledge. Getting back to a simple text mode and displaying the panic message requires the ability to program a fixed mode from within the kernel, and the ability to lock out other users of the graphics device (perhaps waiting for the hardware pipeline to drain, if necessary).

Keith is right, BSOD is far superior to what we have now. But the problem with his idea is, switching to text mode is broken more often than anyone seems to realize these days. Out of three systems on my desk, three are broken. One is a (SiS) Xabre Volari Z7 in Dell SC430, and another is a kind of an ancient mobile nVidia (GeForce2 Go). On the SiS Z7, switching with <Alt><Ctrl>F1 works fine, but when X exits for shutdown, the screen is a typical colorful mess of mismatching RAM access. On the laptop, the text can be read, but it flickers badly enough that taking a picture of it is a challenge. What is most important, nobody cares enough to fix it (no, I haven't filed any bugs - I don't care enough either).

What we really need is putting the console output into the framebuffer. Either do it in the same butt-ugly way SunOS 4 did it on SPARCstation, or come up with a better idea (actually I tinkered with a console window back in JavaStation days). But Windows-style mode switching is not a good idea.

xorg-x11-server-1.1.1-54.fc7/hw/xfree86/common/xf86Config.c:

    /*
     * hack: always synthesize a 'mouse' section configured to send core
     * events, unless a 'void' section is found, in which case the user
     * probably wants to run footless.
     */
    int _found = 0;
    IDevPtr i;
    for (i = servlayoutp->inputs; i->driver; i++) {
        if (!strcmp(i->driver, "void") || !strcmp(i->driver, "mouse")) {
            _found = 1; break;
        }
    }
    if (!_found) {
        xf86Msg(X_INFO, "No default mouse found, adding one\n");

Thus, the solution:

[root@xen-theta ~]# diff -u /etc/X11/xorg.conf.jittery /etc/X11/xorg.conf 
--- /etc/X11/xorg.conf.jittery  2006-12-13 21:37:49.000000000 -0800
+++ /etc/X11/xorg.conf  2006-12-13 21:38:51.000000000 -0800
@@ -5,6 +5,7 @@
        Screen      0  "Screen0" 0 0
        InputDevice    "Keyboard0" "CoreKeyboard"
        InputDevice    "VMouse0"
+       InputDevice    "IHATEKLUDGERS"
 EndSection
 
 Section "InputDevice"
@@ -35,6 +36,11 @@
        Option      "Device"            "/dev/input/mice"
 EndSection
 
+Section "InputDevice"
+        Identifier  "IHATEKLUDGERS"
+       Driver      "void"
+EndSection
+
 Section "Device"
        Identifier  "Videocard0"
        Driver      "fbdev"
[root@xen-theta ~]# 

Well, well, well. At least this is open source. With Windows, I'd never know what hit me (or had to buy a hideously expensive book, and sign up for MSDN).

The motion is not jumpy anymore, but still not correct. I feed correct values into xf86PostMotionEvent(), but my ->conversion_proc receives them weirdly scaled (by about 20%, and offset). Dunno what's up with that.

{Fridge update: git can tell the commit, and the author turns out to be none other than ajaxxx. What was he thinking?}

(==) ServerLayout "Default Layout"
(**) |-->Screen "Screen0" (0)
(**) |   |-->Monitor ""
(**) |   |-->Device "Videocard0"
(WW) No monitor specified for screen "Screen0".
        Using a default monitor configuration.
(**) |-->Input Device "Keyboard0"
(**) |-->Input Device "VMouse0"
(II) No default mouse found, adding one
(**) |-->Input Device "<default pointer>"

The two input devices fight for sending the events and thus the jitters.

The evdev suffers from exactly the same problem, so I can't just steal code from it. Tomorrow is time for "grep -r 'No default mouse found'".

I'm sure that this problem is possible to work around in xorg.conf. Otherwise, nobody would have been able to use evdev for input (it's just that bad), and I am sure Stone, Hoksberg, or whoever actually test the thing. However, this is not desirable. I prefer xenpv to be a drop-in replacement for mouse for now.

This also may be not worth fighting, because, as I mentioned before, Katz wants mouse itself to support absolute input, in the same way vmmouse does it now. This way, none of our configuration tools would need any changes. So hmm.... Anyway, tomorrow.

P.S. Hackery of X is very much fun, I should've done it before.

{Update: O.M.G.}

Check this out though:

........
(II) LoadModule: "xenpv"
(II) Loading /usr/lib64/xorg/modules/input/xenpv_drv.so
(II) Module xenpv: vendor="X.Org Foundation"
        compiled for 7.1.1, module version = 1.1.0
        Module class: X.Org XInput Driver
        ABI class: X.Org XInput driver, version 0.6
........
(II) FBDEV(0): hardware: xen (video memory: 1875kB)
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 800x600 (pitch 800)
........
(**) Keyboard0: CustomKeycodes disabled

Backtrace:
0: X(xf86SigHandler+0x71) [0x4a0c01]
1: /lib64/libc.so.6 [0x2aaaabc2d200]
2: X(xf86MotionHistoryAllocate+0x15) [0x49b915]
3: /usr/lib64/xorg/modules/input/xenpv_drv.so [0x2aaaadfa6e71]
4: X(InitInput+0x17b) [0x460f9b]
5: X(main+0x338) [0x432468]
6: /lib64/libc.so.6(__libc_start_main+0xf4) [0x2aaaabc1aa44]
7: X(FontFileCompleteXLFD+0x229) [0x431879]

Fatal server error:
Caught signal 11.  Server aborting

Aside from the celebration about stuffing my xenpv module through the compiler, it's interesting that X now prints a traceback. I think they copied kallsyms here. Good going, Keith's minions!

In general, it's not a good thing when applications grow such ad-hoc debugging aids, because usually they interfere with gdb while being nowhere near as functional. I think gaim used to have something like it, and I still remember it because few things are as irritating as a bug in the debugging code which causes the application to exit without explanation or a core. But in case of X, I think it's cool. It's almost a kernel really.

I wonder why my module's symbols are not visible to the traceback...