[RESPONDED] Help configuring FW16 keyboard with VIA

To those of you lucky enough to have received your Framework 16 as I have, I’m wondering if anyone has figured out how to perform QMK configuration using VIA’s web platform.

I’m running Fedora 39. I’ve tried several Chromium browsers including Brave, Ungoogled Chromium, Chromium, and Google Chrome. I see the dialog where I choose my keyboard and click Connect. The dialog closes and nothing happens. The web page still shows the weird graphic that rolls back and forth. If I click Authorize Device again, the dialog now shows that the keyboard is paired, but still nothing happens.

Does the Framework 16 not ship with the necessary firmware? Is there an incompatibility with Fedora or Linux? Am I being thick?

Edit: I just discovered the Framework domain keyboard.frame.work which seems like a wrapper for usevia.app. Anyway, I tried it there and it still fails, but at least I get an error message there. I see the following two errors:

19:08:28.158
Failed to open the device.
Device: Framework Laptop 16 Keyboard Module - ANSI
Vid: 0x32AC
Pid: 0x0012

19:08:28.169
Received invalid protocol version from device
Device: Framework Laptop 16 Keyboard Module - ANSI
Vid: 0x32AC
Pid: 0x0012

You need to make sure that you’ve correctly configured your udev rules. the QMK repo has a copy that you should be able to copy directly into your conf.d folder and then reload the udev rules and then it should work.

1 Like

This is what’s seen when you need to add the udev rules which undermark5 mentioned.

What version of Fedora 39 do you have?
This has been reported on KDE and Silverblue, but not yet on regular Fedora 39.

Instructions:
github.com/FrameworkComputer/qmk_hid#running-on-linux

place this file into /etc/udev/rules.d/.

Once added, run the following:

sudo udevadm control --reload-rules
sudo udevadm trigger

If anyone else needs to apply this just to get keyboard.frame.work to connect, please post your distro.

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 :slightly_frowning_face:.

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 :thinking:. 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 :frowning:

$ 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 :smiley: .

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 :smile:.

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.

3 Likes