Not working with Logitech MX Keys

[rroels]

Describe the bug
On my Lenovo laptop, Kinto.sh works fine with the internal keyboard, as well as with other USB keyboards. However, it does not work for the Logitech MX Keys keyboard.

Kinto.sh seems to be running fine. The laptop's internal keyboard is properly remapped. However, nothing seems to be remapped for the external Logitech MX Keys keyboard.

As mentioned, I tried other USB keyboards and those worked fine.

Expected behavior
I expected keys on the Logitech MX Keys keyboard to be remapped, just like with any other keyboard.

Install Type: Bare Metal
Distro: Manjaro 21.2.2
DE: Gnome 41.3
Kinto Version: Kinto v1.2-11 build 6b3ea9a

Logs and service status do not seem to indicate any issues.

xkeysnail.service - xkeysnail
     Loaded: loaded (/usr/lib/systemd/system/xkeysnail.service; disabled; vendor preset: disabled)
     Active: active (running) since Mon 2022-01-31 09:43:49 CET; 5min ago
   Main PID: 5588 (sudo)
      Tasks: 2 (limit: 38165)
     Memory: 17.1M
        CPU: 1.145s
     CGroup: /system.slice/xkeysnail.service
             ├─5588 /usr/bin/sudo /bin/bash -c "/usr/bin/xhost +SI:localuser:root && /home/rroels/.config/kinto/killdups.sh && /usr/bin/xkeysnail --quiet --watch /home/rroels/.config/kinto/kinto.py"
             └─5589 /usr/bin/python /usr/bin/xkeysnail --quiet --watch /home/rroels/.config/kinto/kinto.py

Jan 31 09:43:49 iris systemd[1]: Started xkeysnail.
Jan 31 09:43:49 iris sudo[5588]:     root : PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/bin/xhost +SI:localuser:root && /home/rroels/.config/kinto/killdups.sh && /usr/bin/xkeysnail --quiet --watch /home/rroels/.config/kin>
Jan 31 09:43:49 iris sudo[5588]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Jan 31 09:43:49 iris sudo[5590]: localuser:root being added to access control list

Jan 31 09:43:49 iris systemd[1]: Stopped xkeysnail.
Jan 31 09:43:49 iris systemd[1]: Started xkeysnail.
Jan 31 09:43:49 iris sudo[5588]:     root : PWD=/ ; USER=root ; COMMAND=/bin/bash -c /usr/bin/xhost +SI:localuser:root && /home/rroels/.config/kinto/killdups.sh && /usr/bin/xkeysnail --quiet --watch /home/rroels/.config/kin>
Jan 31 09:43:49 iris sudo[5588]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=0)
Jan 31 09:43:49 iris sudo[5590]: localuser:root being added to access control list

I rely on Kinto.sh so much that I'd be more than happy to help create the fix. However, I'm going to need some help in diagnosing the issue.

Please let me know if you need any other information.

[rroels]

This seems to be the same issue as #275
xkeysnail does not detect the MX Keys as a keyboard, unless I tell it to, with the --devices option

As a temporary "hack" I just modified /usr/lib/systemd/system/xkeysnail.service and manually listed my keyboards:

ExecStart=/usr/bin/sudo /bin/bash -c '/usr/bin/xhost +SI:localuser:root && /home/rroels/.config/kinto/killdups.sh && /usr/bin/xkeysnail --quiet --watch /home/rroels/.config/kinto/kinto.py --devices "Logitech MX Keys" "AT Translated Set 2 keyboard"'

It's not a proper solution, but it does allow me to use my MX Keys for now...
Warning: if you do this, kinto/xkeysnail will only work for the keyboards you specify in --devices, not for anything else!

[rroels]

To follow up, the "hack" above was giving me some other issues.

In the end I think it's something that is better fixed in xkeysnail. I posted the following issue with xkeysnail:
mooz/xkeysnail#151

In the meantime, as an equally disgusting temporary workaround I've manually patched my /usr/lib/python3.10/site-packages/xkeysnail/input.py so it looks like this (note the "Logitech MX Keys" check):

def is_keyboard_device(device):
    """Guess the device is a keyboard or not"""
    capabilities = device.capabilities(verbose=False)

    if "Logitech MX Keys" in device.name:
        return True

    if 1 not in capabilities:
        return False
    supported_keys = capabilities[1]
    if Key.SPACE not in supported_keys or \
       Key.A not in supported_keys or \
       Key.Z not in supported_keys:
        # Not support common keys. Not keyboard.
        return False
    if Key.BTN_MOUSE in supported_keys:
        # Mouse.
        return False
    # Otherwise, its keyboard!
    return True

[rbreaves]

Awesome, disgusting or not if it solves the problem then it works. I will look at merging this into my fork of xkeysnail later! Thank you for digging into it!

Also for roughly the past week a bug existed that caused my fork to give out the latest xkeysnail v0.4, you need v0.3, please backup your changes (rename for your folder) and re-clone the latest version of Kinto so that the proper held keys behavior will occur. (otherwise things like Alt-Tab may break)

[joshgoebel]

On my list of things to add to the configuration file is add_device. joshgoebel/keyszer#19

So we could just do:

add_device "Logitech MX Keys"

I think having a long list of "valid" hardware devices in the config file itself would make a lot more sense than hard-coding them into the source. Then as we find more exception devices over time we can juse add more add_device lines to the config...

Open to suggestions on the naming.

[joshgoebel]

What is it about the MX that's preventing it from working though? Does it not have capability 1 or does it have a BTN_MOUSE buttons? The criteria is actually pretty simple...

[rroels]

I think the issue is that the OS claims that the device has a BTN_MOUSE. The system says these are the device capabilities:

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]}

