The Framework keyboards do not work by default on the general Via site. The board definition files haven’t been added for them to be automatically recognized. keyboard.frame.work is a Framework hosted copy.
Thanks for the feedback, everyone.
@MJ1 I had tried that rules file after @undermark5 suggested it, but that didn’t do the trick. Thanks for the tip about keyboard.frame.work though, that did eventually work once I found the right udev rule. See below.
Since the udev rule at the QMK Github didn’t work, I ended up finding a Vial tutorial that ended up doing the trick for me. I followed the instructions here to make a device-specific rule here: Configuring udev on Linux - Vial
The rule that I ended up creating that works looks like this:
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0012", MODE="0660", GROUP="users", TAG+="uaccess", TAG+="udev-acl"
2 Likes
What version of Fedora 39 do you have?
The standard Workstation Edition running Gnome.
1 Like
I am having the same problem but without a solution yet 
.
I use Ubuntu 22.04. I have the udev rules from qmk installed and reloaded. I also tried that additional udev rule above (tweaked to my user group just to see if it works). But to no avail.
The framework VIA page shows the same errors:
23:33:21.132
Failed to open the device.
Device: Framework Laptop 16 Keyboard Module - ANSI
Vid: 0x32AC
Pid: 0x0012
23:33:21.146
Received invalid protocol version from device
Device: Framework Laptop 16 Keyboard Module - ANSI
Vid: 0x32AC
Pid: 0x0012
In addition, chrome page chrome://device-log/ shows:
[23:26:14] Failed to open '/dev/hidraw3': FILE_ERROR_ACCESS_DENIED
[23:26:14] Access denied opening device read-write, trying read-only.
But the access rights on this file seems right:
$ ll /dev/hidraw*
crw-rw----+ 1 root plugdev 241, 0 mars 22 23:00 /dev/hidraw0
crw-rw----+ 1 root plugdev 241, 1 mars 22 23:00 /dev/hidraw1
crw-rw----+ 1 root lexa 241, 2 mars 22 23:00 /dev/hidraw2
crw-rw----+ 1 root lexa 241, 3 mars 22 23:00 /dev/hidraw3
crw-rw----+ 1 root lexa 241, 4 mars 22 23:00 /dev/hidraw4
crw-rw----+ 1 root lexa 241, 5 mars 22 23:00 /dev/hidraw5
$ getfacl /dev/hidraw3
getfacl: Removing leading '/' from absolute path names
# file: dev/hidraw3
# owner: root
# group: lexa
user::rw-
user:lexa:rw-
group::rw-
mask::rw-
other::---
For now, apart from rebooting (which I will try soon), I am out of idea 
. Would you have any?
EDIT: Nop, reboot didn’t magically fixed it.
Also adding that I use chromium from snap.
Reading this comment, I tried the following command:
sudo snap connect chromium:raw-usb
But that does not work neither.
I was going to ask if your browser was installed as a normal package.
Snaps can have permission issues. And some snap browser builds just leave out WebHID support. It’s been reported that the snap Brave browser build does. What does this page say for you? https://webapicheck.com/apis/webhid-api
For your udev rule, you have GROUP="lexa"?
If neither of those are the problem, you could try just changing permissions on /dev/hidraw3. Mine is crw-rw-rw-+ on LinuxMint.
What does this page say for you? https://webapicheck.com/apis/webhid-api
API test:
Available on this device (experimental)
For your udev rule, you have
GROUP="lexa"?
Yes
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="32ac", ATTRS{idProduct}=="0012", MODE="0660", GROUP="lexa", TAG+="uaccess", TAG+="udev-acl"
If neither of those are the problem, you could try just changing permissions on /dev/hidraw3. Mine is
crw-rw-rw-+on LinuxMint.
Did not work unfortunately 
$ ll /dev/hidraw*
crw------- 1 root root 241, 0 mars 23 00:21 /dev/hidraw0
crw------- 1 root root 241, 1 mars 23 00:21 /dev/hidraw1
crw-rw----+ 1 root lexa 241, 2 mars 23 00:21 /dev/hidraw2
crw-rw-rw-+ 1 root lexa 241, 3 mars 23 00:21 /dev/hidraw3
crw-rw----+ 1 root lexa 241, 4 mars 23 00:21 /dev/hidraw4
crw-rw----+ 1 root lexa 241, 5 mars 23 00:21 /dev/hidraw5
Stilll the same access denied error message in chrome://device-log/.
At that point, I would try a non-snap browser build. Rule out an unseen snap permission issue.
Also, you should be able to simplify your udev rule to just
KERNEL=="hidraw*", MODE="0660", GROUP="lexa", TAG+="uaccess", TAG+="udev-acl"
1 Like
Ah! I was doing just that 
.
It works! Using deb package from google chrome itself…
So. that does indeed point to a snap permission issue (once again, snap is the culprit of something mysteriously not working…).
1 Like
Quite the pain that it claims it has WebHID support when the permissions to actually use it are missing.
Yes. But I guess it only checks if it can instantiate the API without trying to make an actual real access to a device.
I will see later if I can investigate the snap issue. For now, I have a layout to change 
.
Thanks for your help!
1 Like
I had to add 50-qmk.rules file to OpenSUSE Tumbleweed, then was able to tweak my keyboard via keyboard.frame.work using Chromium (but not Firefox).
Cheers!
1 Like
Via requires a browser with WebHID enabled. It works in Chrome, Edge, and other Google Chromium-based browsers.
Firefox has chosen not to enable WebHID.
Mozilla, which makes Firefox, believes that websites should not have low level access to hardware, so they have chosen not to enable WebHID, for the same reasons that they don’t support WebUSB.
mozilla.github.io/standards-positions/#webusb
mozilla.github.io/standards-positions/#webhid
Mozilla’s / Firefox’s Position
Because many USB devices are not designed to handle potentially-malicious interactions over the USB protocols and because those devices can have significant effects on the computer they’re connected to, we believe that the security risks of exposing USB devices to the Web are too broad to risk exposing users to them or to explain properly to end users to obtain meaningful informed consent. It also poses risks that sites could use USB device identity or data stored on USB devices as tracking identifiers.
Via has an electron wrapper that could also be used github.com/the-via/releases/releases (you need to load the Framework draft definition). But I found it hard to get it to detect a keyboard reliably.
One of the reason I much prefer Vial. It has desktop apps for Windows, Linux, Mac. Doesn’t rely on a website and giving it low level access to hardware. Though Vial does still offer a website configurer if you so desire.
2 Likes
For keyboard:
- Start off first by updating the firmware is you have not done so yet. You’ll want firmware 0.2.9.
- Get Rust installed:
curl --proto '=https' --tlsv1.2 -sSf [https://sh.rustup.rs](https://sh.rustup.rs/) | sh - Get udev rules ready:
cd Downloads && wget https://raw.githubusercontent.com/qmk/qmk_firmware/master/util/udev/50-qmk.rules && sudo cp 50-qmk.rules /etc/udev/rules.d/ && sudo udevadm control --reload-rules && sudo udevadm trigger && git clone https://github.com/FrameworkComputer/qmk_hid.git && cd qmk_hid
-
Inside the qmk_hid directory:
cargo run
then
cargo build
then
./target/debug/qmk_hid -
Playing with RBG effects like:
./target/debug/qmk_hid via --rgb-effect 21 -
Web UI is best with Chrome.
-
I recommend bouncing between the Via web UI and the Rust application as each has its benefits.
4 Likes
For the record: I’m on Ubuntu 22.04 and I had Chromium installed via apt install chromium-browser, and I had the same issues. Installing the .deb for Chrome itself fixed it.
Thanks.
Yeah, ubuntu hijacks some apt install’s and redirects them to snap. It’s one of the things that pushes people away from ubuntu and over to Mint instead (based on ubuntu but has snap disabled by default).
The procedure in the firmware update instructions doesn’t work properly on my Arch installation. The folder for firmware files does not pop up (I’m certain it’s my own issue with my custom desktop environment where launching default app and URL handlers is not ironed out).
Is there an alternative way to navigate to the correct location?