X forgets xinput settings on suspend

[Sampo Niskanen]

Binary package hint: xinput

I don't know is this an issue in X or xinput...

I've used XUbuntu on a Thinkpad for several years. I have configured middle-click-scrolling (so middle-click + drag equals to the scroll wheel) as descibed at http://www.thinkwiki.org/wiki/How_to_configure_the_TrackPoint#Configuration_using_xinput using:

xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1
xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Button" 8 2
xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation Axes" 8 6 7 4 5

I have configured the script to be run when X starts up, and everything has been dandy. When I upgraded to XUbuntu 10.10, however, every time I suspend and resume my laptop X forgets the xinput settings and I have to run the script again.

Additionally, every now and then (maybe once or twice a week) when resuming the script stops working because X has detected the input device in duplicate:

$ xinput set-int-prop "TPPS/2 IBM TrackPoint" "Evdev Wheel Emulation" 8 1
Warning: There are multiple devices matching 'TPPS/2 IBM TrackPoint'.
To ensure the correct one is selected, please use the device ID, or prefix the
device name with 'pointer:' or 'keyboard:' as appropriate.

unable to find device TPPS/2 IBM TrackPoint
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=10 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=12 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=13 [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)]
    ↳ Video Bus id=7 [slave keyboard (3)]
    ↳ Sleep Button id=8 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=9 [slave keyboard (3)]
    ↳ ThinkPad Extra Buttons id=11 [slave keyboard (3)]

(Devices 12 and 13) If I manually run the commands for device 13 they work, but not automatically. On the contrary, occasionally the Trackpoint (nib) and its corresponding buttons stop working completely, and only the Touchpad functions. I have to reboot to get it working properly again.

The constant messing around with the mouse settings is very frustrating, especially since it's been working fine for so long.

[Charlie Kravetz (cjkgeek)]

Thank you for reporting this issue. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

Please attach the output of `lspci -vvnn` too. These should be attached as plain text files, please.

[Sampo Niskanen (sampo-niskanen)]

Hi,

Attached is the Xorg.0.log from my current session. The entries from 22970.161 onwards is generated by a single suspend-resume (which loses the trackpoint settings). The xinput commands generate no output in the logs.

I'll try to save the Xorg logs the next time the trackpoint is detected as duplicate or stops working completely.

[Sampo Niskanen (sampo-niskanen)]

Here's the output of lspci -vvnn.

[Charlie Kravetz (cjkgeek)]

Thank you for the additional attachments. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

[Timo Aaltonen (tjaalton)]

xinput does what it's designed to do, you can add xinput commands to the session startup scripts to make it "persistent". But, this particular use case has already been filed, and I'll mark this as a dupe of the other one.

[Fionn (fbe)]

I'd like to strongly emphasize my opinion that this is certainly NOT a duplicate of #554984.
Bug #554984 is about enabling tracpoint scrolling generally.

THIS bug, however, is about X forgetting certain settings, namely the trackpoint wheel emulation, which have been enabled via xinput, during an S3 (suspend to ram) cycle.
Since X is not being restarted in the course of this event, it should also not change or forget its settings.

Putting the required statements into .xsessionrc as recommended in #554984 as a workaround does not apply for this bug, too, since that file is only evaluated at X startup and not at resume from s3.

[Fionn (fbe)]

Although this bug is most certainly not a duplicate of bug #554984, it might (or might not) be related to bug #489830 which seems to have useful hints in the comments. Whether or not this actually is the same issue should be properly investigated before flagging this as dupe again, IMHO.

HTH