When invoking xinput
from udev, you have to set the XAUTHORITY
variable:
#!/bin/sh
export DISPLAY=":0"
export XAUTHORITY="/home/<user>/.Xauthority"
/usr/bin/xinput set-prop "DLL063E:00 06CB:2934" "Device Enabled" $1
this variable is already set when you run the script directly from the console, but scripts invoked by udev (and other services, such as cron), usually have a minimum set of environment variables, so you have to set it manually.
In the script called by your udev rule, place the while, do, done
snippet below, before your xinput
parameter tweaks.
#!/bin/sh
while [ ! "$(/usr/bin/hcitool info 84:38:35:31:CC:6B >& /dev/null; echo $?)" ]; do
sleep 0.1
done
xinput --set-prop "Mouse of Elios" "Device Accel Constant Deceleration" 5.0
xinput --set-prop "Mouse of Elios" "Device Accel Adaptive Deceleration" 1.0
xinput --set-prop "Mouse of Elios" "Device Accel Velocity Scaling" 3.3
It allows yr script to wait for successive time intervals of 0.1 second, until the mouse is appropriately tethered by Bluetooth and before the xinput --set-prop
cmds kick in.
Note that you have three ways to tweak yr mouse's response to a hand movement.
- Device Accel Constant Deceleration (528): 2.500000
- Device Accel Adaptive Deceleration (529): 1.000000
- Device Accel Velocity Scaling (530): 10.000000
Check this and this out to figure out exactly what those parameter values stand for. In order to satisfactorily modify the "velocity scaling", you'll need to know what your mouse refresh rate is (in Hz). You should find that value on the technical data sheet of your mouse. The Velocity Scaling value is estimated as 1000/refresh_rate_in_Hz
. Thus 3.3 assume a refresh rate of 300Hz, 10 a refresh rate of 100Hz.
Your script seems to bring no change to the default values of:
Device Accel Constant Deceleration (528): 2.500000
Device Accel Adaptive Decelaration (529): 1.000000
as revealed by your xinput --list-props
cmd... Try modifying the value of 2.5 for prop_id 528 and realize that setting prop_id 529 to 1 (default) means "no adaptive acceleration or deceleration".
The udev rule you adapted from Gilles' answer on AU / U&L does not apply strictly to your case. What you need is a rule that kicks in upon "adding" your device, i.e. as soon as its presence first triggers a kernel event. So your udev rule should simply read:
ACTION=="add", SUBSYSTEMS=="input", ATTRS{idVendor}=="____", ATTRS{idProduct}=="____", RUN+="/usr/local/sbin/fixmouse"
where you should replace ____ with your real device's idVendor
and idProduct
. To find that info:
$ udevadm monitor
Connect your BT mouse. Read on the line where "KERNEL" appears, something similar to:
KERNEL[22576.118379] add /devices/pci0000:00/0000:00:1d.7/hci2/2-3/2-3.4/2-3.4:1.0/0003:192F:0916.0004/input/input23/mouse1 (input)
To end monitoring, just type in CTRL+C, then:
$ udevadm info -a -p '/devices/pci0000:00/0000:00:1d.7/hci2/2-3/2-3.4/2-3.4' | grep -e "idVendor" -e "idProduct"
You should obtain 2 or 3 pairs of (idVendor, idProduct) values, depending on how your hardware is put together. My use-case yields:
ATTRS{idVendor}=="192f"
ATTRS{idProduct}=="0916"
ATTRS{idVendor}=="1a40"
ATTRS{idProduct}=="0101"
ATTRS{idVendor}=="1d6b"
ATTRS{idProduct}=="0002"
Try them in your udev rule in the order they appear. Normally the top most one should be the good one.
To finish, do:
$ sudo mv /home/elios/Documents/FixMouse.sh /usr/local/sbin/fixmouse
$ sudo chown root:root /usr/local/sbin/fixmouse
$ sudo chmod 755 /usr/local/sbin/fixmouse
Hope I got this right. Either way let us know.
Best Answer
Sounds like a USB auto-suspend issue in your case. Kernel boot option
usbcore.autosuspend=-1
should be tried to verify.See: fix-linux-mouse howto