udev rules help

sniff · 04-12-2016, 11:24 AM

I am trying to get udev to change some settings on my mouse when I switch better computers with KVM. So once the mouse is redetected the buttons need resetting.

I have the following udev rules file in my /etc/udev/rules.d folder, named 90-emouse.rules:

Code:

ACTION=="add", ATTRS{idVendor}=="1a7c", ATTRS{idProduct}=="0191", SUBSYSTEM=="input", RUN+="/home/mouseSetup.sh"

The context of mouseSetup.sh is as follows and works on its own:

Code:

#!/bin/bash
MOUSE_ID=`xinput list | grep -i Evoluent | awk -F= '{ print $2}' | awk '{print $1}'`
xinput set-button-map $MOUSE_ID 1 3 2 4 5 6 7 8 9 10 11 12 13 14

The rule doesn't seem to be working and this mouse buttons therefore do not change with I switch back to the computer. Its running Opensuse 13.2.

Anyone see a problem?

ferrari · 04-13-2016, 04:35 AM

Well, udev will run that script as root, but does root own the X-session? That will complicate running that script

Similar threads
http://unix.stackexchange.com/questi...only-partially
http://unix.stackexchange.com/questi...s-an-x-display

sniff · 04-13-2016, 04:47 PM

I thought that might be it. However if I run the script as root then it seems to work.

ferrari · 04-13-2016, 06:11 PM

Are the attributes valid? Do they all come from same parent device?

https://wiki.archlinux.org/index.php...es_of_a_device
http://www.reactivated.net/writing_u....html#udevinfo

Quote:

You may have noted the use of colour in the above examples. This is to demonstrate that while it is legal to combine the attributes from the device in question and a single parent device, you cannot mix-and-match attributes from multiple parent devices - your rule will not work.

Is the udev rule being triggered before logging in (ie before session exists)?

sniff · 04-15-2016, 12:03 PM

I will test out the attributes. Is there a way to see if the udev rule is triggered?

ferrari · 04-15-2016, 08:37 PM

Yes, there is. It relies on knowing the device path though...

https://wiki.archlinux.org/index.php...before_loading

ferrari · 04-15-2016, 09:00 PM

I recall an old openSUSE thread I participated in many moons ago. It is possible to put the udevd daemon in debug mode. The steps required to stop the daemon depend on whether systemd is used or not, but once stopped, the daemon is then run with

Code:

udevd --debug

and then the output will help confirm if a particular rule is triggered for a given event.

sniff · 05-15-2016, 01:39 PM

I am still struggling with this... well there was a gap between attempts. I haven't been doing solid for weeks.

This is the output of:
udevadm info -a -n /dev/input/by-id/usb-Kingsis_Peripherals_Evoluent_VerticalMouse_4-mouse

Code:

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1A7C:0191.001A/input/input50/mouse0':
    KERNEL=="mouse0"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1A7C:0191.001A/input/input50':
    KERNELS=="input50"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Kingsis Peripherals Evoluent VerticalMouse 4"
    ATTRS{phys}=="usb-0000:00:1a.0-1.5.1/input0"
    ATTRS{uniq}==""
    ATTRS{properties}=="0"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0/0003:1A7C:0191.001A':
    KERNELS=="0003:1A7C:0191.001A"
    SUBSYSTEMS=="hid"
    DRIVERS=="hid-generic"
    ATTRS{country}=="21"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1/1-1.5.1:1.0':
    KERNELS=="1-1.5.1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="usbhid"
    ATTRS{bInterfaceClass}=="03"
    ATTRS{bInterfaceSubClass}=="01"
    ATTRS{bInterfaceProtocol}=="02"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{supports_autosuspend}=="1"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceNumber}=="00"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5/1-1.5.1':
    KERNELS=="1-1.5.1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{devpath}=="1.5.1"
    ATTRS{idVendor}=="1a7c"
    ATTRS{speed}=="12"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="30"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="100mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="a0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="0"
    ATTRS{bcdDevice}=="0100"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="2545"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="Kingsis Peripherals"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0191"
    ATTRS{bDeviceClass}=="00"
    ATTRS{product}=="Evoluent VerticalMouse 4"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.5':
    KERNELS=="1-1.5"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{devpath}=="1.5"
    ATTRS{idVendor}=="05e3"
    ATTRS{speed}=="480"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="29"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="100mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="4"
    ATTRS{bcdDevice}=="0702"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="48"
    ATTRS{ltm_capable}=="no"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0608"
    ATTRS{bDeviceClass}=="09"
    ATTRS{product}=="USB2.0 Hub"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1/1-1':
    KERNELS=="1-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{devpath}=="1"
    ATTRS{idVendor}=="8087"
    ATTRS{speed}=="480"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="2"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="0mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="6"
    ATTRS{bcdDevice}=="0000"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="178"
    ATTRS{ltm_capable}=="no"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0024"
    ATTRS{bDeviceClass}=="09"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0/usb1':
    KERNELS=="usb1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{devpath}=="0"
    ATTRS{idVendor}=="1d6b"
    ATTRS{speed}=="480"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{authorized_default}=="1"
    ATTRS{busnum}=="1"
    ATTRS{devnum}=="1"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="0mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="2"
    ATTRS{bcdDevice}=="0401"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{serial}=="0000:00:1a.0"
    ATTRS{version}==" 2.00"
    ATTRS{urbnum}=="24"
    ATTRS{ltm_capable}=="no"
    ATTRS{manufacturer}=="Linux 4.1.20-11-default ehci_hcd"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0002"
    ATTRS{bDeviceClass}=="09"
    ATTRS{product}=="EHCI Host Controller"

  looking at parent device '/devices/pci0000:00/0000:00:1a.0':
    KERNELS=="0000:00:1a.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ehci-pci"
    ATTRS{irq}=="16"
    ATTRS{subsystem_vendor}=="0x1458"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x0c0320"
    ATTRS{companion}==""
    ATTRS{driver_override}=="(null)"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{local_cpus}=="fff"
    ATTRS{device}=="0x1d2d"
    ATTRS{uframe_periodic_max}=="100"
    ATTRS{enable}=="1"
    ATTRS{msi_bus}=="1"
    ATTRS{local_cpulist}=="0-11"
    ATTRS{vendor}=="0x8086"
    ATTRS{subsystem_device}=="0x5006"
    ATTRS{numa_node}=="-1"
    ATTRS{d3cold_allowed}=="1"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

ferrari · 05-15-2016, 07:09 PM

Well, after a quick glance at the udevinfo output, I think your matching attributes are ok. You can verify that triggering is occurring (or not) by using udev in debug mode as I've previously described. The steps required are a little different if using systemd. For reference, I'm running Leap and when I stop udev.service, I get

Code:

# systemctl stop udev
Warning: Stopping udev.service, but it can still be activated by:
  systemd-udevd-control.socket
  systemd-udevd-kernel.socket

Anyway, the socket activation can be stopped in a similar fashion. When your device is then attached, the verbose output can be captured to examine which rules are triggered.