[Bug 55332] New: 00d8:fixme:setupapi:CM_Get_Device_Interface_List_SizeW 000000000011F5B8 0000000180045FD8 (null) 0x00000000: stub
https://bugs.winehq.org/show_bug.cgi?id=55332 Bug ID: 55332 Summary: 00d8:fixme:setupapi:CM_Get_Device_Interface_List_SizeW 000000000011F5B8 0000000180045FD8 (null) 0x00000000: stub Product: Wine Version: 8.13 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: usb Assignee: wine-bugs(a)winehq.org Reporter: alois.schloegl(a)gmail.com Distribution: --- Created attachment 74926 --> https://bugs.winehq.org/attachment.cgi?id=74926 log about trying to run "wine usbip.exe attach ..." Trying to run wine usbip.exe attach -r <USBIB_SERVER> -b 1-1.2.4.2 fails with the attached error. The same command on linux usbip attach -r <USBIB_SERVER> -b 1-1.2.4.2 is working fine. In order to reproduce this, you need - an usbip server running some linux with hostname or IP-ddress <USBIP-SERVER>, with some usb-device attached, - start the usbip deamon with this command: usbipd -D - check the busid of the usb device with usbip list --local - bind the usb device, usbip bind --busid=1-1.2.4.2 This provides remote access (port 3240 by default). Next you install usbip-win2 from https://github.com/vadimgrn/usbip-win2/releases in wine, and try to connect to the usbip server with usbip list --remote=<USBIB_SERVER> This should show the exported USB devices. However, the command wine usbip.exe attach -r <USBIB_SERVER> -b 1-1.2.4.2 will fail with the attached error. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL| |https://github.com/vadimgrn | |/usbip-win2/releases Component|usb |-unknown Summary|00d8:fixme:setupapi:CM_Get_ |usbip-win2 fails to create |Device_Interface_List_SizeW |a connection |000000000011F5B8 | |0000000180045FD8 (null) | |0x00000000: stub | Keywords| |download, source --- Comment #1 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Confirming. Interestingly there is an error claiming Program Files/USBip/classfilter.exe is missing during installation. It is, indeed, missing. Did you install this or just copy the binary over from Windows? No need to set up a server: a tcpdump trace shows no packets are ever sent. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #2 from Alois Schlögl <alois.schloegl(a)gmail.com> --- I also saw this error during installation claiming Program Files/USBip/classfilter.exe. I ignored this error and did not do anything about it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 Alois Schlögl <alois.schloegl(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |usb -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #3 from Ken Sharp <imwellcushtymelike(a)gmail.com> --- Do you know what classfilter.exe does? Can it be ignored or is it an important part of the program? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 Ken Sharp <imwellcushtymelike(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|usb |-unknown -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #4 from Alois Schlögl <alois.schloegl(a)gmail.com> --- (In reply to Ken Sharp from comment #3)
Do you know what classfilter.exe does? Can it be ignored or is it an important part of the program?
I know that this classfilter is not needed/used in the linux version of usbip. Based on the README.md of usbip-win2, classfilter seem to be somehow important for this "testsigning"-nonsense on windows, for which there is no need in Wine. Querying the remote usb devices with wine usbip.exe list -r <usbip server ip> is already working. So usbip.exe is already working. Therefore, I believe that this classfilter can be ignored. This raises also the question, whether usbip could be natively integrated in Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #5 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alois Schlögl from comment #4)
This raises also the question, whether usbip could be natively integrated in Wine.
Probably better to use host software. From a simple search, I see <https://wiki.archlinux.org/title/USB/IP>. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #6 from Alois Schlögl <alois.schloegl(a)gmail.com> --- What do you mean by "better to use host software" ? Do you suggest that instead of using usbip-win2, I should use the host usbip? The later version will not work for some windows application that requires remote usb access. The standard use case, is a remote dongle server, can be already used now for running these applications in Windows. Currently, it is not possible to run these applications in Wine because usbip support is missing in Wine. Or do you suggest that usbip support in Wine should be based on the host usbip ? I'd appreciate if this would become possible. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #7 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alois Schlögl from comment #6)
What do you mean by "better to use host software" ?
Do you suggest that instead of using usbip-win2, I should use the host usbip? The later version will not work for some windows application that requires remote usb access. The standard use case, is a remote dongle server, can be already used now for running these applications in Windows. Currently, it is not possible to run these applications in Wine because usbip support is missing in Wine.
Or do you suggest that usbip support in Wine should be based on the host usbip ? I'd appreciate if this would become possible.
What do you mean that it requires remote usb access? If the program is trying to access a USB device on the local computer, and you're trying to use usbip to expose a remote USB device as a local device, then host usbip should work too. If the program doesn't work with a local USB device, or doesn't work with host usbip, that's probably because a Wine bug is preventing the program itself from working in some way. Or does the program specifically look for and expect you to use usbip-win2 somehow? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #8 from Alois Schlögl <alois.schloegl(a)gmail.com> --- No, these applications do not look specifically for usbip-win2. "requires remote usb access" means testing applications currently running on windows with access to a remote dongle through USBIP. I'm testing whether it would be possible to migrate this applications to wine. And in some cases, the only part that does not work yet is remote dongle access through USBIP. I'm pretty sure to have seen two cases (FlowJo and CED1401), where the application runs in Wine, and recognized the USB device when connected locally to the host system, but the usb device is not recognized when connected through USBIP to the host system. However, at the moment I can not reproduce this (using wine/8.13 on Debian12), because the usb devices are not recognized even when they are connected locally. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #9 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alois Schlögl from comment #8)
No, these applications do not look specifically for usbip-win2. "requires remote usb access" means testing applications currently running on windows with access to a remote dongle through USBIP. I'm testing whether it would be possible to migrate this applications to wine. And in some cases, the only part that does not work yet is remote dongle access through USBIP.
Right, so why wouldn't host usb/ip support work? If it exposes remote usb devices as if they were connected locally, Wine in theory shouldn't care. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to Zeb Figura from comment #9)
(In reply to Alois Schlögl from comment #8)
No, these applications do not look specifically for usbip-win2. "requires remote usb access" means testing applications currently running on windows with access to a remote dongle through USBIP. I'm testing whether it would be possible to migrate this applications to wine. And in some cases, the only part that does not work yet is remote dongle access through USBIP.
Right, so why wouldn't host usb/ip support work? If it exposes remote usb devices as if they were connected locally, Wine in theory shouldn't care.
Since I used such a configuration recently I can confirm that connecting to a remote USB device with Linux usb/ip tools and using that device locally in Wine does work. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #11 from Alois Schlögl <alois.schloegl(a)gmail.com> --- If the approach of using host usbip is working and is now the recommended way of doing it, I'm fine with it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55332 --- Comment #12 from Zeb Figura <z.figura12(a)gmail.com> --- (In reply to Alois Schlögl from comment #11)
If the approach of using host usbip is working and is now the recommended way of doing it, I'm fine with it.
In a sense? I don't think getting usbip-win2 working is out of scope for Wine, and I don't see any evidence it's impossible yet. On the other hand, if host usb/ip works, it's already by definition easier. It also means the USB device can be used by host programs, although I suppose that doesn't matter in this case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla