Page MenuHomeFreeBSD

hidwacom: Add Wacom ExpressKey Remote driver
Needs ReviewPublic

Authored by guest-seuros on Apr 30 2026, 1:54 AM.
Tags
Referenced Files
Unknown Object (File)
Thu, Jun 4, 1:41 PM
Unknown Object (File)
Wed, May 27, 8:55 AM
Unknown Object (File)
Tue, May 26, 7:24 AM
Unknown Object (File)
Tue, May 26, 7:17 AM
Unknown Object (File)
Tue, May 26, 2:23 AM
Unknown Object (File)
Tue, May 26, 2:14 AM
Unknown Object (File)
Sun, May 24, 11:36 PM
Unknown Object (File)
Sun, May 24, 11:28 PM
Subscribers

Details

Reviewers
adrian
ziaee
imp
Summary

The Wacom ExpressKey Remote (ACK-411050) is a wireless button pad with 18 programmable buttons and a touch ring, used as a companion device with Wacom tablets.
It communicates via a USB wireless receiver (0x056a:0x0331) using a vendor-specific HID report (ID 0x11).

This driver exposes the device via evdev:

  • 18 buttons: BTN_0–BTN_Z, BTN_BASE, BTN_BASE2
  • Touch ring position via ABS_WHEEL (0–71; reports 0 on release)
  • Pad activity marker via ABS_MISC (set to 15/PAD_DEVICE_ID when any input is active, 0 when idle that matches Linux wacom driver convention)
  • Remote serial number via MSC_SERIAL (for userland per-remote identification)

Battery level, charging state, and touch ring mode (3 LEDs, values 0–2) are exposed as per-device sysctls (dev.hidwacom.0.battery, .charging, .ring_mode) rather than overloading evdev misc codes. The ring mode sysctl is preserved across device idle periods.

Protocol was decoded from USB traffic analysis and cross-referenced against the Linux wacom_remote_irq() implementation in drivers/hid/wacom_wac.c.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 72741
Build 69624: arc lint + arc unit

Event Timeline

guest-seuros held this revision as a draft.
This comment was removed by guest-seuros.
guest-seuros edited the summary of this revision. (Show Details)
guest-seuros added a reviewer: adrian.
guest-seuros added reviewers: ziaee, imp.

please consider namespace collision if hidwacom is really the best name for this. wacom is traditionally synonymous with trackpads. maybe hidremote?

also, please consider xrefing this in hidbus(4).

share/man/man4/hidwacom.4
2

please add a blank comment line before this for consistency with C comments and in accordance with our style guides

13–28

please consider writing this according to mdoc(7), or see the mail I sent to arch@ earlier this year.

56–57
78

HARDWARE comes immediately after DESCRIPTION

79–87

The ID's don't matter here, what matters is the type of device it is.

89

please d not put macros in list width fields. is there some doc which is telling you to do this?

ziaee requested changes to this revision.May 1 2026, 8:12 PM
This revision now requires changes to proceed.May 1 2026, 8:12 PM

I think hidwacom is the better name here.

This is Wacom hardware, and it does not speak a generic "remote" protocol. It uses a Wacom-specific, undocumented HID report protocol. I decoded it from USB traffic captured against their Windows driver, and only later found that Linux already handles the same protocol in drivers/hid/wacom_wac.c under the hid-wacom driver.

If this were a published or vendor-neutral remote-control protocol, I would agree that hidremote would be a better name. But in this case, hidremote would make the driver look more generic than it really is.
The important part is not that the device is a remote, but that it is a Wacom HID device using Wacom-specific reports.

Linux also has support for multiple remotes and some additional quirks, but I cannot test those yet since I only have one ExpressKey Remote. I would rather land the tested base driver first and leave the untested multi-remote/quirk handling for future work.

Also, Wacom hardware is not limited to drawing tablets. Wacom EMR digitizers ship embedded in several laptops, including Lenovo ThinkPad X200t/X220t/X230t/Yoga models, and machines from HP, Dell, Asus, and Panasonic. Those are not drawing tablets either, but they still use Wacom-specific constants/protocol details. Samsung use it for their flagship phones and screens.

I will add the hidbus(4) xref.

guest-seuros edited the summary of this revision. (Show Details)

lint and hidbus(4) xref

share/man/man4/hidwacom.4
79–87

Please see the style guide in the tree, style.mdoc(5), for the reasoning.

I think hidwacom is the better name here.

This is Wacom hardware, and it does not speak a generic "remote" protocol. It uses a Wacom-specific, undocumented HID report protocol. I decoded it from USB traffic captured against their Windows driver, and only later found that Linux already handles the same protocol in drivers/hid/wacom_wac.c under the hid-wacom driver.

If this were a published or vendor-neutral remote-control protocol, I would agree that hidremote would be a better name. But in this case, hidremote would make the driver look more generic than it really is.
The important part is not that the device is a remote, but that it is a Wacom HID device using Wacom-specific reports.

Linux also has support for multiple remotes and some additional quirks, but I cannot test those yet since I only have one ExpressKey Remote. I would rather land the tested base driver first and leave the untested multi-remote/quirk handling for future work.

Also, Wacom hardware is not limited to drawing tablets. Wacom EMR digitizers ship embedded in several laptops, including Lenovo ThinkPad X200t/X220t/X230t/Yoga models, and machines from HP, Dell, Asus, and Panasonic. Those are not drawing tablets either, but they still use Wacom-specific constants/protocol details. Samsung use it for their flagship phones and screens.

I will add the hidbus(4) xref.

Can we compromise on something like hidexpresskey? You're completely right that Wacom produces other things, but that's also a point against claiming hidwacom -- one other proprietary protocol from them and it gets confusing. I also tend to agree that Wacom made themselves synonymous with tablets, which is another point of confusion.

I would like to understand the technical reasoning behind rejecting hidwacom before doing a rename. The rename itself is mechanical, but I want to understand what makes the name problematic so I can apply the same logic to future drivers.

The hid prefix already scopes this to HID-protocol Wacom devices. Wacom's other hardware (EMR digitizers in laptops, etc.) uses I2C/SPI, not HID so there is no actual namespace collision.

Linux's Wacom driver (under drivers/hid/) covers every Wacom HID device in one driver: pen tablets (Intuos, Bamboo), pen displays (Cintiq, DTU/DTK/DTH), the ExpressKey Remote, Bamboo Pad, and embedded laptop digitizers, across USB, Bluetooth, I2C, and PCI transports.

Wacom is significant enough that it doesn't even use the hid- prefix like other vendor drivers (hid-apple, hid-sony, hid-logitech, hid-samsung) or maybe their driver started before the norm.

If this were called hidexpresskey, I will have to create a separate driver when I steal a Wacom Intuos Pro from my friend some weekend and add pen tablet support even though it speaks the same Wacom HID vendor protocol.

When I was looking for a driver for this device, I didn't even know it was called "ExpressKey". I grepped for Cintiq, then Wacom. That is how users will look for it too. IMH