description: Native Linux control application for the FiFine AmpliGame D6 / Mirabox “Stream Dock” family of USB macro keypads with per-key LCD screens (USB 3142:0060). It renders per-key icons, labels and live system monitors on the device and executes user-configured actions (launch apps, hotkeys, shell commands, media control, multi-step macros) on key presses. Free and open source (GPL).
upstream-relation: I am the upstream author and the snap publisher (same person).
supported-category: hardware-specific device-control utility (driver/configurator for a USB HID macro keypad). If no listed category fits exactly, please consider the interface limitation described below.
reasoning: The keypad speaks a vendor HID protocol over /dev/hidraw (the vendor SDK uses hidapi’s hidraw backend). Under strict confinement this cannot work: raw-usb + hardware-observe - which our shipped strict revisions (up to 0.5.6, currently in the store) request and guide users to connect via an in-app helper - do not cover hidraw device nodes, so the device can never be opened and the current store listing is non-functional for every user. The dedicated hidraw interface only receives slots from gadget snaps, which do not exist on generic classic desktop systems, so an app snap in the store cannot use it either. Additionally, the app’s core purpose is executing arbitrary user-configured commands and injecting hotkeys into the user’s desktop session (it is a macro keypad controller), which strict confinement cannot express.
I understand that strict confinement is generally preferred over classic.
I’ve tried the existing interfaces to make the snap work under strict confinement (raw-usb + hardware-observe shipped in revisions 0.5.2-0.5.6; the hidraw transport remains inaccessible).
This is not a supported category, please see the list of supported categories here:
Your snap needs to fit into one of these categories, else classic confinement can not be granted.
Also note that classic confinement is reserved for mature projects only, your GitHub page says it’s status is alpha quality and you git history seems still very young
On the category: understood that a device-control utility isn’t on the supported list. Before we decide how to proceed, one technical question: is there any supported strict-confinement path to /dev/hidraw for a vendor-HID USB device on classic desktop systems? The device is driven through hidapi’s hidraw backend; raw-usb doesn’t cover hidraw nodes, and as far as I can tell the hidraw interface only gets slots from gadget snaps (i.e. Ubuntu Core), not on classic desktops. If there’s a mechanism we’ve missed, we’d much rather ship strict with the store’s blessing than classic.
On maturity: also fair - the project is young. It is released and working through a PPA and .deb today; if there is no strict path, we’re happy to let this request rest and come back when the project has more history behind it.
In the meantime: our currently-published strict revisions (up to 0.5.6) cannot reach the device at all. Rather than leave a broken install experience in the store, is closing the stable channel until this is resolved the right move, or is there a better convention?
and as far as I can tell the hidraw interface only gets slots from gadget snaps (i.e. Ubuntu Core), not on classic desktops.
You are right, AFAIK there is not good solution yet for hidraw devices in desktop. I think a plausible solution would be a new interface that only grants access to concrete devices, similar to u2f_devices, but with vendor_id and product_id defined via plug-attributes. I don’t think there is any concrete plan for that as of now, but PRs are always welcome
is closing the stable channel until this is resolved the right move, or is there a better convention?
I think so, but maybe someone from @store can confirm
