USB device support in wine
Hi, I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it. I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device. Any ideas, or anyone else who would be interested in helping me? Regards, Jono
On 5/3/07, Jon Burgess <jkburges(a)gmail.com> wrote:
Hi,
I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it.
I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
One thing is that you need to make sure that the hardware is detected and usable by Linux prior to trying to implement support for it in wine. If linux can't see it, then wine won't be able to, just like if you dont have the drivers installed in windows, then you wont be able to use it within the application on windows. -- Thanks Tom Check out this new 3D Instant Messenger called IMVU. It's the best I have seen yet! http://imvu.com/catalog/web_invitation.php?userId=1547373&from=power-email
I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it.
I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
One thing is that you need to make sure that the hardware is detected and usable by Linux prior to trying to implement support for it in wine. If linux can't see it, then wine won't be able to, just like if you dont have the drivers installed in windows, then you wont be able to use it within the application on windows.
Ok, thanks Tom. I will investigate that - "/var/log/syslog" and "/proc/bus/usb/devices" should give me some idea if the USB device is detected, right? I'll check when I get home, at work atm. Cheers, Jono
On 5/4/07, Jon Burgess <jkburges(a)gmail.com> wrote:
Hi,
I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it.
I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
Any ideas, or anyone else who would be interested in helping me?
Does the software come with a .SYS file? That website doesn't much, please post lsusb -v output.
Regards, Jono
Damjan
I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it.
I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
Any ideas, or anyone else who would be interested in helping me?
Does the software come with a .SYS file?
yes: the is a directory .../Serato/Drivers/ containing "MP4Usb.sys" and " MP4Usb.inf", although I seem to remember reading somewhere that the MP4 driver is for another Serato product (not Scratch live). That website doesn't much, please post lsusb -v output. Bus 005 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 1 Single TT bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic ehci_hcd iProduct 2 EHCI Host Controller iSerial 1 0000:00:1d.7 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Hub Descriptor: bLength 11 bDescriptorType 41 nNbrPorts 8 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection TT think time 8 FS bits bPwrOn2PwrGood 10 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 0x00 PortPwrCtrlMask 0xff 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Port 3: 0000.0100 power Port 4: 0000.0100 power Port 5: 0000.0100 power Port 6: 0000.0100 power Port 7: 0000.0100 power Port 8: 0000.0000 Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 001 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 002 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 004 Device 002: ID 13e5:0001 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize0 32 idVendor 0x13e5 idProduct 0x0001 bcdDevice 1.00 iManufacturer 1 Serato iProduct 2 Serato Scratch LIVE(c)2004 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 497 bNumInterfaces 9 bConfigurationValue 1 iConfiguration 13 USB Powered bmAttributes 0x80 (Bus Powered) MaxPower 300mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 15 Line 1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 7 LineOut1Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 9 LineOut1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 3 LineIn1Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 5 LineIn1 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 16 Line 2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 8 LineOut2Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 10 LineOut2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 4 LineIn2Idle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 6 LineIn2 Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x00b8 1x 184 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 6 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 17 Mic Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 11 MicIdle Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 7 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 12 Mic Class specific interface descriptor for class 255 is unsupported Class specific interface descriptor for class 255 is unsupported Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0090 1x 144 bytes bInterval 1 bRefresh 0 bSynchAddress 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 8 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 4 Device Status: 0x0000 (Bus Powered) Bus 004 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0103 power enable connect Device Status: 0x0003 Self Powered Remote Wakeup Enabled Bus 003 Device 001: ID 0000:0000 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed hub bMaxPacketSize0 64 idVendor 0x0000 idProduct 0x0000 bcdDevice 2.06 iManufacturer 3 Linux 2.6.20-15-generic uhci_hcd iProduct 2 UHCI Host Controller iSerial 1 0000:00:1d.2 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection bPwrOn2PwrGood 1 * 2 milli seconds bHubContrCurrent 0 milli Ampere DeviceRemovable 0x00 PortPwrCtrlMask 0xff Hub Port Status: Port 1: 0000.0100 power Port 2: 0000.0100 power Device Status: 0x0003 Self Powered Remote Wakeup Enabled And here is the relevant excerpt from my /proc/bus/usb/devices file (not sure if this gives anything extra than lsusb -v above though). T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=32 #Cfgs= 1 P: Vendor=13e5 ProdID=0001 Rev= 1.00 S: Manufacturer=Serato S: Product=Serato Scratch LIVE(c)2004 C:* #Ifs= 9 Cfg#= 1 Atr=80 MxPwr=300mA I: If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=01(O) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 2 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 2 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=82(I) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 3 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 4 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 4 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=04(O) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 5 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 5 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=84(I) Atr=09(Isoc) MxPS= 184 Ivl=1ms I: If#= 6 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=01 Prot=00 Driver=(none) I: If#= 7 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) I: If#= 7 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=(none) E: Ad=85(I) Atr=09(Isoc) MxPS= 144 Ivl=1ms I: If#= 8 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=4ms E: Ad=03(O) Atr=03(Int.) MxPS= 64 Ivl=4ms In the mean time, looks like I have some reading to do regarding USB spec, dbus and hal :-) Thanks for the help so far. Regards, Jono
On 5/4/07, Jon Burgess <jkburges(a)gmail.com> wrote:
I have found some talk of implementing USB device support in wine in this list some time ago (2005), but as far as I know, nothing ever came of it.
I would perhaps be interested in getting this going again, as I have an application (Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
Any ideas, or anyone else who would be interested in helping me?
Does the software come with a .SYS file?
yes: the is a directory .../Serato/Drivers/ containing "MP4Usb.sys" and "MP4Usb.inf", although I seem to remember reading somewhere that the MP4 driver is for another Serato product (not Scratch live).
It probably doesn't refer to the MP4 music format.
That website doesn't much, please post lsusb -v output.
Bus 004 Device 002: ID 13e5:0001 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol
This there is no "standard" driver for your USB device (like for example there is just 1 driver for all USB flash disks, because they're all in the same device class). You have the use the vendor-supplied .SYS file. Will it work on wine right now? Not even remotely. Will it ever? Read on... There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows (there is apparently some user-space USB stuff in mingw's headers, but I couldn't find any official docs on it, and it's not enough to write a user-space driver because there is no bulk/interrupt/isochronous pipe support, so I doubt anybody actually uses it). There is only kernel-mode interfaces for talking to USB - and different kernel mode drivers will export different user-mode interfaces (if any). So user-space software uses a kernel-mode driver. If that driver is documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be done in wine, and wine can be connected to USB in a number of ways (which I'll discuss later). If that driver is undocumented, either you have to document it by reverse-engineering (very hard) and continue with the first way, or (the second way:) make wine's not-yet-existing NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the USB interfaces that Windows has. CONNECTING WINE TO USB: A HOW-TO GUIDE There is 4 ways to do it: 1. Make a kernel module in your OS (eg. a Linux kernel module) that exports the same interface that the software expects and works the same way as the Windows driver. Using USBSCAN.SYS as an example, reading does a USB bulk read, writing does a USB bulk write, and 13 or so i/o control codes do various other things, among them USB control and interrupt tranfers. Change kernel32's CreateFileW() to open the /dev device node used by the kernel module and send it to the wine server using wine_server_fd_to_handle(), then reading and writing will go to your kernel module, where you can implement them by doing USB reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to capture i/o control codes used by your device, call wine_server_handle_to_fd(), and do an ioctl() on that fd to send that i/o control call to the kernel module, which then reacts appropriately. This way has been tested by me, it works and it's fast, but it's non-portable (eg. Linux-only, and Linux's USB interface keep changing so an out-of-tree module will only work on some versions, the usual problems...), difficult (kernel-mode code is hard to write), and generally a royal PITA. 2. Like (1) but use a framework like FUSD (the xiph.org version works on 2.6 kernels) to write the driver in user-space and then do USB I/O using libusb. I'm currently testing this approach, I suspect it's slow (how significantly remains to be seen), but at least it's more portable between Linux versions and easier to write and maintain. 3. Integrate your device into wine directly the way eg. serial ports have been done. This is hard, and requires introducing a new FD_TYPE, changing ntdll's file.c's NtReadFile, NtWriteFile, and NtDeviceIoControlFile (and asynchronous versions of those) to use special behavior for that FD_TYPE, and managing global device state (eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot of time, and some changes to both wine and libusb, you could get it to work properly. This should IMO only be done for generally useful drivers, not drivers for just 1 type of device. 4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably through libusb), and modify ntdll to forward the appropriate reads, writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file can handle them. This is the only way that works with .SYS files out-of-the-box, the others all require a rewrite of the .SYS driver's functionality. Architecturally, this is the best way, you wouldn't need to change any code in wine to add a new driver. Way 4 is probably the best and I hope it works at some stage, but it's still a long way off seeing as how NTOSKRNL.EXE itself still isn't in wine.
In the mean time, looks like I have some reading to do regarding USB spec, dbus and hal :-)
There is only 1 or 2 chapters you need from the USB spec. DBus is just an RPC framework, and HAL just lists devices and their properties, so they won't help much.
Thanks for the help so far.
Regards, Jono
Damjan
There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows
But there is, just that most vendors don't use it.
(there is apparently some user-space USB stuff in mingw's headers, but I couldn't find any official docs on it, and it's not enough to write a user-space driver because there is no bulk/interrupt/isochronous pipe support, so I doubt anybody actually uses it). There is only kernel-mode interfaces for talking to USB - and different kernel mode drivers will export different user-mode interfaces (if any).
So user-space software uses a kernel-mode driver. If that driver is documented, like USBSCAN.SYS and USBPRINT.SYS, its interface can be done in wine, and wine can be connected to USB in a number of ways (which I'll discuss later). If that driver is undocumented, either you have to document it by reverse-engineering (very hard) and continue with the first way, or (the second way:) make wine's not-yet-existing NTOSKRNL.EXE load that driver, *and* provide NTOSKRNL.EXE with all the USB interfaces that Windows has.
CONNECTING WINE TO USB: A HOW-TO GUIDE
There is 4 ways to do it:
1. Make a kernel module in your OS (eg. a Linux kernel module) that exports the same interface that the software expects and works the same way as the Windows driver. Using USBSCAN.SYS as an example, reading does a USB bulk read, writing does a USB bulk write, and 13 or so i/o control codes do various other things, among them USB control and interrupt tranfers. Change kernel32's CreateFileW() to open the /dev device node used by the kernel module and send it to the wine server using wine_server_fd_to_handle(), then reading and writing will go to your kernel module, where you can implement them by doing USB reads and writes. Change ntdll's file.c's NtDeviceIoControlFile to capture i/o control codes used by your device, call wine_server_handle_to_fd(), and do an ioctl() on that fd to send that i/o control call to the kernel module, which then reacts appropriately. This way has been tested by me, it works and it's fast, but it's non-portable (eg. Linux-only, and Linux's USB interface keep changing so an out-of-tree module will only work on some versions, the usual problems...), difficult (kernel-mode code is hard to write), and generally a royal PITA.
2. Like (1) but use a framework like FUSD (the xiph.org version works on 2.6 kernels) to write the driver in user-space and then do USB I/O using libusb. I'm currently testing this approach, I suspect it's slow (how significantly remains to be seen), but at least it's more portable between Linux versions and easier to write and maintain.
3. Integrate your device into wine directly the way eg. serial ports have been done. This is hard, and requires introducing a new FD_TYPE, changing ntdll's file.c's NtReadFile, NtWriteFile, and NtDeviceIoControlFile (and asynchronous versions of those) to use special behavior for that FD_TYPE, and managing global device state (eg. i/o timeouts) in wineserver (look at server/serial.c). With a lot of time, and some changes to both wine and libusb, you could get it to work properly. This should IMO only be done for generally useful drivers, not drivers for just 1 type of device.
4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably through libusb), and modify ntdll to forward the appropriate reads, writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file can handle them. This is the only way that works with .SYS files out-of-the-box, the others all require a rewrite of the .SYS driver's functionality. Architecturally, this is the best way, you wouldn't need to change any code in wine to add a new driver.
Way 4 is probably the best and I hope it works at some stage, but it's still a long way off seeing as how NTOSKRNL.EXE itself still isn't in wine.
In the mean time, looks like I have some reading to do regarding USB spec, dbus and hal :-)
There is only 1 or 2 chapters you need from the USB spec. DBus is just an RPC framework, and HAL just lists devices and their properties, so they won't help much.
Thanks for the help so far.
Regards, Jono
Damjan
On Friday 04 May 2007, you wrote:
There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows
But there is, just that most vendors don't use it.
http://libusb-win32.sourceforge.net/ It doesn't seem maintained, but it did work in WIN98 era at least (used it back then).
(there is apparently some user-space USB stuff in mingw's headers, but I couldn't find any official docs on it, and it's not enough to write a user-space driver because there is no bulk/interrupt/isochronous pipe [...]
Woopty, finger slipped on enter :) Kuba
On 5/4/07, Kuba Ober <kuba(a)mareimbrium.org> wrote:
There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows
But there is, just that most vendors don't use it.
There is libusb-win32, but it uses its own kernel-mode driver. Vista has a user-space driver framework for some types of hardware. It supports USB drivers, and I think Microsoft did a backport to Windows XP as well. Hopefully vendors will start to use it instead of writing kernel-mode drivers, then we can easily use those drivers from wine :-). Damjan
On Fri, May 04, 2007 at 07:43:00AM -0400, Kuba Ober wrote:
There is no standard user-mode interface for accessing USB hardware - there is no equivalent of Linux's libusb on Windows
But there is, just that most vendors don't use it.
Lots of Windows driver vendors use the USBD.SYS (spelling?) driver abstraction though. Ciao, Marcus
4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably through libusb), and modify ntdll to forward the appropriate reads, writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file can handle them. This is the only way that works with .SYS files out-of-the-box, the others all require a rewrite of the .SYS driver's functionality. Architecturally, this is the best way, you wouldn't need to change any code in wine to add a new driver.
Way 4 is probably the best and I hope it works at some stage, but it's still a long way off seeing as how NTOSKRNL.EXE itself still isn't in wine.
Correct me if I'm wrong, but you're saying that this approach would enable wine to work with (almost?) any USB device, which has a vendor specific, kernel-mode driver, using the vendor's supplied driver out-of-the-box. Sounds like the best approach to me too. Maybe there are other people out there with the same problem as me, (or simply a desire to get better USB support in to wine) who would be interested in working on this too? Jono
On 5/5/07, Jon Burgess <jkburges(a)gmail.com> wrote:
4. Integrate NTOSKRNL.EXE into wine, add USB infrastructure to NTOSKRNL.EXE so that kernel-mode drivers can access USB (probably through libusb), and modify ntdll to forward the appropriate reads, writes, and i/o control requests to NTOSKRNL.EXE so that the .SYS file can handle them. This is the only way that works with .SYS files out-of-the-box, the others all require a rewrite of the .SYS driver's functionality. Architecturally, this is the best way, you wouldn't need to change any code in wine to add a new driver.
Way 4 is probably the best and I hope it works at some stage, but it's still a long way off seeing as how NTOSKRNL.EXE itself still isn't in wine.
Correct me if I'm wrong, but you're saying that this approach would enable wine to work with (almost?) any USB device, which has a vendor specific, kernel-mode driver, using the vendor's supplied driver out-of-the-box.
Yes.
Sounds like the best approach to me too.
Maybe there are other people out there with the same problem as me, (or simply a desire to get better USB support in to wine) who would be interested in working on this too?
But it's a lot of work, and very few people know how to write Windows drivers. NTOSKRNL.EXE has been around for a year or 2 now, and it still hasn't been accepted into wine. On a brighter note, NDISWRAPPER already works with some USB drivers, so it can't be that hard to do.
Jono
Damjan
On Fr, 2007-05-04 at 10:37 +0800, Jon Burgess wrote:
(Serato Scratch Live: http://www.rane.com/scratch.html) for which the software appears to run ok under wine (not that I am able to test much of its functionality on the other hand), but is utterly useless without support for its associated USB hardware device.
The driver is here: http://www.rane.com/sslfix.html It looks, that you need to use the vendor-driver, and Windows Kernel Drivers do not work in wine. "winedump dump -j import SeratoUsb.sys" ntoskrnl.exe hal.dll wmilib.sys usbd.sys -- By by ... Detlef
participants (6)
-
Damjan Jovanovic -
Detlef Riekenberg -
Jon Burgess -
Kuba Ober -
Marcus Meissner -
Tom Spear