https://bugs.winehq.org/show_bug.cgi?id=52081
Bug ID: 52081 Summary: usbip: error: vhci driver is not loaded Product: Wine Version: 6.22 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: alois.schloegl@gmail.com Distribution: ---
When trying to install and use the usbip-win client https://github.com/cezanne/usbip-win/releases/download/v0.3.5/usbip-win-0.3....
trying to attach a remote usb device fails with the usbip: error: vhci driver is not loaded
This happens with the released version of usbip-win v0.3.5 as well as with a self-compiled version of usbip-win where the has_certificate function is disabled. Below are the steps to reproduce. In order to test this, are usbip server (in my case this is on "donglerasp") where "usbipd -D" is running and a usb device is exported with usbip bind --busid=1-1.2.3
$ wine usbip.exe install -w usbip: error: root driver already exist 0100:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FC20
$ wine usbip.exe list -r donglerasp Exportable USB devices ====================== - donglerasp 1-1.2.3: unknown vendor : unknown product (0529:0001) : /sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2/1-1.2.3 : unknown class / unknown subclass / unknown protocol (ff/00/00) : 0 - unknown class / unknown subclass / unknown protocol (ff/00/00)
0100:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FC20
$ wine usbip.exe attach -r donglerasp -b "1-1.2.3" usbip: error: vhci driver is not loaded 0118:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FC20
https://bugs.winehq.org/show_bug.cgi?id=52081
Alois Schlögl alois.schloegl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian
https://bugs.winehq.org/show_bug.cgi?id=52081
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- This can probably be made to work, but is there a reason not to use the host vhci driver?
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #2 from Alois Schlögl alois.schloegl@gmail.com --- (In reply to Zebediah Figura from comment #1)
This can probably be made to work, but is there a reason not to use the host vhci driver?
I tested this with one, using usbip on the host system, and at least one software package (Kaluza, it installs locally a sentinel license manager), falls to install doing that.
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #3 from Alois Schlögl alois.schloegl@gmail.com --- s/falls/fails/
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alois Schlögl from comment #2)
I tested this with one, using usbip on the host system, and at least one software package (Kaluza, it installs locally a sentinel license manager), falls to install doing that.
That might just be a bug with the software in question. I'm assuming it just wants to see a USB device in Wine?
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #5 from Alois Schlögl alois.schloegl@gmail.com --- (In reply to Zebediah Figura from comment #4)
(In reply to Alois Schlögl from comment #2)
I tested this with one, using usbip on the host system, and at least one software package (Kaluza, it installs locally a sentinel license manager), falls to install doing that.
That might just be a bug with the software in question. I'm assuming it just wants to see a USB device in Wine?
That is possible but unlike, because the same software/installer runs on windows w/o a usb dongle connected - it results in installing the evaluation function, and later, when the dongle is attached, one can change to the dongle license.
And I tried loading vhci on the host (I tested with "modprobe vhci_hcd"), that does not help running these applications within wine either.
For clarification, it would be perfectly fine for me if usbip would be integrated in wine without the need for usbip-win. It just needs to provide a solution, that allows to run the usbip client commands which are:
attach Attach a remote USB device detach Detach a remote USB device list List exportable or local USB devices port Show imported USB devices
One can do these also on the host, in that case the functions of the driver provided by that device need to be made accessible to software running within wine.
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- (In reply to Alois Schlögl from comment #5)
(In reply to Zebediah Figura from comment #4)
(In reply to Alois Schlögl from comment #2)
I tested this with one, using usbip on the host system, and at least one software package (Kaluza, it installs locally a sentinel license manager), falls to install doing that.
That might just be a bug with the software in question. I'm assuming it just wants to see a USB device in Wine?
That is possible but unlike, because the same software/installer runs on windows w/o a usb dongle connected - it results in installing the evaluation function, and later, when the dongle is attached, one can change to the dongle license.
I'm not sure I understand. If it runs on Windows, but fails on Wine, why wouldn't that imply a bug in Wine?
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #7 from Alois Schlögl alois.schloegl@gmail.com ---
Thats a missunderstanding - I thought with "a bug with the software in question", you are refering to the application software running under wine - not wine itself.
I agree that wine "has a bug" (I prefer to say, wine is missing some features) that prevents this application from running under wine. The error message from usbip suggests that this might be related to the missing support for vhci. Maybe that is the same reason why the other application does not running either.
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #8 from Zebediah Figura z.figura12@gmail.com --- Ah yes, my phrasing was misleading; I apologize.
I think it'll probably be more useful to debug the Kaluza software; if it's not seeing USB devices I'm not sure that Win32 vhci is going to help with that.
It might be an interesting exercise to make Win32 vhci work anyway, but I don't think it's going to provide any features that host vchi doesn't. (It won't be usable from non-Wine processes, for instance.)
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #9 from Alois Schlögl alois.schloegl@gmail.com ---
(In reply to Zebediah Figura from comment #8)
Ah yes, my phrasing was misleading; I apologize.
I think it'll probably be more useful to debug the Kaluza software; if it's not seeing USB devices I'm not sure that Win32 vhci is going to help with that.
It might be an interesting exercise to make Win32 vhci work anyway, but I don't think it's going to provide any features that host vchi doesn't. (It won't be usable from non-Wine processes, for instance.)
I think would provide additions features - for the following reason:
I've been able to connect these USB devices on some linux host serving as USBIP server, forward those through USBIP to some windows machine, and I've been able to run the corresponding software on Windows (I'm thinking about CED1401, which is data aquisiton system with up to serveral 100kSamples/seconds., as well as the Kaluza/Sentinel dongle license) As far as I know, no vhci was running on the usbip server. The same software does not work when I connect the same USB device to the host system one which Wine is running (and it will not work through usbip, because usbip-client will no run under Wine). I guess that is because there are no linux drivers for these devices, and so it seems to me that the host-based vhci can not handle these cases. (in Kaluza and usbip I had host-vhci loaded, I can not say whether this was the case when testing ced1401).
Or let me ask you this. What would happen if you have some usb device with some windows only drivers. There are no linux drivers available for the above examples (CED1401, and Kaluza/Sentinel). Would vhci on the host being able to handle these and provide the these driver functions to Wine and applications running in Wine ? I doubt that, for the reason described above.
I guess Wine does a good job with usb devices where the drivers are somehow standardised and are supported on all OS's, like USB memory sticks, USB cameras, HID devices like keyboard and mouse, and perhaps some dongles. Some might not use vhci, for some host-based vhci might work well. But for devices that have no Linux support, and only Drivers for Windows, Wine does not seem to support these USB devices. Would you agree to that ?
When looking at this list https://bugs.winehq.org/buglist.cgi?quicksearch=usb&list_id=748976 I guess a number of these devices fall into that category. The hypothesis is that when vhci would be supported within Wine, it would improve support for these devices as well.
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- It doesn't really work like that. Wine does in fact have support for directly exposing USB devices, so even if there are no host drivers, Windows programs which want to access the device directly will still work (although you'll probably have to set up permissions on the host side so that Wine can actually open them).
Note also that Wine exposes these devices on the "kernel" level, so that Windows kernel drivers which layer on top of USB devices will still work.
If a bit of software is able to detect a USB device on Windows when using usbip, but doesn't work on Wine when using a host vhci driver, that's probably just because something else in Wine is broken that's preventing the USB device from being enumerated. I'm pretty sure it would fail similarly even if the usbip vchi driver was working.
https://bugs.winehq.org/show_bug.cgi?id=52081
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, hardware, source URL| |https://github.com/cezanne/ | |usbip-win/releases/download | |/v0.3.5/usbip-win-0.3.5.zip
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #11 from Alois Schlögl alois.schloegl@gmail.com --- Created attachment 73413 --> https://bugs.winehq.org/attachment.cgi?id=73413 patch to provide more details in debug log
Part of the problem of usbip-win being not supported, is the fact that BUS_QUERY_ID_TYPE type==0x05 (i.e. BusQueryContainerID) is not supported.
The attached patch provides more details in the debug log.
The next step would probably be to implement get_container_id(...) in dlls/winebus.sys/main.c and dlls/wineusb.sys/wineusb.c
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- (In reply to Alois Schlögl from comment #11)
Part of the problem of usbip-win being not supported, is the fact that BUS_QUERY_ID_TYPE type==0x05 (i.e. BusQueryContainerID) is not supported.
The attached patch provides more details in the debug log.
The next step would probably be to implement get_container_id(...) in dlls/winebus.sys/main.c and dlls/wineusb.sys/wineusb.c
Maybe, but probably not. Not every FIXME actually matters, and sometimes none of them do. Given some knowledge about the relevant code I would not expect this one to matter.
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #13 from Zeb Figura z.figura12@gmail.com --- *** Bug 53883 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=52081
--- Comment #14 from Alois Schlögl alois.schloegl@gmail.com --- (In reply to Zeb Figura from comment #12)
(In reply to Alois Schlögl from comment #11)
Part of the problem of usbip-win being not supported, is the fact that BUS_QUERY_ID_TYPE type==0x05 (i.e. BusQueryContainerID) is not supported.
The attached patch provides more details in the debug log.
The next step would probably be to implement get_container_id(...) in dlls/winebus.sys/main.c and dlls/wineusb.sys/wineusb.c
Maybe, but probably not. Not every FIXME actually matters, and sometimes none of them do. Given some knowledge about the relevant code I would not expect this one to matter.
I need to take your word for it, although I'm not convinced. It seems that to get USB support in wine going, several components might be needed (e.g. plugplay/pnp, etc). It might also make difference whether a particular driver for some device is available on the host system or not.
For example CED1401 has only a working driver for Windows, but not for Linux. So in order to make this work, the most promising path seems to make the windows driver of CED1401 work under Wine. Although, I'm aware that drivers are part of the OS domain, and since Wine works in user space, this approach might come with its own challenges.
OTOH, USBIP is available one Windows and Linux, so in that case it might be an option to link against libusbip from the host system. So this case might need a very different approach.
Long story short, I believe that more debugging information would be useful in going forward with USB support in Wine. (see also comment 8 in https://bugs.winehq.org/show_bug.cgi?id=49394)
https://bugs.winehq.org/show_bug.cgi?id=52081
Alois Schlögl alois.schloegl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|6.22 |8.0-rc1
https://bugs.winehq.org/show_bug.cgi?id=52081
Alois Schlögl alois.schloegl@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |usb
https://bugs.winehq.org/show_bug.cgi?id=52081
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|8.0-rc1 |6.22
-
WineHQ Bugzilla