On Mon, 11 Dec 2017, Martin Husemann wrote: [snip]
However, it can not work with the way NetBSD uses ugen devices: uftdi0 at uhub3 port 2 uftdi0: FTDI (0x9e88) SheevaPlug JTAGKey FT2232D B (0x9e8f), rev 2.00/5.00, addr 3 ucom0 at uftdi0 portno 1 ucom1 at uftdi0 portno 2 I can disable the ucom at uftdi0 portno 1, but there is no way to get a ugen device to attach there. The uftdi chip itself offers a separate interface for each of the ports, at that layer there should not be a problem. I could hack uftdi to allow attaching a ugen child, but that sounds like a very special hack. Jared suggested to instead make ugen not a separate device, but globaly fold it into the usb stack. That would also solve similar issues we have seen with usb scanner devices and ulpts.
This sounds to be related to the requirements of USB remoting such as USB-over-IP and Citrix Receiver. With the latter, I may choose to access a device using a known virtual channel such as video, in which case I would be using the kernel driver. Within my remote session, I may choose to use the USB virtual channel which would detach the kernel driver and use the native Windows driver within the session.
libusb has libusb_detach_kernel_driver() which NetBSD does not have the functionality to support. The ability to detach a kernel driver, then attach a ugen in its place would be useful (good for rump device driver development too!). However, as Taylor says, with care it may be possible to maintain both interfaces.
-- Stephen