BTN_MOUSE translates to code 272 (which is in the list). I'm slightly confused by this, since the keyboard doesn't actually have any mouse buttons. This is a relatively standard keyboard, doesn't have a scrollwheel or anything like that.

One possible explanation is that the keyboard is connected via one of those Logitech Unifying Receiver dongles. My Logitech mouse is also connected via the same dongle. Perhaps the device capabilities reported by the OS include all the capabilities of all the devices connected to the dongle.

Either way, the main issue is that the device supposedly has a BTN_MOUSE so it's immediately disqualified as a keyboard.

[joshgoebel]

BTN_MOUSE translates to code 272 (which is in the list).

Yep, that's our problem. My fork already fixes this by changing how "what is a keyboard" is defined...

My Logitech mouse is also connected via the same dongle.

Highly plausible this is the issue. Is there a single /dev/input device vs one for the keyboard and mouse? Do mouse events come in on event when you test with evtest?

[rbreaves]

On my list of things to add to the configuration file is add_device

Yea.. looking back it is sad that I have essentially forgotten to ever get around to adding the literally coded up fix here in this thread already lol. I am glad that you are picking it up though for your fork @joshgoebel that is really awesome!

[rbreaves]

I now have an mx logitech keyboard btw. Will be testing with it soon.

[Jozott00]

Got the same issue with my Logitech ERGO K860 connected via an unifying receiver.

[darkowic]

I will look at merging this into my fork of xkeysnail later! Thank you for digging into it!

@rbreaves is there anything we can do to help with this?

[exetico]

I'd like to bump this too. How's the best way to use MX Keys on Manjaro?

I can see that joshgoebel/keyszer#19 is still open.

Btw. My issue regarding "MX Keys identified as mouse" on the Manjaro forum, but unrelated to Kinto, has passed 1K views 💣: https://forum.manjaro.org/t/logitech-mx-keys-keyboard-identified-as-event-mouse-instead-of-event-kbd/83127

It's crazy that it's still the same issue, and havn't been patched. Sadly I don't have the proper skills to fix is in the Linux kernel or anything like that. But I've moved to MacOS on my work-machine, and really find it annoying to remember my "Ctrl"-skills, so Kinto.sh is starting to become a "must-have" util on my other workstation with Manjaro 😄 .

I've also edited `/usr/lib/python3.10/site-packages/xkeysnail/input.py' and replaced:

def is_keyboard_device(device):
    """Guess the device is a keyboard or not"""
    capabilities = device.capabilities(verbose=False)
    if 1 not in capabilities:
        return False
    supported_keys = capabilities[1]
    if Key.SPACE not in supported_keys or \
       Key.A not in supported_keys or \
       Key.Z not in supported_keys:
        # Not support common keys. Not keyboard.
        return False
    if Key.BTN_MOUSE in supported_keys:
        # Mouse.
        return False
    # Otherwise, its keyboard!
    return True

with:

def is_keyboard_device(device):
    """Guess the device is a keyboard or not"""
    capabilities = device.capabilities(verbose=False)

    if "Logitech MX Keys" in device.name:
        return True

    if 1 not in capabilities:
        return False
    supported_keys = capabilities[1]
    if Key.SPACE not in supported_keys or \
       Key.A not in supported_keys or \
       Key.Z not in supported_keys:
        # Not support common keys. Not keyboard.
        return False
    if Key.BTN_MOUSE in supported_keys:
        # Mouse.
        return False
    # Otherwise, its keyboard!
    return True

Thank for the current workaround, rroels.

I also installed xkeysnail manually and now the "active" status in the bottom corner of the Kinto.sh application stays as "active" (instead of jumping to "inactive). However, my Ctrl are not remapped, even though I've selected MacOS.

[RedBearAK]

@exetico

I don't have that type of keyboard, so I can't test, but I'm wondering if my project (Toshy, an offshoot from Kinto) is affected by this issue. It uses keyszer instead of xkeysnail, and the equivalent code in devices.py doesn't seem to have the part where it rejects the device just because it has a mouse button capability.

class Devices:
    @staticmethod
    def is_keyboard(device):
        """Guess the device is a keyboard or not"""
        capabilities = device.capabilities(verbose=False)
        if 1 not in capabilities:
            return False
        supported_keys = capabilities[1]

        qwerty = all(k in supported_keys for k in QWERTY)
        az = all(k in supported_keys for k in A_Z_SPACE)
        if qwerty and az:
            return True
        # Otherwise, its not a keyboard!
        return False

This should accept any device that has the necessary keys to be a "keyboard".

Pretty sure that this is the problem with the xkeysnail example:

    if Key.BTN_MOUSE in supported_keys:
        # Mouse.
        return False

If you were to comment out just the return False there, it should allow your keyboard to be accepted as a device to grab, without explicitly naming the keyboard.

I feel like at least one user of Toshy had a Logitech MX Keys and their main issue was that they had the keyboard in Mac mode but it was being identified as a Windows keyboard. That may also explain why your Ctrl key doesn't seem to be in the right place, though from your description I'm not sure if your Opt/Cmd are swapped or there are no modifiers being remapped (which would indicate a different problem).

There was another user with an MX Keys, and their main issue was using a German layout. So it seems that the device was at least working in general.

You can try Toshy, but you'd need to stop Kinto and disable its auto-start feature, or there would be a conflict between them after installing. Toshy has both a script/command that will disable it from auto-starting when you log in, and a full uninstall option, so it's fairly easy to return to using Kinto by just enabling it and re-enabling its auto-start option.

Open an issue on my repo if you're interested in talking about this.

https://github.com/RedBearAK/toshy/issues