Expose /dev/input device via it's usb vendor/product id?

[RandomGHUser]

Thank you for writing this plugin - if I'm exposing a usb keyboard / mouse to my container as usb, they will not be detected (as no /dev/inputs are created, only the /dev/bus usb devices). On the host, the keyboard is generally mapped as event(x), mouse as mouse0, but the nums can obviously change. I can bind the first 30 count of my /dev/input, then they will work in my container, but I was wondering if there was a way to bind the exact /dev/input entries needed specificially based on parent usb vendor/product id without having to do a generic scope. I would like to stay away from writing custom udev rules on my host, if possible.

[squat]

There's no obvious way to do that today in this plugin. As far as USB devices are concerned, we only know how to discover nodes based on vendor/product IDs. One of the goals of this project is to not absorb domain-specific logic from every possible device.

That said, maybe we could add logic to discover symlinks for device nodes and have an option in our device config to auto-mount these symlinks for pods. This behavior could be useful for any application that relies on udev-created symlinks.

Another option could be to add vendor/product ID filtering to path-based devices that support it. This way you would configure the plugin to expose input devices but the selected devices would be limited. In practice, configuring a USB device today would just become a synonym for "find me all path devices under /dev/bus that can be filtered by this vendor/product". This might be a bit easier and faster also somewhat might close the gap between path-based devices and USB-based devices in this project.

[RandomGHUser]

Thank you for the prompt response - either option sounds very beneficial. Ultimately, if the first approach is taken, would that open up the possibility of passing through full usb hubs, traversing the children connected and attaching relevant symlinks (i.e. plugging any keyboard into a vend/prod defined usb hub could auto-attach the keyboard usb device + udev symlinks created)?

In the meantime, if I really feel the need for an exact filter match on an input device, I can write a udev rule.

[travisby]

I'm in a similar boat!

I'm looking to mount a zwave stick into a zwavejsui pod.

It's meant to be consumed as /dev/ttyUSB0, but that's not a guaranteed name if I start adding multiple serial devices to the node. So instead, I attempted to match on:

       - |
              name: zwave
              groups:
                - usb:
                  - vendor: 10c4
                    product: ea60

This created the appropriate /dev/bus/usb/ device, but not /dev/ttyUSB0 and /dev/serial/.... which seems necessary to actually talk over serial!

I also tried the /dev/serial/by-id/ name with path, and that failed (nothing found), I think because ultimately that's a symlink.

---

An enumeration or recreation of symlinks would be incredibly helpful for my usecase.

---

udev rule sounds smart, I might take that approach for now (to create /dev/zwave, and tell GDP to mount that)

---

edit, for future sleuthers:

machine:
  udev:
    rules:
      - ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="zwave"

Is my talos config to add a udev rule,

      containers:
        # latest on 2025-05-18
        - image: squat/generic-device-plugin:arm64-6475ff5d0927c0f25b3a39a661aa657ca190d0ef
          args:
            - --device
            - |
              name: zwave
              groups:
                # we have a udev rule that mounts any zwave stick to /dev/zwave
                - paths:
                  - path: /dev/zwave

is my relevant section from the GDP daemonset,

and

            requests:
              cpu: 100m
              memory: 100Mi
              squat.ai/zwave: 1
            limits:
              cpu: 256m
              memory: 100Mi
              squat.ai/zwave: 1

is part of my workload pod's containerspec

[rcambrj]

The by-id symlink seems to work for me with a zigbee stick.

        devices:
        - name: zigbee
          groups:
          - paths:
            - path: /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2650375-if00

In the end, your /dev/zwave is just another symlink. But perhaps there's something unique about the zwave device.