# sysfs, udev, and bluetooth MX1000 mouse using evdev. Agh!

## astaroth_pod

I seem to have gotten stuck on trying to get my bluetooth mouse working reliably using the evdev driver in xorg. (7.0.0 RC3).

The main problem is not the evdev (I can get that working) or the bluetooth mouse (that works too) but the fact that I can't write a reliable udev rule for the mouse!

When I use the mouse driver, I can simply cheat and use /dev/input/mice and always have the mouse working.

But when I use evdev, it'll end up on /dev/input/event4 first, and then every time I recieve a call on my cellphone using a bluetooth wireless headset, or there is any other interference, the mouse will disconnect and reconnect - and end up on /dev/input/event5! (As xorg is "holding" the event4). Voila, no more working mouse and I need to stop the X server, disconnect the mouse, wait 30 seconds, reconnect the mouse, and restart X to get the mouse back. Frustrating.

Well, I thought I could just write a little udev rule that'd handle the mouse and put it in one place, right? So I started out, documentation in hand:

```
KERNEL="event*", SYSFS{<somethingfromsysfs>}="<randominfo>", NAME="input/mx1000", MODE="0600"
```

Easy. So I start digging in /sys to find the mouse, just like the documentation says.

I find my device in /sys/class/bus/input/event4, hey great! There is order in the madness... So I want to extract the info from this device. First I do a ls -l:

```
total 0

-r--r--r--  1 root root 4096 Dec 16 12:54 dev
```

Hm, that's not alot is it... All the other input devices has lots of information.

Well, I try the udev tool 'udevinfo -a -p /sys/class/input/event4':

```
device '/sys/class/input/event4' has major:minor 13:68

  looking at class device '/sys/class/input/event4':

    KERNEL=="event4"

    SUBSYSTEM=="input"

    SYSFS{dev}=="13:68"

```

Hm, not much to go on there, but maybe I can use the SYSFS{dev} to identify my device?

I am a little suspicious though, so I provoke a change in the bluetooth connection to go to event5 by giving a buddy a call.

What happens, is this 'udevinfo -a -p /sys/class/input/event4': 

```
device '/sys/class/input/event4' has major:minor 13:69

  looking at class device '/sys/class/input/event4':

    KERNEL=="event4"

    SUBSYSTEM=="input"

    SYSFS{dev}=="13:69"

```

As I suspected, the SYSFS{dev} is not unique, but changes by order of connected devices  :Sad: 

The only things I can write an udev rule on in this case, is "event*" and "input" which will match all my input devices!

Last little maybe-interesting thing, 'cat /proc/bus/input/devices':

```
I: Bus=0010 Vendor=001f Product=0001 Version=0100

N: Name="PC Speaker"

P: Phys=isa0061/input0

H: Handlers=kbd event0

B: EV=40001

B: SND=6

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41

N: Name="AT Translated Set 2 keyboard"

P: Phys=isa0060/serio0/input0

H: Handlers=kbd event1

B: EV=120013

B: KEY=4 2000000 3802078 f950d001 f2ffffdf ffefffff ffffffff ffffffff

B: MSC=10

B: LED=7

I: Bus=0011 Vendor=0002 Product=0007 Version=0000

N: Name="SynPS/2 Synaptics TouchPad"

P: Phys=isa0060/serio4/input0

H: Handlers=mouse0 event2

B: EV=b

B: KEY=6420 0 70000 0 0 0 0 0 0 0 0

B: ABS=11000003

I: Bus=0011 Vendor=0002 Product=000a Version=0000

N: Name="TPPS/2 IBM TrackPoint"

P: Phys=synaptics-pt/serio0/input0

H: Handlers=mouse1 event3

B: EV=7

B: KEY=70000 0 0 0 0 0 0 0 0

B: REL=3

I: Bus=0005 Vendor=046d Product=b003 Version=4310

N: Name=""

P: Phys=

H: Handlers=mouse2 event4

B: EV=7

B: KEY=1f0000 0 0 0 0 0 0 0 0

B: REL=103

```

The last entry here is the bluetooth mouse.

Ok, maybe a long long post to say that the bluetooth mouse doesn't give any correct sysfs entries, but... HELP! Can anybody assist me in getting this working? Is it a bug, or is it a malconfigured whatever? Can't sysfs read bluetooth devices correctly? Doesn't BlueZ give the correct info?

Any input would be appreciated - if only enough to make a bug report somewhere...

----------

## Headrush

Make your udev rule using these attributes:

```
Vendor=046d Product=b003
```

The SYSFS attributes to match are idVendor and idProduct.

```
SYSFS{idVendor}="046d", SYSFS{idProduct}="b003"
```

Because this device creates two events you might have to do this

```
KERNEL="event[0-9]*", SYSFS{idVendor}="046d", SYSFS{idProduct}="b003", NAME="input/%k", SYMLINK="input/logitech%s{bInterfaceNumber}", MODE="0664"
```

So the devices will always be /dev/input/logitech00 and /dev/input/logitech/01.

----------

## astaroth_pod

Thanks Headrush - but it still doesn't work.

If SYSFS actually had these attributes for itself, wouldn't they be in udevinfo -a -p /sys/class/input/event4?

I tried adding idVendor and idProduct, but it won't catch the mouse... Still comes as event4. I tested it with SYSFS{dev}="13:68" and that works (as long as doesn't reset connection).. So I know the rule is working elsewise.

I also patched the kernel with the newest BlueZ changes - the output from /proc/bus/input/devices now looks like this:

```
I: Bus=0005 Vendor=046d Product=b003 Version=4310

N: Name="Logitech Bluetooth Mouse"

P: Phys=00:0F:B3:50:09:C2

H: Handlers=kbd mouse2 event4

B: EV=10000f

B: KEY=7fff0000 10000 0 0 0 0 0 0 0

B: REL=103

B: ABS=300 0
```

So better... But /sys is still just as empty.

----------

## TheAl

same problem here ...

Dont know how to link a name to my /dev/input/eventX

----------

## Hagar

 *astaroth_pod wrote:*   

> Thanks Headrush - but it still doesn't work.
> 
> If SYSFS actually had these attributes for itself, wouldn't they be in udevinfo -a -p /sys/class/input/event4?
> 
> I tried adding idVendor and idProduct, but it won't catch the mouse... Still comes as event4. I tested it with SYSFS{dev}="13:68" and that works (as long as doesn't reset connection).. So I know the rule is working elsewise.

 

You might be looking at the wrong entry in /sys

Try this to get the device info instead

# udevinfo -a -p $(udevinfo -q path -n /dev/input/eventX)

----------

