[GUIDE] Updated after firmware updates - udev rules for https://keyboard.frame.work/

Framework Laptop 16
, ,
1

There seems to have been a change for how udev and systemd work in linux distros. Below is the process to get your keyboard, numpad, macropad, etc to show up correctly in your browser (where supported)

(Edit by @Matt_Hartley)

This used for making https://keyboard.frame.work/ work again correctly.

Copy this file to /etc/udev/rules.d/

Edit the file (vim, nano, ect) and append the following (thanks to @mj1 for confirming the device IDs):

SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0012", TAG+="uaccess"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0013", TAG+="uaccess"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0014", TAG+="uaccess"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0018", TAG+="uaccess"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0019", TAG+="uaccess"

Then run:

sudo udevadm control --reload-rules
sudo udevadm trigger

After doing so, your browser should correctly show your keyboard or other device.

5 Likes
[RESPONDED] QMK keyboard setup not working under Linux?
Caps Lock LED Indicator is always on
Volume jumps from mute to 90% randomly without any keyboard input
3

Added needed context for newcomers to the OP’s post, pinned.

3 Likes
4

@Matt_Hartley sorry if this is a silly question but where / how do i find all pinned articles for FW16 / Linux guides?

5

Ideally, folks are not relying on the forums. It’s not designed at all for it and is completely unmaintained outside of community efforts.

Once I have time, this will be converted into a proper KB article.

3 Likes
6

Thanks @Matt_Hartley !!!

1 Like
7

Onya @Matt_Hartley !

8

Can I just wait long enough and trust these changes will eventually trickle down to my machine via normal machine update channels (Fedora)?

9

I dont think so - I think its more-so related to changes in systemd and that lead to this issue.

I dont think this is a firmware related issue (i flasshed the older firmware and couldnt fix it that way) but rather a change that hit after I moved to Fedora 43

1 Like
10

I have keyboard firmware claiming to be 0.3.1, from: Releases · FrameworkComputer/qmk_firmware · GitHub

The old udev rules worked fine

Further, the keyboard still awakens the laptop when the lid is closed.

Are wires getting crossed somehow, e.g. different keyboard firmware there and in fwupdmgr? How do I actually fix the issue? What firmware version/combination is known to fix the problem?

(For avoidance of doubt, yes I’m using 4.0.1 BIOS version, claimed to be sufficient - and there was a message when I upgraded to it that the keyboard firmware needed to be updated, which I did soon afterwards.)

11

This would be a different issue from my guide. I would recommend a new topic specifically on this.

Would likely want to collect some logs in the new post:

  1. what distro
  2. journalctl logs after the keyboard wakes up the laptop
  3. Probably try a manual reinstall of a firmware
12

Thanks a lot! Ive also figured something out that I dont think is documented anywhere:

How the layer change function works: This is tied to the NumLock key in firmware, or so it seems. So if you put the NumLock key in a different location, this will now be the toggle to the other layer.

If you think about it this makes total sense, because pressing numlock gives you additonal keys on a separate layer. I just always thought about NumLock in an office context, without rgb, and huge customizability…

Is there some reason layer changes arent realized through the “Layers” function in VIA?

13

So, I am completely new to linux and I just got my framework 16 up and running. I ran into this issue as well, and would love to take a stab at fixing it as described, but may need some additional hand holding to get started. How do I copy the linked file to “/etc/udev/rules.d/? Is that through terminal? I am running Ubuntu

14

Download the file - ill do this as if it was in downloads:

sudo cp ~/Downloads/50-qmk.rules /etc/udev/rules.d/50-qmk.rules

15

thank you so much!

16

I did this yesterday for my new keyboard. This is what I did @John_Dean1:

  1. Downloaded the file (to my Downloads folder)
  2. Opened it in a text editor and added the 4 lines of text shared to the bottom of the file.
  3. I ran sudo cp ~/Downloads/50-qmk.rules /etc/udev/rules.d/

Then, using chromium I was able to interact with keyboard.frame.work (my browser of choice, Librewolf, does not work with that site).

1 Like
17

@TechPriestNhyk - thanks for adding the full steps. Been a long work week and I left off the “edit the file” steps :slight_smile:

18

But they are? Ignoring numlock for the moment.
In Via, the first 4 layers (0,1,2,3) iirc are normal, Fn+normal, Fn-lock, Fn+Fn-lock.

Numlock is… special.
Normal numlock is not bad, if you understand that it really just works the same as CapsLock. The keyboard does not change its keys when NumLock or CapsLock is on. Rather it’s your OS choosing to change what key is output, when it sees that NumLock or CapsLock has been toggled. And the OS can also choose to ignore toggles too.

Numlock becomes complicated on the FWL16 / qmk / Via. Here, whenever numlock is toggled, some code which FW added triggers a qmk/Via layer change. This is so you have the option of adding keys that do other things while numlock is on. This differs from CapsLock, as pressing caplock does not trigger a qmk/Via layer change (but it could, if one wanted).

How FW does numlock and to a some extent Fn & Fn-lock I feel hasn’t been documented well by FW. At least last I looked, it’s been awhile.