can't get it to work - keep getting device busy errors about map2 HOT 5 CLOSED

You probably don't have an a key on your mouse that you're grabbing, so you might be looking for a keyboard device instead :) (usually will have a fd name ending with -event-keybaord), Mouse axis mapping is currently not supported.

Yeah, I wondered about that originally too. I assumed since I have an htpc keyboard (single device with both a keyboard and a trackpad) that maybe it just got registered as a mouse instead of a keyboard but still thought it was weird. Unfortunately, all of mine seem to say mouse. I'll try to just step through every option later and see if one of them works.. or maybe i can find something online mentioning the file descriptor for it; these things were cheap but relatively decent htpc keyboards so i'm sure there's a few other Linux users using them.

$ ls -acl /dev/input/by-id /dev/input/by-path | grep -Pvi 'Headset|spkr'
/dev/input/by-id:
total 0
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 usb-Logitech_USB_Receiver-if02-event-mouse -> ../event4
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 usb-Logitech_USB_Receiver-if02-mouse -> ../mouse1
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 usb-MOSART_Semi._2.4G_Wireless_Mouse-event-if00 -> ../event7
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 usb-MOSART_Semi._2.4G_Wireless_Mouse-event-mouse -> ../event6
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 usb-MOSART_Semi._2.4G_Wireless_Mouse-mouse -> ../mouse0
  
/dev/input/by-path:
total 0
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:12.0-usb-0:2:1.3-event -> ../event3
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:13.0-usb-0:4:1.2-event-mouse -> ../event4
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:13.0-usb-0:4:1.2-mouse -> ../mouse1
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:13.2-usb-0:5.2:1.0-event -> ../event7
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:13.2-usb-0:5.2:1.0-event-mouse -> ../event6
lrwxrwxrwx. 1 root root 9 Jan  8 19:58 pci-0000:00:13.2-usb-0:5.2:1.0-mouse -> ../mouse0

Edit: Not sure what I did different but it started working. Only thing I can think of that was significant was rebooting since adding myself to the input group unless I somehow had some bad whitespace chars in my previous device list or example script...

$ mkdir /tmp/map2 && cd "$_"
$ echo '/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse' > event4.list
$ echo "// maps 'a' to 'b'" > example.m2
$ echo 'a::b;' >> example.m2
$ map2 -d event4.list example.m2

anyway, when I retested in xed, it was working now.

Thanks for the help!

from map2.

Also came across this page while trying to figure out how to find the event names for certain media keys (I have some keys at the top of mine with a music symbol, a house icon, a lock symbol, and a power symbol that I was interested in remapping)...

Anyway, while not very helpful for what I wanted, I found them talking about the input group I mentioned there as well and this was on Ubuntu. So it seems that group is not specific to Fedora after all.

edit: also, in case anybody coming in from the web is looking for how to remap these keys for a logitech k400. here's what worked for find random odd media keys on fedora. Just make sure that you either can remove into your system with ssh to be able to kill evtest or open a separate terminal and set something like sleep 1m && pkill --signal 9 --full --ignore-case evtest before you start... or just have a spare keyboard / mouse handy to close the terminal window.

terminal 1:

$ sudo dnf install -y evtest
$ sleep 1m && pkill --signal 9 --full --ignore-case evtest

terminal 2: click to make sure it has focus then run evtest --grab /dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse then just press the key you're interested in. it should ignore the key but I'd start with something other than sleep/poweroff first just to make sure that you have the correct keyboard.

for the k400, I had the following:

The following does seem to remap these keys... but it seems like the "Lock PC" button is literally sending left meta / super / "windows" key + L so I'm not sure if there is going to be a way to remap this guy that doesn't also affect the Super + L combo using the normal left meta key. AFAICT this is a limitation of the keyboard... not a big deal for those that use Ctrl+Alt+L or don't lock their screens but more challenging for those who do use Super + L for locking their screen.

$ cat mediakeys.m2 
// confirm media key mappings
KEY_CONFIG::m;
KEY_HOMEPAGE::h;
#l::n;
KEY_SLEEP::p;
 
map2 -d event4.list mediakeys.m2

from map2.

Hi, thanks for trying out map2, I'll make sure the docs will be way easier to understand in the second release I'm currently working on.
You only need 1 fd for your mouse, if you know which one it is you can point directly to it i.e. /dev/input/eventX or use the by-path or by-id folders which just provide symlinks with human-readable names.
It's trial and error for now (I'll have a better solution ready in the second release), but it's most likely something ending with event-mouse for your mouse and event-keybaord for keyboards, so you probably want /dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse.

It might be that since you're giving it 2 symlinked fds which point to the same fd you get a resource busy error when map2 tries to lock it twice, but I can't say for sure. Try it out with just one fd and we can go from there. Not sure if I can be of much help since there can be any number of reasons why the fd doesn't get grabbed, but try the obvious thing at first and we'll see :D

from map2.

Thanks! ok, so removing the second entry and running with sudo does seem to get rid of the errors...

$ cat devices-event4.list
/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse
 
$ cat example.m2 
// maps 'a' to 'b'
a::b;
 
$ sudo map2 -d devices-event4.list example.m2
//no output or errors from above command

Unfortunately, it just... doesn't do anything; e.g. the script doesn't seem to be actually remapping a to b. I was trying to test by just opening up xed and typing a into it. I forgot to turn off selinux initially but also retried with it off; didn't make a difference though.

As a side note, I also found out that changing perms under /dev/input/<whatever-the-symlink-maps-to> seems to make it so that running with sudo is no longer required. This might be worth noting in the revised documentation :-)

$ map2 -d devices-event4.list example.m2 
thread 'tokio-runtime-worker' panicked at 'failed to open fd '/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse': Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', /home/shiro/project/map2/src/device/virtual_input_device.rs:88:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  
$ ls -acl /dev/input/event4
crw-rw----. 1 root input 13, 68 Jan 10 22:13 /dev/input/event4
$ sudo chmod o+r /dev/input/event4
$ map2 -d devices-event4.list example.m2
//no output or errors from above command

alternately, it seems like you can just add your user to the input group to do the same thing (not sure if this part is specific to fedora or not).

$ sudo chmod o-r /dev/input/event4
  
$ map2 -d devices-event4.list example.m2 
thread 'tokio-runtime-worker' panicked at 'failed to open fd '/dev/input/by-id/usb-Logitech_USB_Receiver-if02-event-mouse': Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', /home/shiro/project/map2/src/device/virtual_input_device.rs:88:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
  
$ sudo usermod -aG input $USER
// hack to log you into new shell so as to have group membership take place
// otherwise just log out and back in
$ su - $USER
$ cd /tmp/map2
$ map2 -d devices-event4.list example.m2
//no output or errors from above command

from map2.

You probably don't have an a key on your mouse that you're grabbing, so you might be looking for a keyboard device instead :) (usually will have a fd name ending with -event-keybaord), Mouse axis mapping is currently not supported.

I'll check if the input group is fedora specific, thanks for the pointer. Usually changing permissions won't persist after a reboot, so you'd have to setup udev rules, which is somewhat out of scope for my documentation, but I'll add some links to disto wiki entries. (should work the same everywhere since it's just udev)

from map2.