Studio: Verify basic HID assumptions

[petejohanson]

Need to verify our assumptions about our ability to use "raw HID" over USB and BLE (HID over GATT) for the studio communication protocol:

Need to verify the HID stack works as expected on:

• Linux
  • Chrome/WebHID
  • Generally (hid-recorder and others)
• Windows
  • Edge/WebHID
  • Chrome/WebHID
• macOS
  • Chrome/WebHID
  • Generally
• iPadOS
• ChromeOS

Over both USB and BLE, and record the quirks.

[petejohanson]

Ok, so the testing I'm doing is over at https://github.com/petejohanson/zmk/tree/studio/raw-hid-exploration

To test you would:

• Build from that branch
• Run the small webapp found in webhid-app locally, e.g. pyhon3 -m http.server
• Load http://localhost:8000 in Chrome or Chrome based browser, e.g. Edge
• Click the "Connect" button.

It should present the found ZMK device and allow connecting. If you pull up the dev console you should see messages about input reports being received and writing reports when you move the slider in the UI.

On Linux, you'll need some udev rules probably:

SUBSYSTEMS=="hid", KERNELS=="0005:1D50:615E*", TAG+="uaccess"
SUBSYSTEMS=="hid", KERNELS=="0003:1D50:615E*", TAG+="uaccess"

This makes the signed in user able to use the HID devices directly for our product/vendor ID over either USB (the 3 prefix) or BLE (the 5 prefix)

[petejohanson]

Ok, so after lots of brainstorming around the negatives of using HID, mostly around security, but also how inaccessible it is on some OSes like iPadOS, going to seriously consider a serial protocol that can be used over several possible transports:

• CDC ACM serial over USB
• Custom "UART GATT Service" over BLE
• (Future) raw HID over either low level BLE/USB protocol.

[jhorology]

went up my motivation to programming, thanks to your efforts. All my ZMK keyboards are verified fine under macos. My dream is able to comminicate ZMK with Thrift or protobuf over ...

[petejohanson]

Ok, so HID works on several of these platforms, but isn't ideal. In particular, it's locked down in places like iOS, and on Linux there is no way to apply udev rules to only one of the input devices for a given USB VID/PID based on the usage page in the report descriptor, so you end up needing to allow read access to all the HID devices from the keyboard. This has the side effect of letting any userspace program open and read the HID reports and keylog.

So, HID assumptions... validated, but in an unexpected way: After discussion on Discord, I have explored abstracting the transport, and implementing the RPC workflow over either serial (including CDC ACM for USB access) and/or custom GATT service which is just a serial read/write.

This is fully working, and is designed to allow a raw HID implementation later if needed, since the low level transport can be abstracted easily.

[petejohanson]

Marking this issue closed, will continue work on the RPC protocol in https://github.com/orgs/zmkfirmware/projects/1/views/1?groupedBy%5BcolumnId%5D=72426981&pane=issue&itemId=49844254