Changes with xinput randomly revert back to default

Question

I'm using Kubuntu 16.04 (xenial) on a laptop with an ELAN Touchscreen together with a DELL 750-AAHC active stylus. One of the buttons on the stylus behaves as a mouse middle-button, and I want it to be a right button instead.

I can achieve this by doing

$ xinput set-button-map "ELAN Touchscreen Pen" 1 3 2

(i.e., mapping the function of button 3, which must correspond to the right button, to physical button 2).

This does what I want, but the change is not permanent.

I added the command in ~/.xsessionrc (according to the answer on this post), so it's run automatically when I reboot, but the button mapping "randomly" reverts to default on its own: it's working as expected for a while, and suddenly I discover that it doesn't, so I get

$ xinput get-button-map "ELAN Touchscreen Pen"
1 2 3 4 5

and I have to remap it manually.

I tried a few "suspect" things to see what might be responsible for reverting, but I couldn't figure it out. It's not caused by

• suspending the laptop or turning off the screen
• rotating the screen (this was suspect because xinput is used on rotation to transform the input matrix.)
• toggling touchscreen, touchpad or stylus input on/off (also with xinput).

IMPORTANT UPDATE:

I've discovered that this problem is not specific to the stylus: I disabled the finger-touch capability of the screen ("ELAN Touchscreen") earlier for some reason by doing:

$ xinput disable "ELAN Touchscreen"

and I just discovered that it came back on its own (and the stylus right-click had again reverted). So it seems like all xinput changes revert to default for this unknown reason.

UPDATE 2

I found some suspicious entries in /var/log/syslog when this happened again. The timestamps were during a time I had not actually been using the laptop for some time, so energy-saving features were probably activated (I have "dim screen" at 9 mins and "switch off" at 10 mins; I will experiment with energy saving and update accordingly).

The pattern bellow is actually repeated many times, with only a few seconds difference between each block.

usb 1-8: USB disconnect, device number 18
usb 1-8: new full-speed USB device number 19 using xhci_hcd
usb 1-8: New USB device found, idVendor=04f3, idProduct=2073
usb 1-8: New USB device strings: Mfr=4, Product=14, SerialNumber=0
usb 1-8: Product: Touchscreen
usb 1-8: Manufacturer: ELAN
input: ELAN Touchscreen Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7548
input: ELAN Touchscreen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7549
input: ELAN Touchscreen Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7552
hid-multitouch 0003:04F3:2073.04EE: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [ELAN Touchscreen] on usb-0000:00:14.0-8/input0

In each block, almost everything is the same except a few numbers that increase. Here's the next block for comparison:

usb 1-8: USB disconnect, device number 19
usb 1-8: new full-speed USB device number 20 using xhci_hcd
usb 1-8: New USB device found, idVendor=04f3, idProduct=2073
usb 1-8: New USB device strings: Mfr=4, Product=14, SerialNumber=0
usb 1-8: Product: Touchscreen
usb 1-8: Manufacturer: ELAN
input: ELAN Touchscreen Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7554
input: ELAN Touchscreen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7555
input: ELAN Touchscreen Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7558
hid-mul itouch 0003:04F3:2073.04EF: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [ELAN Touchscreen] on usb-0000:00:14.0-8/input0

The device numbers wrap around at 128.

System:

• KDE Plasma 5.5.5
• Qt 5.5.1
• Kernel 4.13.0-32-generic #35~16.04.1-Ubuntu 64-bit

• xinput version 1.6.2

  XI version on server: 2.3

• X.Org X Server 1.19.5

  Release Date: 2017-10-12

  X Protocol Version 11, Revision 0

Answer 1

This appears to be a bug (the fact that the touchscreen device randomly disconnects and reconnects as a new device, which has the side-effect of resetting all settings to default).

As a workaround, you can create your own udev rule (file name based on these suggestions by Daniel Drake) that will run a script that re-applies the xinput changes whenever the touchscreen reconnects:

sudo nano /etc/udev/rules.d/10-custom-elan.rules

and add this line which contains "idVendor" and "idProduct" information (from your syslog). The absolute path to "elan.sh" must be used.

ATTRS{idVendor}=="04f3", ATTRS{idProduct}=="2073", RUN+="/home/username/elan.sh"

(which roughly translates to ""when a device that matches the specified attributes is found, run the designated script").

Then create the actual script to run xinput:

nano /home/username/elan.sh 

with the following lines:

#!/usr/bin/env bash

#These lines allow the script to be called by udev rules
export DISPLAY=":0"
export XAUTHORITY="/home/username/.Xauthority"

#Command to remap buttons
xinput set-button-map "ELAN Touchscreen Pen" 1 3 2 4 5

And of course make it executable:

chmod +x /home/username/elan.sh

Without the export lines, the script works when called by you (the active user) directly, but it doesn't work when called by udev (the root user). Details can be found in this and this answer, but here's a brief summary:

To launch a graphical program on a user's desktop, you need two things: the address (what display the user's desktop is on) and authorisation. When a user logs in, the login manager authorises a connection to the X server by generating a cookie, adding it to the server and passing it to the user by writing it to $HOME/.Xauthority. The root user should, then, be able to connect by knowing the display used by the user and by having access to the Xauthority cookie. This is what the export lines achieve.

Note: the fact that the display number is hardcoded might cause a problem under some circumstances, but in this usage scenario (single user of a personal laptop) it will probably be OK.