Logitech MX Keys (via Logitech Unified receiver) not detected as keyboard

[rroels]

The currect way of detecting keyboards fails with devices that are both mice and keyboards. An example of this, is the Logitech Unified Receiver dongle.

In input.py, in the method is_keyboard_device(...), the following check just rejects it as a keyboard:

def is_keyboard_device(device):
  ...
  if Key.BTN_MOUSE in supported_keys:
          # Mouse.
          return False
  ...
  return True

In this case, a Logitech Unified Receiver is rejected because it has support for BTN_MOUSE, even though it's also the connector for my wireless keyboard.

It would be nice if this check can be improved to accept keyboard devices that also have support for BTN_MOUSE.

The device capabilities for my Logitech MX Keys keyboard (connected via Logitech Unifying dongle) look like this:

device /dev/input/event21, name "Logitech MX Keys", phys "usb-0000:00:14.0-7.4/input2:1"
{0: [0, 1, 2, 3, 4, 17, 20], 1: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 113, 114, 115, 116, 117, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 142, 143, 144, 150, 152, 155, 156, 158, 159, 161, 163, 164, 165, 166, 167, 168, 169, 171, 172, 173, 174, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 206, 207, 208, 209, 210, 212, 216, 217, 219, 223, 224, 225, 228, 229, 230, 231, 232, 233, 234, 235, 240, 241, 244, 256, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 353, 354, 358, 362, 366, 370, 372, 374, 375, 376, 377, 378, 379, 380, 381, 383, 384, 386, 387, 389, 392, 393, 396, 397, 398, 399, 400, 401, 402, 403, 405, 407, 408, 409, 410, 412, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 439, 442, 576, 577, 578, 579, 580, 581, 582, 583, 584, 585, 592, 593, 608, 609, 610, 611, 612, 613], 2: [0, 1, 6, 8, 11, 12], 3: [(32, AbsInfo(value=0, min=1, max=767, fuzz=0, flat=0, resolution=0))], 4: [4], 17: [0, 1, 2, 3, 4]}

[joshgoebel]

I think perhaps if we checked for QWERTY + A +Z that perhaps we could then drop the "BTN_MOUSE" requirement?

[joshgoebel]

What I think works:

QWERTY = [Key.Q, Key.W, Key.E, Key.R, Key.T, Key.Y]
A_Z_SPACE = [Key.SPACE, Key.A, Key.Z]

@rroels Does your keyboard have all these keys?

[rroels]

@joshgoebel yes, it does. The Logitech MX Keys keyboard is a relatively standard keyboard:

It's only the OS that seems to think it has support for BTN_MOUSE, which isn't true.

[joshgoebel]

My new keyboard detection code:

    if qwerty and az:
        return True
    # Otherwise, its not a keyboard!
    return False

Which is going to give us everything other than say numpad only keyboards... but problem for another day.

[ian-h-chamberlain]

I found this issue while trying to debug my Logitech G604 mouse (for which I have some keyboard macros assigned to buttons).

XKeysnail seems to work with the mouse while it's using Bluetooth (showing a corresponding device /dev/input/event26 G604 LIGHTSPEED Keyboard), but it's not working when I switch to use the USB receiver.

I tried the above changes as well as forcing the --device to work on the USB mouse, but if I do anything that causes the mouse to "look like a keyboard", the pointer stops working (which I guess is expected? https://github.com/mooz/xkeysnail/issues/85#issuecomment-1150666297).

I'm wondering if there is any way for me to force xkeysnail to behave the same way when the mouse is using the USB as it does for Bluetooth, but I guess they register as "different" devices so maybe not?

Also seems like https://github.com/joshgoebel/keyszer/issues/123 might be related to this (although I haven't had a chance to try keyszer yet to see if the behavior is different).

[joshgoebel]

USB and bluetooth drivers can be very different...

BUT If you can it's best not to run your mouse thru Keyser at all... use --device to manually specify only actual keyboard devices if the auto-detection is confused (since your mouse is saying it's a keyboard so it can type).

[ian-h-chamberlain]

USB and bluetooth drivers can be very different...

BUT If you can it's best not to run your mouse thru Keyser at all... use --device to manually specify only actual keyboard devices if the auto-detection is confused (since your mouse is saying it's a keyboard so it can type).

yeah, I guess that makes sense. In the linked keyszer issue I guess having the skip_device feature would be helpful (and then I could just map the mouse macros to their "unmapped" versions and bypass rebinding altogether). Ok, I guess I will wait for that and just stick to using one or the other of bluetooth/dongle for now, thanks!