this post was submitted on 30 Jul 2026
354 points (99.2% liked)
Technology
86757 readers
2591 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
You can configure Keychron peripherals via their website - Keychron Launcher.
It works on Linux, but there are two caveats:
I've tested it with my Keychain K3 keyboard and M4 mouse and it works.
I agree a compatibility with ex. Piper would be neat though
Be careful with this. These udev rules usually grant uaccess to your entire keyboard. uaccess is explicitly disabled for keyboards by default because it presents the event device to all of userspace, which allows any unprivileged app to log all key presses. This includes any malicious scripts running in a browser. If you do want to set up these rules, use them only for the single session you're setting up your device and don't type any passwords with it active, or change them immediately after (you won't be able to remove them without your sudo password).
For the same reason, stop using OpenRGB for devices that don't have kernel drivers.
You're right, one of the guides I've found explicitly mentioned that, and recommended toggling the rules on only when you need it.
If I'm not mistaken, you can make rules per device ID. Keychron devices show up as a keyboard/mouse and a "Link" device. You could make a passthrough rule just for the Link, thus not granting access to the actual input device.
Could you elaborate on the OpenRGB thing? I've used it a few times but never paid attention to the rules it asks for
That's great, just be sure your rules are specific enough for that device but didn't rely on some randomness for detection. I.e. Matching on the current evdev or hidraw devnode is bad because it can shift with more devices being added, changing ports, or some randomness in enumeration speed. Instead, do an attribute walk on the devnode to find specific unique attributes for that node, such as VID + PID + subsystem + bInterfaceNunber should be unique. Things like names and phys patch aren't guaranteed to be unique or consistent in different operating modes. You'll also want to check the devnodes of the other interfaces to be sure they won't match by doing a test.
The commands for those things are:
udevadm info -a /path/to/devnodeudevadm test /path/to/devnodeSure. While not technically necessary for some devices, they have pretty open blanket udev rules. This is because most keyboard devices require the use of hid reports directly to the device to make changes.
From their page:
Notice the complete lack of warning about any security issue from doing this.
If they wanted to be secure they could make a root level daemon that does all the hardware interfacing, and provide a dbus interface managed through polkit to allow making those changes from the userspace UI.
I REALLY fucking wish people would stop targeting Chromium for their apps.
I agree, but at least it's not an app you have to download, which turns out to be Electron/CEF/etc.