Disabling my Synaptics Mouse using xinput

My Lenovo 3000 N200 Laptop has been suffering a bit lately from old age. On returning from a week working with my fellow colleagues in Dublin the 120GB HDD died. Fortunately I had early warning from some SMART monitoring tools telling me I had a potential HDD failure and I was able to backup all my data before the HDD finally died and restore it on a spare HDD. I managed to find a fairly reasonable Western Digital Scorpio 160GB HDD replacement for about £27 (w/o VAT and postage) which should arrive by Monday.

Unfortunately the Synaptics touchpad has been getting really flakey. Typically the touchpad gets random button press events and then the button states get locked and toggling the buttons just returns the mouse into some weird unpredictable state. Try using GNOME when the buttons states are reversed or stuck down and you get to see how frustrating this can be!

This has not been so much of a problem as I normally use a wireless mouse so the touchpad is never normally used. It's just a pain when the touchpad just goes into weird event mode at random times, usually when you least expect it! My long term solution is to strip the machine down and see why the touchpad is misbehaving (I've downloaded the maintenance manual from Lenovo and it's not a 5 minute task to fix it). Hence I need a quick workaround before I go insane from weird mouse events.

My original plan was to disable the mouse driver, but in Karmic it's built in so this would require rebuilding the kernel with the driver compiled out and I've been resisting this kind of ugly hack. However, tonight I found a better workaround to disable the touchpad:

1. Find the Synaptics Mouse using:

xinput list

This dumps out a load of info, e.g.:

SynPS/2 Synaptics TouchPad" id=8 [XExtensionPointer]
Type is TOUCHPAD
Num_buttons is 12
Num_axes is 2
Mode is Relative
Motion_buffer is 256
Axis 0 :
Min_value is 1472
Max_value is 5472
Resolution is 1
Axis 1 :
Min_value is 1408
Max_value is 4448
Resolution is 1

and a lot more besides.

2. This enabled me to find the textual handle and id number (8) to my touchpad. I then listed the properties using:

xinput list-props "SynPS/2 Synaptics TouchPad"

which dumps out all the properties, e.g.:

Device Enabled (115): 1
Synaptics Edges (260): 1752, 5192, 1620, 4236
Synaptics Finger (261): 24, 29, 255
Synaptics Tap Time (262): 180
Synaptics Tap Move (263): 221
Synaptics Tap Durations (264): 180, 180, 100

..and a lot more properties too..

I then spotted the "Device Enabled" property, which I then disabled using:

xinput set-int-prop "SynPS/2 Synaptics TouchPad" "Device Enabled" 8 0

..and my touchpad was disabled! No more annoying stray events!

3. I next added this rune into the Startup Applications Preferences (from System->Preferences->Startup Applications).

Hopefully when I've got a spare hour or two and the kids aren't around I will strip this laptop down and fix the touchpad. Meanwhile, I'm happy to get control back from my misbehaving touchpad!

Faster ssh X11 Forwarding

I use ssh daily to connect to my servers and laptops around my home office. Most of the time I'm using ssh to login and build software, so it's plain and simple command line activity. However, sometimes I need to run an X11 application on a remote machine, in which case I use X forwarding to display the remote X application on my laptop. However, this can be slow. Today I stumbled on the following incantation to speed up X11 forwarding over ssh:

ssh -c arcfour,blowfish-cbc -X -C user@remotehost

Thanks to Samat Jain for this info.

The choice of cipher is based on some performance benchmarks as noted in LaunchPad bug #54180

Troubleshooting X issues on Ubuntu

Sorting out X problems can be a headache. The breadth of issues is wide and the complexity can be deep, so it's always helpful to have some where to turn to when you need deep X know-how. Fortunately Bryce Harrington has created a set of X Troubleshooting Wiki pages which have proved helpful to fix X issues.

The wiki covers a range of topics, including: Resolution issues, high CPU utilisation, blank screen issues, freezes, font sizes, X resume crashes, Intel performance issues and hotkey fixes to name but a few.

I'd recommend you to check out the Wiki even if you don't have X issues, just because it's packed full of useful X config nuggets of information.

Debugging Intel X Hangs

While I was at UDS I learnt some useful X debugging tricks for Intel based chipsets. One can debug the driver using debugfs as follows:

1. ssh into the machine with locked-up X and then mount debugfs:

$ sudo mount -t debugfs none /sys/kernel/debug

2. Find the dri debug directory:

$ cd /sys/kernel/debug/dri/0

3. Check for a system lock up by looking to see if sequence numbers are advancing or not:

$ cat i915_gem_seqno
Current sequence: 1732368
Waiter sequence: 0
IRQ sequence: 1732364

If the sequence numbers are not increasing then we know that the GPU has locked up for some reason.

4. If that's working, then check to see what the X server is doing:

$ cat /proc/pid-of-X-server/wchan

(where 'pid-of-X-server' is the process id of the X server)

This will show you what it is waiting for. If you see it changing then it's not an X hang.

5. Look at the interrupt activity

$ cat i915_gem_interrupt

Check that the masks are restored correctly after a resume - interrupts may be masked and hence not able to respond to interrupts.

The IRQ sequence generally is a little behind Waiter sequence - if IRQ sequence does not increment it's a GPU hang. The Current Sequence *SHOULD NOT* be zero. Waiter Sequence is zero when there is nothing queued up to process.

Also, check out http://intellinuxgraphics.org/documentation.html