usbipd-win icon indicating copy to clipboard operation
usbipd-win copied to clipboard

Support -a/--auto-attach for multiple devices

Open koffes opened this issue 1 year ago • 3 comments

As a request, it would be fantastic if such a command could be supported: usbipd wsl attach -a -b 18-2 19-1 11-2 ... Many of us are working with multiple USB devices which we want to keep attached to WSL.

Related, running: usbipd wsl attach -a -i xxxx:xxxx results in usbipd: error: Multiple devices with hardware-id '1366:1051' were found; disambiguate by using '--busid'. Having this as an option would be extremely valuable to continuously attach all devices of a given hw-id.

koffes avatar Jun 06 '23 14:06 koffes

I'll put the first request on the backlog. It sounds like a good idea.

For the second part: the translation between hw-id and bus-id is made at the start of the program, whereas the actual "auto-attaching" is running as a Linux script. So, if this feature is going to be implemented, then expect -a -i xxxx:yyyy to do just that. It will figure out which (possibly multiple) devices have a current busid (i.e., are currently physically connected), and then auto-attach by busid. This means 2 things:

  1. after unplugging the device and plugging in another device (with a different hw-id), then that device will be attach (if, of course, that device was also previously shared using --bind). This means that the hw-id is only used at startup time; it is meaningless later on.
  2. if the script is already runnin and a new device (with the same hw-id) is plugged in on a different port, it will not be auto-attached by the current script.

Remember that wsl --auto-attach is just a convenience command. If you want more elaborate stuff, then I suggest you script it yourself (either Linux side, or Windows side, see: https://github.com/dorssel/usbipd-win/wiki/Automation).

In fact, all of this can be accomplished already by proper scripting around the current usbipd functionality. Therefore, I am unsure whether such an extension of "convenience" belongs in the main project itself. Maybe this should be an "additional tool" instead.

In the mean time, you can already run multiple auto-attaches simultaneously, so it is more a "convenience" request (albeit a very reasonable one!).

dorssel avatar Jun 06 '23 15:06 dorssel

Thanks for the response and a fantastic project!

I am unsure about your second point. IMO, this is the feature which would be most valuable. Running usbipd wsl attach -a -i xxxx:xxxx -i yyyy:yyyy: in an ideal scenario, this would always forward these devices to WSL regardless of the number of devices and when they are connected/disconnected.

I agree that this is not hugely important as my own script does this today. It is just cumbersome as this uses the following pseudocode:

while(1) {
    devices = usbipd list
        if (filter_on_devices_with VID:PID and NOT attached ) {
            usbipd wsl attach -b x-x
        }

    sleep()
}

koffes avatar Jun 07 '23 10:06 koffes

There is a lot more to consider here.

  1. A device needs to be bound first before it can be attached. For security reasons this requires admin rights.
  2. Some devices require (and sometimes users prefer) a force bind. Since this changes the driver it must use admin rights.
  3. Not all users use UAC for admin rights, some use a standard user and a separate account for admin. WSL has distinct instances per user, so admin != user in that case. This means that the admin doing the bind and the user doing the WSL-attach are different.

An idea that may work:

  • some new design for pre-binding (forced or not) based on hardware id, such that the service (or script) will auto-allow attachment for never-seen-before devices that match.

Like I said: I like the idea, but covering all use cases requires proper design. And I am still not sure whether:

  • this should be a separate project like https://gitlab.com/alelec/wsl-usb-gui
  • this should be a new CLI option for the existing usbipd
  • usbipd should be augmented with a management interface (MMC plugin, or something like that)

dorssel avatar Jun 07 '23 11:06 dorssel