Well, something in the behaviour of X changed again after an update, and now in response to the previous code, xinput set-int-prop '"Logitech USB Trackball"' 'Evdev Wheel Emulation Button' 8 8, I get this error: unable to find device "Logitech USB Trackball".

So I go a-hunting in man xinput and find that, if the name of the device has changed, I will find it by using xinput list, which give me this:

? Virtual core pointer                    	id=2	[master pointer  (3)]
?   ? Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
?   ? Logitech USB Trackball                  	id=8	[slave  pointer  (2)]
?   ? Macintosh mouse button emulation        	id=10	[slave  pointer  (2)]
? Virtual core keyboard                   	id=3	[master keyboard (2)]
    ? Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ? Power Button                            	id=6	[slave  keyboard (3)]
    ? Power Button                            	id=7	[slave  keyboard (3)]
    ? AT Translated Set 2 keyboard            	id=9	[slave  keyboard (3)]

It looks to me like it’s still called a “Logitech USB Trackball”. Long story short, I now have to identify this by id code, or drop the extra quotes. For posterity, here are the commands that work:

xinput set-int-prop 8 'Evdev Wheel Emulation Button' 8 8
xinput set-int-prop 8 'Evdev Wheel Emulation' 8 1

or

xinput set-int-prop 'Logitech USB Trackball' 'Evdev Wheel Emulation Button' 8 8
xinput set-int-prop 'Logitech USB Trackball' 'Evdev Wheel Emulation Button' 8 1

Yes, these changes are a pain in the ass.

As near as I can tell, some update or tweak in the way X works has invalidated the configuration of my mouse via hal. This is definitely getting tiring. I have had to work around it by putting this in my .xinitrc:

xinput set-int-prop '"Logitech USB Trackball"' 'Evdev Wheel Emulation Button' 8 8
xinput set-int-prop '"Logitech USB Trackball"' 'Evdev Wheel Emulation' 8 1

If it starts to work differently, I’ll update, again.

A recent update of the xerver-xorg package (1:7.4+1) changed the way X configures input devices – they are now handled by hal or evdev, and their sections of the xorg.conf are ignored.

I filed a bug report, and was informed that it’s not a bug. I disagree, in that if you break things in an upgrade, it is a bug.

Never-the-less, I had to figure out how to get my EmulateWheel behaviour back since the upgrade.

The evdev man page is nigh on useless, but this blog entry helped a lot.  It has lead to the following as my /etc/hal/fdi/policy/marble_mouse.fdi:

<match key="info.product" string="Logitech USB Trackball">
 <merge key="input.x11_options.EmulateWheel" type="string">true</merge>
 <merge key="input.x11_options.EmulateWheelButton" type="string">8</merge>
 <merge key="input.x11_options.ZAxsisMapping" type="string">4 5</merge>
</match>

I got the info.product part by looking at /dev/input/by-id/, and
guessing. I logged out, and restarted hal for good measure. One or the
other may not be necessary.