USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? Steve Kenton
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2015-04-11 um 17:38 schrieb Steve Kenton:
USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? I'm not an expert on this, but as far as I understand it the first problem that needs to be solved is properly registering USB devices in the device tree in the registry. This doesn't even involve Windows USB drivers and is as "simple" as advertising a USB mass storage device that's handled by Linux / OSX as a USB mass storage device instead of a fixed hard drive, with the proper vendor and device ID etc.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVKaVaAAoJEN0/YqbEcdMw4OQP/0f3XQqDUOgvXBa7ueHQzZ2P Wfabc+F3L9gxO/PCikBkzgDH8P7x51mefPJbXHuXN+bbQJ+n4yqk31vn5h5gPULE v+SIPTV8oxCOm6AZtd1p2A0PxDQrcnZlZ+f8HyglAtXgTC5KGqf7tcHNqIz8c1sG ZcT9UfJGdEOM1dMluk8XNKJVqPt4g7u5BDOEOO7yhL11w4BF2NNVF7ZyzwyIfgxV C9KO+3+iCX2fzdwM0squl4xlZbbrrIjOnIj9KdWQ1odOZVUBapLAYNkjf0h70O0J 31kEnnVtjwxrWuwSQQQ3FQf6KI3qLCBeThU/86d2X6H8OBbHoLg6CeQ+ZjFjc5f0 acYcxPZkVXRiXw/fRX30lYY5tMYiIhkfr6w3wtx7mNs1v1Yxa/giD0BonhyoSVqr iAJrtOc6Lyr7zahQr/aYHsufdimSEpnagnwBax+/lewRMZg21a6Ch/X5z/LK6F+4 sk2YVR94cTn93n/TrgP6acibkVsHps41NMrEcDXYy5vSeq6ynJh8rUSB6VGYW1od Qtu8m82yVF3GwFPeN1/G5zRar6wAt8/2RRpF3KWNk5h8jgdI6hqZapshOPMy2gbv 23Edj8Y3oOL36+A8wz65iinKEvQ8Dk6dWVQ0C9o2E65UlggMnup9uijfFMp6jAb0 mHz4YK40BAxBhdcnAdOk =Efxl -----END PGP SIGNATURE-----
* On Sun, 12 Apr 2015, Stefan Dösinger wrote:
Am 2015-04-11 um 17:38 schrieb Steve Kenton:
USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable?
I'm not an expert on this, but as far as I understand it the first problem that needs to be solved is properly registering USB devices in the device tree in the registry. This doesn't even involve Windows USB drivers and is as "simple" as advertising a USB mass storage device that's handled by Linux / OSX as a USB mass storage device instead of a fixed hard drive, with the proper vendor and device ID etc.
Stefan, do you mean populating entries in registry subkeys "Control\DeviceClasses" [1] and "Enum" [2] or namely "Enum\USB" [3] in the HKLM\SYSTEM\CurrentControlSet\ key ? I guess namely what values are crucial here except for essentially looking "HardwareID" [4] -- can it be all of them? Judging by the WineHQ Wiki [5] I am not so sure. S. [1] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546165%28v=vs.85... [2] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546173%28v=vs.85... [3] https://msdn.microsoft.com/en-us/library/windows/hardware/jj649944%28v=vs.85... [4] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546152%28v=vs.85... [5] http://wiki.winehq.org/USB?highlight=%28CurrentControlSet%29
On 4/12/2015 11:42 AM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Stefan Dösinger wrote:
Am 2015-04-11 um 17:38 schrieb Steve Kenton:
USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? In particular I'm wondering about how much support for client/function drivers would be desirable. Should we stick to only unprivileged operations or would an optional kernel mode driver to support WDM or WDF (KMDF/UMDF) privileged interfaces be acceptable? I'm not an expert on this, but as far as I understand it the first problem that needs to be solved is properly registering USB devices in the device tree in the registry. This doesn't even involve Windows USB drivers and is as "simple" as advertising a USB mass storage device that's handled by Linux / OSX as a USB mass storage device instead of a fixed hard drive, with the proper vendor and device ID etc. Stefan, do you mean populating entries in registry subkeys "Control\DeviceClasses" [1] and "Enum" [2] or namely "Enum\USB" [3] in the HKLM\SYSTEM\CurrentControlSet\ key ?
I guess namely what values are crucial here except for essentially looking "HardwareID" [4] -- can it be all of them? Judging by the WineHQ Wiki [5] I am not so sure.
S.
[1] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546165%28v=vs.85... [2] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546173%28v=vs.85... [3] https://msdn.microsoft.com/en-us/library/windows/hardware/jj649944%28v=vs.85... [4] https://msdn.microsoft.com/en-us/library/windows/hardware/ff546152%28v=vs.85... [5] http://wiki.winehq.org/USB?highlight=%28CurrentControlSet%29 I spent some more time looking at this last night and it looks like the registry enum keys are about every device ever plugged into the system, whether it's currently present or not and the actual Windows device tree is maintained in memory, so just the registry keys probably won't suffice.
Steve Kenton
* On Sun, 12 Apr 2015, Steve Kenton wrote:
On 4/12/2015 11:42 AM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Stefan Dösinger wrote:
Am 2015-04-11 um 17:38 schrieb Steve Kenton:
USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? ... the first problem that needs to be solved is properly registering USB devices in the device tree in the registry. This doesn't even involve Windows USB drivers and is as "simple" as advertising a USB mass storage device that's handled by Linux / OSX as a USB mass storage device instead of a fixed hard drive, with the proper vendor and device ID etc. Stefan, do you mean populating entries in registry subkeys "Control\DeviceClasses" [1] and "Enum" [2] or namely "Enum\USB" [3] in the HKLM\SYSTEM\CurrentControlSet\ key ?
I guess namely what values are crucial here except for essentially looking "HardwareID" [4] -- can it be all of them? Judging by the WineHQ Wiki [5] I am not so sure. I spent some more time looking at this last night and it looks like the registry enum keys are about every device ever plugged into the system, whether it's currently present or not and the actual Windows device tree is maintained in memory, so just the registry keys probably won't suffice.
Steve, it won't of course. But this is the first required step. I would say that another way: let's make the HwDetect [6] (custom program) work in Wine the same way it works in Windows (except for disabling devices -- just the monitoring part). It reads very small amount of data from "Enum\USB" subkey (I guess). Another step might be fixing Wine so "USB Device Tree Viewer" [7] works as in Windows. But this one looks like a lot more complicated testcase. S. [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-o... [7] http://www.uwe-sieber.de/usbtreeview_e.html
On 04/14/2015 06:04 PM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Steve Kenton wrote:
On 4/12/2015 11:42 AM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Stefan Dösinger wrote:
Am 2015-04-11 um 17:38 schrieb Steve Kenton:
USB Support has been on the list of possible release criteria basically forever. I've read through all the old threads and other discussions I could find and it boils down to "really hard to do right". If possible could someone knowledgeable comment briefly on what might be an acceptable architecture for a Wine USB stack? ... the first problem that needs to be solved is properly registering USB devices in the device tree in the registry. This doesn't even involve Windows USB drivers and is as "simple" as advertising a USB mass storage device that's handled by Linux / OSX as a USB mass storage device instead of a fixed hard drive, with the proper vendor and device ID etc. Stefan, do you mean populating entries in registry subkeys "Control\DeviceClasses" [1] and "Enum" [2] or namely "Enum\USB" [3] in the HKLM\SYSTEM\CurrentControlSet\ key ?
I guess namely what values are crucial here except for essentially looking "HardwareID" [4] -- can it be all of them? Judging by the WineHQ Wiki [5] I am not so sure. I spent some more time looking at this last night and it looks like the registry enum keys are about every device ever plugged into the system, whether it's currently present or not and the actual Windows device tree is maintained in memory, so just the registry keys probably won't suffice.
Steve, it won't of course. But this is the first required step. I would say that another way:
let's make the HwDetect [6] (custom program) work in Wine the same way it works in Windows (except for disabling devices -- just the monitoring part). It reads very small amount of data from "Enum\USB" subkey (I guess).
Another step might be fixing Wine so "USB Device Tree Viewer" [7] works as in Windows. But this one looks like a lot more complicated testcase.
S.
[6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-o... [7] http://www.uwe-sieber.de/usbtreeview_e.html
I was thinking along those same lines with something like the display portion of Windows Device Manager. ~wine/server/device.c has some routines for managing devices, I need to spend some more time understanding the current state of things. But yes, it does look like a good place to start.
* On Tue, 14 Apr 2015, Steve Kenton wrote:
On 04/14/2015 06:04 PM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Steve Kenton wrote:
I spent some more time looking at this last night and it looks like the registry enum keys are about every device ever plugged into the system, whether it's currently present or not and the actual Windows device tree is maintained in memory, so just the registry keys probably won't suffice.
Steve, it won't of course. But this is the first required step. I would say that another way:
let's make the HwDetect [6] (custom program) work in Wine the same way it works in Windows (except for disabling devices -- just the monitoring part). It reads very small amount of data from "Enum\USB" subkey (I guess).
Another step might be fixing Wine so "USB Device Tree Viewer" [7] works as in Windows. But this one looks like a lot more complicated testcase. ... [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-o... [7] http://www.uwe-sieber.de/usbtreeview_e.html
I was thinking along those same lines with something like the display portion of Windows Device Manager. ~wine/server/device.c has some routines for managing devices, I need to spend some more time understanding the current state of things. But yes, it does look like a good place to start.
In bug report 37724 Henrik Haftmann talks [8] about similar issue and offers code excerpt which uses related functions: SetupDiGetClassDevs() SetupDiEnumDeviceInfo() SetupDiOpenDevRegKey() SetupDiDestroyDeviceInfoList() SetupDiEnumDeviceInterfaces() SetupDiGetDeviceInterfaceDetail() You might be interested in collaboration:) S. [8] https://bugs.winehq.org/show_bug.cgi?id=37724
On 04/25/2015 05:22 AM, Saulius Krasuckas wrote:
* On Tue, 14 Apr 2015, Steve Kenton wrote:
On 04/14/2015 06:04 PM, Saulius Krasuckas wrote:
* On Sun, 12 Apr 2015, Steve Kenton wrote:
I spent some more time looking at this last night and it looks like the registry enum keys are about every device ever plugged into the system, whether it's currently present or not and the actual Windows device tree is maintained in memory, so just the registry keys probably won't suffice.
Steve, it won't of course. But this is the first required step. I would say that another way:
let's make the HwDetect [6] (custom program) work in Wine the same way it works in Windows (except for disabling devices -- just the monitoring part). It reads very small amount of data from "Enum\USB" subkey (I guess).
Another step might be fixing Wine so "USB Device Tree Viewer" [7] works as in Windows. But this one looks like a lot more complicated testcase. ... [6] http://www.codeproject.com/Articles/14500/Detecting-Hardware-Insertion-and-o... [7] http://www.uwe-sieber.de/usbtreeview_e.html
I was thinking along those same lines with something like the display portion of Windows Device Manager. ~wine/server/device.c has some routines for managing devices, I need to spend some more time understanding the current state of things. But yes, it does look like a good place to start.
In bug report 37724 Henrik Haftmann talks [8] about similar issue and offers code excerpt which uses related functions:
SetupDiGetClassDevs() SetupDiEnumDeviceInfo() SetupDiOpenDevRegKey() SetupDiDestroyDeviceInfoList() SetupDiEnumDeviceInterfaces() SetupDiGetDeviceInterfaceDetail()
You might be interested in collaboration:)
S.
Actually, I think I'll come at it starting with a modified regedit so I can get familiar with the Windows API and GUI while displaying device information. And hopefully get a handle on the registry while I'm at it. I got into this because I'm writing firmware for a custom USB device to use in an embedded Linux system and the vendor tools are only available for Windows. Sigh. And of course Wine handles everything fine *except* the USB snooping. I've spent my entire professional life working the in Unix workstation & HPC world staring with PDP-11 and later VAX "boot me" tapes from Bell Labs / Western Electric. I think the last time I had to write a Windows GUI app was when the original Windows 95 was released :-( So I'm woefully out of date on Windows. Uwe Bonnes made this comment in another email: "Newer usb devices often use winusb for usb communication. A translation dll winusb->libusb is thinkable. However the problem of device detection remains." Crawling through /sys and /proc or writing a device driver shim I think I can handle, Displaying the information or adding it to the registry is is murky (to me) which is why I'm looking at such a bass-ackwards approach. Steve
"Steve" == Steve Kenton <skenton(a)ou.edu> writes:
Steve> I got into this because I'm writing firmware for a custom USB Steve> device to use in an embedded Linux system and the vendor tools Steve> are only available for Windows. Sigh. And of course Wine handles Steve> everything fine *except* the USB snooping. I've spent my entire Steve> professional life working the in Unix workstation & HPC world Steve> staring with PDP-11 and later VAX "boot me" tapes from Bell Labs Steve> / Western Electric. I think the last time I had to write a Steve> Windows GUI app was when the original Windows 95 was released :-( Steve> So I'm woefully out of date on Windows. Steve> Uwe Bonnes made this comment in another email: Steve> "Newer usb devices often use winusb for usb communication. A Steve> translation dll winusb->libusb is thinkable. However the problem Steve> of device detection remains." Steve> Crawling through /sys and /proc or writing a device driver shim I Steve> think I can handle, Displaying the information or adding it to Steve> the registry is is murky (to me) which is why I'm looking at such Steve> a bass-ackwards approach. Probably the USB device handling is devided into a DLL for USB access and the programm itself using the DLL. Perhaps the DLL API is public or you may get it with some kind of NDA from the vendor. In that case writing a replacement DLL is also an option. This is not generic at all, but may solve your problem. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
I got into this because I'm writing firmware for a custom USB device to use in an embedded Linux system and the vendor tools are only available for Windows. Sigh. And of course Wine handles everything fine *except* the USB snooping. I've spent my entire professional life working the in Unix workstation & HPC world staring with PDP-11 and later VAX "boot me" tapes from Bell Labs / Western Electric. I think the last time I had to write a Windows GUI app was when the original Windows 95 was released :-( So I'm woefully out of date on Windows.
I probably shouldn't tell you this because I *really* want USB support in Wine, but you can currently do this currently using a VM. Run your application in a Windows in VirtualBox, then you can use Linux's usbmon to sniff the traffic. To do the capture I usually start off with wireshark, and then use this command line tool that I maintain: https://github.com/jhol/usbdump With a command line packet trace, you can then do greps, diffs, vidiff etc. to reverse engineer the protocol. Kind Regards Joel
On 4/29/2015 4:27 AM, Joel Holdsworth wrote:
I got into this because I'm writing firmware for a custom USB device to use in an embedded Linux system and the vendor tools are only available for Windows. Sigh. And of course Wine handles everything fine *except* the USB snooping. I've spent my entire professional life working the in Unix workstation & HPC world staring with PDP-11 and later VAX "boot me" tapes from Bell Labs / Western Electric. I think the last time I had to write a Windows GUI app was when the original Windows 95 was released :-( So I'm woefully out of date on Windows.
I probably shouldn't tell you this because I *really* want USB support in Wine, but you can currently do this currently using a VM. Run your application in a Windows in VirtualBox, then you can use Linux's usbmon to sniff the traffic.
To do the capture I usually start off with wireshark, and then use this command line tool that I maintain:
https://github.com/jhol/usbdump
With a command line packet trace, you can then do greps, diffs, vidiff etc. to reverse engineer the protocol.
Kind Regards Joel
Thanks for the tip. I picked up a used usb protocol analyzer for a good price to diagnose the immediate problem (lots of NAKs at an unexpected time) but I'd still like to pursue getting USB support into wine and not have to depend on a Windows box (or VM) for any part of the project. Steve
Thanks for the tip. I picked up a used usb protocol analyzer for a good price to diagnose the immediate problem (lots of NAKs at an unexpected time) but I'd still like to pursue getting USB support into wine and not have to depend on a Windows box (or VM) for any part of the project.
Fair enough. Well I happen to know Peter Stuge who is the guy behind libusb (http://www.libusb.org/). He tends to hang out at #sigrok under the username "CareBear\" . I would recommend having a chat with him. Joel
participants (5)
-
Joel Holdsworth -
Saulius Krasuckas -
Stefan Dösinger -
Steve Kenton -
Uwe Bonnes