SHM config in synaptics

This is an addendum to Why SHMConfig is off by default.

SHM in synaptics provided two functionalities: run-time configuration and hardware monitoring.

run-time configuration works by having the driver configuration exposed as a shared memory segment and letting another process change this state. hw monitoring works by dumping the hw state read from the device into the shared memory and then having another process print this state.
synclient was the default UI (though syndaemon used SHM as well).

X Server 1.6 introduced input device properties, a generic way to attach information to input devices. The information can be attached by drivers or clients, and both drivers and clients are notified about changed values. Hence, it's a good vehicle for device-specific configuration.

• synaptics 1.0 had input device property support in the driver, but SHM configuration is still available.

• synaptics 1.1 had synclient and syndaemon use input device properties by default, but SHM configuration is still available.

• synaptics 1.2 (current release) has configuration through SHM removed from both the driver and synclient/syndaemon and the SHM area is not writable by the user anymore.

All releases support hardware monitoring through SHM. However, there's little reason to enable it these days unless a developer asks you to do so to get more information on the data the touchpad provides. I haven't asked anyone for the monitoring output for months, usually the data from the kernel is enough.

The following GUI tools use properties:

• gnome-mouse-properties + gnome-settings-daemon
• gsynaptics (merely a wrapper around synclient). discontinued, see gpointing-device-settings.
• gpointing-device-settings
• synaptiks
  

(not sure what other KDE tools there are)

evtest-capture and replaying events

Many of you are probably familiar with evtest, a small debugging utility written by Vojtek Pavlik to check what input device data is leaving the kernel. I use it a lot and one of the standard requests I make in bugreports is run evtest against the device file. The information it prints tells us the capabilities a device has and the events being sent when a certain action is performed.

I've used this information to add uinput device to my uinput test devices collection to debug various server and/or driver failures.
That worked for some cases but suffered from a major caveat: it was incredibly hard to reproduce issues that resulted from complex interactions. For months, I've been meaning to fix this and last weekend I finally had time to sit down and hack something up. That work is now in the evtest repository.

It works quite simple:
The user runs evtest-capture against the device and performs the action that reproduces the bug. evtest-capture saves the event stream into an xml file, this xml file can then be converted into a standalone uinput-based C program that resembles both the device and the interaction. I can re-create and run that program on my test box and reproduce and hopefully debug the issue.

The full set of steps is (as root where necessary):

$> evtest-capture /dev/input/event0 pointer-crashes.xml
$> xsltproc evtest-create-device.xsl pointer-crashes.xml > pointer-crash-device.c
$> gcc -o pointer-crash-device pointer-crash-device.c
$> ./pointer-crash-device
#verify the issue happens with this test device.

Like so many things, it's not perfect but it will hopefully help us reproduce a lot more bugs and thus make it simpler to find and address these bugs.