Cannot remap keys on Cherry keyboard

[bernardjoseph]

I cannot remap keys on my Cherry Wired Keyboard. evremap config.toml does not ouput an error message, but does not have any effect. evremap list-devices shows two devices named "Cherry GmbH CHERRY Wired Keyboard' with two different events. I have no clue what is the right event for the keyboard, but maybe evremap takes the wrong one. The keyboard name seems to be ambiguous.

I have another keyboard, the Logitech K380 bluetooth keyboard, which has three devices. But these devices have three different names, "Keyboard K380 Keyboard", "Keyboard K380 System Control" and "Keyboard K380 Consumer Control", and taking the first one works.

[bronvic]

I faced the same problem. My keyboard has two different inputs in /dev/input

I looked in /proc/bus/input/devices and found them:

I: Bus=0003 Vendor=04b4 Product=0818 Version=0111
N: Name="LingYao ShangHai Thumb Keyboard"
P: Phys=usb-0000:00:14.0-5/input0
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.0/0003:04B4:0818.0005/input/input41
U: Uniq=081820131130
H: Handlers=sysrq kbd leds event7
B: PROP=0
B: EV=120013
B: KEY=1000000000007 ff9f207ac14057ff febeffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=04b4 Product=0818 Version=0111
N: Name="LingYao ShangHai Thumb Keyboard"
P: Phys=usb-0000:00:14.0-5/input1
S: Sysfs=/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5:1.1/0003:04B4:0818.0006/input/input42
U: Uniq=081820131130
H: Handlers=event13 mouse3
B: PROP=0
B: EV=17
B: KEY=70000 0 0 0 0
B: REL=3
B: MSC=10

It seams that this code iterate through list of devices in /dev/input and there are two events for this keyboard: event7 and event13

l /dev/input                                                      voronwe@beelinerouter
total 0
drwxr-xr-x 2    160 Nov 19 23:08 by-id
drwxr-xr-x 2    300 Nov 19 23:08 by-path
crw-rw---- 1 13, 64 Nov 18 13:06 event0
crw-rw---- 1 13, 65 Nov 18 13:06 event1
crw-rw---- 1 13, 74 Nov 18 13:06 event10
crw-rw---- 1 13, 75 Nov 18 13:06 event11
crw-rw---- 1 13, 76 Nov 18 13:06 event12
crw-rw---- 1 13, 77 Nov 19 23:08 event13
crw-rw---- 1 13, 78 Nov 18 13:06 event14
crw-rw---- 1 13, 79 Nov 18 13:06 event15
crw-rw---- 1 13, 80 Nov 18 13:06 event16
crw-rw---- 1 13, 81 Nov 18 13:06 event17
crw-rw---- 1 13, 82 Nov 18 13:06 event18
crw-rw---- 1 13, 83 Nov 18 13:06 event19
crw-rw---- 1 13, 66 Nov 18 13:06 event2
crw-rw---- 1 13, 84 Nov 18 13:06 event20
crw-rw---- 1 13, 85 Nov 18 13:06 event21
crw-rw---- 1 13, 86 Nov 18 13:06 event22
crw-rw---- 1 13, 87 Nov 18 13:06 event23
crw-rw---- 1 13, 88 Nov 19 22:36 event24
crw-rw---- 1 13, 67 Nov 18 13:06 event3
crw-rw---- 1 13, 68 Nov 18 13:06 event4
crw-rw---- 1 13, 69 Nov 18 13:06 event5
crw-rw---- 1 13, 70 Nov 18 13:06 event6
crw-rw---- 1 13, 71 Nov 19 23:08 event7
crw-rw---- 1 13, 72 Nov 18 13:06 event8
crw-rw---- 1 13, 73 Nov 18 13:06 event9
crw-rw-r-- 1 13,  0 Nov 18 13:06 js0
crw-rw---- 1 13, 63 Nov 18 13:06 mice
crw-rw---- 1 13, 32 Nov 18 13:06 mouse0
crw-rw---- 1 13, 33 Nov 18 13:06 mouse1
crw-rw---- 1 13, 34 Nov 18 13:06 mouse2
crw-rw---- 1 13, 35 Nov 19 23:08 mouse3
crw-rw---- 1 13, 36 Nov 18 13:06 mouse4

But, as you can see, event13 appears before event7. I removed /dev/input/event13 entry and application worked just fine

I'm don't know why keyboard has two entries and how to know which one is correct. Maybe we can sort events before iterating and first one will be correct? At least it is simple solution for this particular problem

[wez]

I think what's needed in this case is for this logic: https://github.com/wez/evremap/blob/master/src/deviceinfo.rs#L28 to detect when a name is ambiguous and do something, such as printing out the list of /dev/input/eventX paths that are ambiguous, and then augmenting the config code to allow specifying device_path instead of device_name to disambiguate these things.

[bronvic]

But are you sure that same events would be assigned to same device every time?

[bronvic]

I checked event types and properties for my devices and found that there are some differences

/dev/input/event13 (incorrect) has extra event type: EV_REL /dev/input/event7 (correct) has two extra event types: EV_LED and EV_REP

And both of them has EV_SYN, EV_KEY and EV_MSC

I checked this with evdev-rs package that you use in the project

But I don't actually know if availability of any of these events (or their combination) can be reliable property of needed keyboard

[wez]

The master branch now has the following behavior:

; cat /tmp/evremap.toml
device_name = "Power Button"

sudo ./target/debug/evremap remap /tmp/evremap.toml
 2021-11-24T10:04:40.885 ERROR evremap > Short delay: release any keys now!
 2021-11-24T10:04:43.084 WARN  evremap::deviceinfo > The following devices match name `Power Button`:
 2021-11-24T10:04:43.084 WARN  evremap::deviceinfo > DeviceInfo { name: "Power Button", path: "/dev/input/event0", phys: "PNP0C0C/button/input0" }
 2021-11-24T10:04:43.084 WARN  evremap::deviceinfo > DeviceInfo { name: "Power Button", path: "/dev/input/event1", phys: "LNXPWRBN/button/input0" }
 2021-11-24T10:04:43.084 WARN  evremap::deviceinfo > evremap will use the first entry. If you want to use one of the others, add the corresponding phys value to your configuration, for example, `phys = "LNXPWRBN/button/input0"` for the second entry in the list.
 2021-11-24T10:04:43.085 ERROR evremap::remapper   > Going into read loop

So you can solve the ambiguity with a config like this:

device_name = "Power Button"
phys = "LNXPWRBN/button/input0"

# remapping rules down here