Keychron keyboard configuration & firmware upates via launcher.keychron.com

As keychron is quite a popular brand of mechanical keyboards,
and the information about using https://launcher.keychron.com/ sucessfully on Arch based-distros is a bit cumbersome, as it only sets permission momentarily to access /dev/hidraw*.

Therefore I just wanted to share the info how to setup a udev rule properly, without using plugdev, which seems to be ill advised as stated here.

In short, if you want to configure your keychron keyboard, you’ll need a browser that has WebUSB support (my choice would be ungoogled-chromium-bin). If you’re uncertain if WebUSB isn’t enabled, check permissions via chrome://settings/content/usbDevices. Forks of Firefox don’t support WebUSB, thus you’re stuck to those forks of chrome.

If you’re using a wireless keyboard, in order to configure it properly, you should enable the wired mode of the keyboard and connect it via USB, it won’t work if you’re in wireless model, even if you’re using a keychron link usb reciever to connect the device.

First of all, you’ll need to identify your keyboard via lsusb -d 3434: that should list all keychron devices currently connected via usb. If should report back something like:

Bus 001 Device 002: ID 3434:0a51 Keychron Keychron K5 Max
Bus 001 Device 008: ID 3434:d030 Keychron  Keychron Link 

We’ll need the vendor ID (3434) as well as the device ID (in this case: 0a51 for my K5 Max).
If you want to update the firmware of the Keychron Link as well, you should also take note of it’s device ID (d030 for mine, there might be different hardware revisions, thus you should better check.)

(you may also retrieve those ID’s via chrome://device-log/ … but those are in decimal notation and we need the hex notation for the udev rules)

Based upon the vendor & device ID’s we could now define a custom udev rule in the /etc/udev/rules.d drop-in configuration folder:

sudo nano /etc/udev/rules.d/50-keychron.rules

and add those entries:

SUBSYSTEM=="hidraw", ATTRS{idVendor}=="3434", ATTRS{idProduct}=="0a51", MODE="0660",  TAG+="uaccess""

That should allow the required premission for the keyboard to be configured via WebUSB. Unlike the source, where I found that udev rule, it’s not required to set MODE="0666", "0660" is sufficient.

To enable the firmware flashing capabilities, which is usually done via the STM bootloader of the keyboard, which has to be enabled as per instructions of the launcher in DFU mode via connecting it to usb with the escape key pressed down, this last rule should enable the firmware flashing procedure. The idVendor should be 0483 and idProduct df11 and should be universal for all STM devices in DFU mode.

SUBSYSTEM=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="df11", MODE="0660", TAG+="uaccess"

Last but not least If you additionally want to flash the firmware of a Keychron Link reciever, add:

SUBSYSTEM=="usb", ATTRS{idVendor}=="3434", ATTRS{idProduct}=="d030", MODE="0660", TAG+="uaccess"

After the file is written, you should execute

sudo udevadm control --reload-rules as well as
sudo udevadm trigger --subsystem-match=hidraw --action=add and
sudo udevadm trigger --subsystem-match=usb --action=add if you want firmware updating functionality.

To check, simply ls -l /dev/hidraw* if the permissions have been set. The keychron devices should be listed as crw-rw----+ 1 root root via hidraw

Or simply visit https://launcher.keychron.com and once you’ve connected to the HID device, you should be directlly redirected to current keymap overview to make changes.

2 Likes

Thanks! This worked great for my K10 HE right up to the last step where my permissions don’t match.

$ ls -l /dev/hidraw*
crw-------  1 root root  243,  0 Oct 20 21:29 /dev/hidraw0
crw-------  1 root root  243,  1 Oct 20 21:29 /dev/hidraw1
crw-------  1 root root  243, 10 Oct 20 21:29 /dev/hidraw10
crw-------  1 root root  243,  2 Oct 20 21:29 /dev/hidraw2
crw-------  1 root root  243,  3 Oct 20 21:29 /dev/hidraw3
crw-------  1 root root  243,  4 Oct 20 21:29 /dev/hidraw4
crw-------  1 root root  243,  5 Oct 20 21:29 /dev/hidraw5
crw-------  1 root root  243,  6 Oct 20 21:29 /dev/hidraw6
crw-------  1 root root  243,  7 Oct 20 21:29 /dev/hidraw7
crw-rw----+ 1 root users 243,  8 Oct 20 21:29 /dev/hidraw8
crw-rw----+ 1 root users 243,  9 Oct 20 21:29 /dev/hidraw9

But the website loads and lets me configure the keyboard, so all is well! :+1:

1 Like

The source article created those udev rules with the additional parameters GROUP="users" & TAG+="udev-acl". Those aren’t strictly required if I’m not mistaken. For the basic functionality to configure the keymap and backlight settings at least.

Thus, if the firmware update functionality doesn’t work correctly, you may want to add those to your udev rule.

This reminds me to check the firmware updates on my keychron. I don’t think I needed any magic to update it, just used Brave browser while had USB connected.

So, every time you want to configure using the launcher website you need to execute the trigger commands or the “connect” button will fail. I combined the three into one which I’ll probably make into an alias when I get fed up enough.

sudo udevadm control --reload-rules && sudo udevadm trigger --subsystem-match=hidraw --action=add && sudo udevadm trigger --subsystem-match=usb --action=add

If I’m not mistaken you’ll only need to reload the rules once, when the new file within /etc/udev/rules.d/ has been created and the udevadm trigger would be required to adapt the new udev rules when they’re plugged in already. In short: the rules should be applied when they’re plugged in.

Anyway, as I’ve mentioned in my last comment, I removed the parameters GROUP="users" as well as the TAG+="udev-acl" and up so far I haven’t found in depth details on the udev-acl tag, other than mentions that it’s often combined with uaccess and would address backward compatibility issues. Using both would be somewhat redundant, bothprovide an access‑control list for the device, udev-acl does it for the current user session, uaccess does this as well, but on top of that the access permissions are set for the current systemd‑logind additionally.

Up so far, from my objections during testing that udev rules, the permissions are set automatically, at least for the hidraw subsystem as I plug the device in and I can use the keychron launcher without the need of granting the permissons manually, which has been the whole point of creating those udev rules. I haven’t tested the firmware flashing part extensively, as I don’t want to reset and update the firmware only for testing purposes, as I don’t want to brick it in the process.