Keyboard is treated as a mouse

[Oreolek]

Hi. I have a programmable keyboard but I can't bind it in sway because it's treated as a mouse.

bindcode --input-device="5426:273:Razer_Razer_Nostromo" --whole-window 77 exec 'ydotool key "n+enter"'

Error: [...] Event code 77 (KEY_KP6) is not a button

bindsym --input-device="5426:273:Razer_Razer_Nostromo" --whole-window w exec 'ydotool key "n+enter"'

Error: [...] Unknown button w

I looked at the source code and apparently these messages don't mean sway doesn't know a button "w", it doesn't know a mouse can have one and treats my keyboard as a mouse.

The device in question has a scroll wheel so technically it combines a mouse and a keyboard. But having only a scroll wheel and no other buttons is not great.

[emersion]

Your bug report is missing debug logs. Please add a link to the full debug log file.

Also attach the output of sudo libinput list-devices.

[Oreolek]

relevant debug log section:

2020-06-14 17:49:53 - [sway/config.c:795] Read line 45: bindsym --input-device="5426:273:Razer_Razer_Nostromo" --whole-window w exec 'ydotool key "n+enter"'
2020-06-14 17:49:53 - [sway/commands.c:372] Config command: bindsym --input-device="5426:273:Razer_Razer_Nostromo" --whole-window w exec 'ydotool key "n+enter"'
2020-06-14 17:49:53 - [sway/commands.c:392] After replacement: bindsym --input-device="5426:273:Razer_Razer_Nostromo" --whole-window w exec 'ydotool key "n+enter"'
2020-06-14 17:49:53 - [sway/config.c:828] Error on line 45 'bindsym --input-device="5426:273:Razer_Razer_Nostromo" --whole-window w exec 'ydotool key "n+enter"'': Unknown button w (/home/alexander/.config/sway/config)

UPD: installed libinput-tools, here's libinput output:

Input device: Razer Razer Nostromo
  Type: Mouse
  Identifier: 5426:273:Razer_Razer_Nostromo
  Product ID: 273
  Vendor ID: 5426
  Libinput Send Events: enabled

Input device: Razer Razer Nostromo
  Type: Keyboard
  Identifier: 5426:273:Razer_Razer_Nostromo
  Product ID: 273
  Vendor ID: 5426
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled

swaymsg -t get_inputs:

Input device: Razer Razer Nostromo
  Type: Mouse
  Identifier: 5426:273:Razer_Razer_Nostromo
  Product ID: 273
  Vendor ID: 5426
  Libinput Send Events: enabled

Input device: Razer Razer Nostromo
  Type: Keyboard
  Identifier: 5426:273:Razer_Razer_Nostromo
  Product ID: 273
  Vendor ID: 5426
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled

[emersion]

Sounds like the keyboard and the mouse have the same device identifier.

[Oreolek]

Well it is one device. It has keys but also can send mouse clicks and scroll wheel events. I reckon the mouse devices with programmable keys would also send something similar.

[Xyene]

Hmm, at least my Logitech G502 mouse doesn't:

Input device: Logitech G502 HERO SE Keyboard
  Type: Keyboard
  Identifier: 1133:49291:Logitech_G502_HERO_SE_Keyboard
  Product ID: 49291
  Vendor ID: 1133
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled

Input device: Logitech G502 HERO SE
  Type: Mouse
  Identifier: 1133:49291:Logitech_G502_HERO_SE
  Product ID: 49291
  Vendor ID: 1133
  Libinput Send Events: enabled

However, my keyboard does do the same thing:

Input device: Kinesis Advantage2 Keyboard
  Type: Keyboard
  Identifier: 10730:258:Kinesis_Advantage2_Keyboard
  Product ID: 258
  Vendor ID: 10730
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled

Input device: Kinesis Advantage2 Keyboard
  Type: Mouse
  Identifier: 10730:258:Kinesis_Advantage2_Keyboard
  Product ID: 258
  Vendor ID: 10730
  Libinput Send Events: enabled

Perhaps we could allow combined syntax like input mouse 5426:273:Razer_Razer_Nostromo or similar to disambiguate in these cases?

[emersion]

Perhaps it's because the keyboard appears first in your setup. Maybe we should stop assuming one input identifier == one input device and allow an identifier to match multiple devices? In practice this probably means chasing down break in loops.

[emersion]

… But that won't work well if we do need to refer to a single specific input device in the config (do we?). In which case maybe we need a better identifier (ref swaywm/wlroots#403).

[Xyene]

Maybe we should stop assuming one input identifier == one input device and allow an identifier to match multiple devices?

I think that'd probably work well enough here.

But that won't work well if we do need to refer to a single specific input device in the config (do we?).

I can think of the case where you'd have two of the same input device attached, and would want to configure one independently of the other. This sounds super niche, though. I can't imagine any situations where you'd want to configure two of the same devices differently in anything resembling a "common" setup, and it sounds like the type of thing someone would open an issue for if they actually needed.

I can also think of a hypothetical keyboard device where recorded macros come from a different input device, and where you might want to apply different keybindings (specifically none) to macro'd input. But, this also sounds very niche, and I'm not sure if such a device actually exists.

[schauveau]

@Xyene A common case could be a machine with two keyboards of the same model but with different layouts.

In theory, those 'identical' devices can be differentiated using the phys property associated to each device.

for i in /sys/class/input/event* ; do echo -n "$i " ; cat $i/device/phys ; done

Unfortunately, libinput does not seem to provide that information (I only had a kick look at the API so I could be wrong). Also, the phys value is unlikely to help for multiple devices provided by the same physical source.

[Xyene]

A common case could be a machine with two keyboards of the same model but with different layouts.

Agreed, but while it may be worthwhile to support this, I'd hesitate to call this use-case common.

Unfortunately, libinput does not seem to provide that information

I haven't taken a close look at the relevant API, but at the very least you can obtain the evdev node that you'd could use to get at any other information, so it should be possible.

[RedSoxFan]

The following requires the user to be in the input group, but allows for that phys property to be accessed:

char *get_phys(struct libinput_device *libinput_device) {
    // TODO: Add better error handling and logging
    struct udev_device *udev_device =
        libinput_device_get_udev_device(libinput_device);
    const char *devnode = udev_device_get_devnode(udev_device);

    int fd = open(devnode, O_RDONLY|O_NONBLOCK);
    struct libevdev *libev_device;
    if (libevdev_new_from_fd(fd, &libev_device) < 0) {
        close(fd);
        udev_device_unref(udev_device);
        return NULL;
    }

    const char *ev_phys = libevdev_get_phys(libev_device);
    char *phys = strdup(ev_phys);
    libevdev_free(libev_device);
    close(fd);
    udev_device_unref(udev_device);
    return phys;
}

Maybe something like the following would work to solve both this and #3608:

input *
input type:<type>
input [--type=<type>] --phys=<phys>
input [--type=<type>] [--phys=<phys>] <identifier>

Unfortunately, the layering gets a bit messy there.