Hi,
I'm trying to connect through wine the CED1401 device which is connected through USB. There is a driver in the linux staging tree, (linux-source-3.10/drivers/staging/ced1401/), which I've already compiled into my kernel. The module loads fine and becomes available when connecting to the device.
The are several application software for Windows (e.g. ced1401 [1], Spike [2], Signal5, and we have also one running in Igor Pro). The software runs also on Wine, but fails to identify the connected hardware device.
I've tried to find relevant information in the wiki; and especially, http://wiki.winehq.org/USB as well as wine developer guide, Chapter 8 Kernel modules. I've a rough idea what is missing, but would like asking what you think is missing, and how much effort it would take to get this working ?
--Alois
[1] http://appdb.winehq.org/objectManager.php?sClass=application&iId=15958 [2] http://appdb.winehq.org/objectManager.php?sClass=application&iId=9146
http://wiki.winehq.org/USB is about running Windows USB drivers in Wine. If you were able to make this work, it would mean that the native Linux driver isn't involved at all, similar to what would happen if you connected a USB device to a virtual machine.
Devices with Linux native drivers can work in Wine without needing to run a Windows driver, as long as the device is accessed through a standard and generic Windows API that Wine provides, such as DirectInput for joysticks.
If you have a specialized device for which no generic API exists, there's no way for Wine to provide access to that device to Windows programs in a generic way. It can, however, be done in a device-specific way based on the respective API's for accessing that device on Linux and Windows.
How would a Windows software developer access the device you're trying to use? Is there a specific API (it doesn't have to be included in Windows) that would allow a Windows developer to target a range of similar devices? If so, providing an implementation of that API in Wine is probably the best approach. If not, you'll need to either run the Windows driver somehow (very difficult, I would guess) or create a replacement for it (may be much easier, depending on how similar the Linux and Windows API's are, and how complex they are).
If you can find some documentation for those interfaces, then we can talk more specifically about how to provide them in Wine.
On 2014-03-31 18:18, Vincent Povirk wrote:
http://wiki.winehq.org/USB is about running Windows USB drivers in Wine. If you were able to make this work, it would mean that the native Linux driver isn't involved at all, similar to what would happen if you connected a USB device to a virtual machine.
I've tried this with 1.5.7, 1.4.1, as well as a recent version from the repository (1.7.14+). I tried 1.4.1 with patches from [1]; althought there are a number of steps involved, I'm pretty sure that I've applied them all as described. Especially, exporting and importing the registry entries is not trivial and one could get something wrong. Same with 1.5.7 (but I was not that careful in applying steps). For 1.7.14, there are no patches in [1] that apply in clean way, and I did not apply any.
In all cases, result was the same. The application software was running but did not find the connected USB device.
[1] ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ [2] http://wiki.winehq.org/Wine64
Devices with Linux native drivers can work in Wine without needing to run a Windows driver, as long as the device is accessed through a standard and generic Windows API that Wine provides, such as DirectInput for joysticks.
No, that's not applicable here. The application comes with a dll.
If you have a specialized device for which no generic API exists, there's no way for Wine to provide access to that device to Windows programs in a generic way. It can, however, be done in a device-specific way based on the respective API's for accessing that device on Linux and Windows.
How would a Windows software developer access the device you're trying to use? Is there a specific API (it doesn't have to be included in Windows) that would allow a Windows developer to target a range of similar devices?
Yes, there is an API, implemented as DLL. See below.
If so, providing an implementation of that API in Wine is probably the best approach. If not, you'll need to either run the Windows driver somehow (very difficult, I would guess) or create a replacement for it (may be much easier, depending on how similar the Linux and Windows API's are, and how complex they are).
My guess is that they are quite similar.
If you can find some documentation for those interfaces, then we can talk more specifically about how to provide them in Wine.
Yes, there is documentation and as far as I know there is no secrecy.
You will find it on this webpage [4]. Look for "1401 Programming Support". After installation (works fine in wine, too), you can find these interfaces:
~/.wine/drive_c/1401Lang/WinSupp/Use1401.h ~/.wine/drive_c/1401Lang/WinSupp/Use1432.dll
Another interesting part on page [4] is the link "Windows installation" leading to a download called "winsupp.exe". After installation, you can find several *.sys and *.dll files in .wine/drive_c/1401/WinDrv/ ced_usb.sys and ced_us64.sys are the driver listed in the registry (on 32 and 64 bit windows, resp) after installation. It contains also the program try1432.exe, which is used for testing the connection to the device.
-- Alois
Yes, there is documentation and as far as I know there is no secrecy.
You will find it on this webpage [4]. Look for "1401 Programming Support". After installation (works fine in wine, too), you can find these interfaces:
~/.wine/drive_c/1401Lang/WinSupp/Use1401.h ~/.wine/drive_c/1401Lang/WinSupp/Use1432.dll
Seems to me your best bet would be to ignore the drivers completely and work on a winelib replacement for Use1432.dll. There shouldn't be any need to run or replace the device driver, as long as the applications you need go through that dll rather than accessing it directly (and both of those options are likely more difficult than replacing a dll).
You can use the winedump command to generate a .spec file which you can then use to build a stub dll. See http://www.winehq.org/docs/winelib-guide/bindlls for some information on that. In this case, your interface is dictated to you by the header and dll file, and the corresponding Linux api probably consists of opening a Linux device file and doing ioctl() calls on it.
Note that you don't need to implement all or even any functions to use the dll. If a program calls an unimplemented function, the function name will be sent to stderr, and the program will crash. Which is a good way to check whether your programs are using the dll, and which functions you'll need. As you implement them, remember to replace the "stub" lines in your spec file with stdcall lines so they are actually used.
Also, if you want to distribute your code, keep in mind there's no license on their header, and you may need to replace it if you don't want a dependency on it.
BTW, try1432.exe doesn't appear to use use1432.dll and instead attempts to directly access the device file at \.\CED1. I tested this by running with WINEDEBUG=+loaddll.
Forgot to add the link to reference [4]. Here it is: [4] http://ced.co.uk/upu.shtml
On 2014-03-31 18:18, Vincent Povirk wrote:
http://wiki.winehq.org/USB is about running Windows USB drivers in Wine. If you were able to make this work, it would mean that the native Linux driver isn't involved at all, similar to what would happen if you connected a USB device to a virtual machine.
I've tried this with 1.5.7, 1.4.1, as well as a recent version from the repository (1.7.14+). I tried 1.4.1 with patches from [1]; althought there are a number of steps involved, I'm pretty sure that I've applied them all as described. Especially, exporting and importing the registry entries is not trivial and one could get something wrong. Same with 1.5.7 (but I was not that careful in applying steps). For 1.7.14, there are no patches in [1] that apply in clean way, and I did not apply any.
In all cases, result was the same. The application software was running but did not find the connected USB device.
[1] ftp://ftp.etersoft.ru/pub/people/amorozov/usb/ [2] http://wiki.winehq.org/Wine64
Devices with Linux native drivers can work in Wine without needing to run a Windows driver, as long as the device is accessed through a standard and generic Windows API that Wine provides, such as DirectInput for joysticks.
No, that's not applicable here. The application comes with a dll.
If you have a specialized device for which no generic API exists, there's no way for Wine to provide access to that device to Windows programs in a generic way. It can, however, be done in a device-specific way based on the respective API's for accessing that device on Linux and Windows.
How would a Windows software developer access the device you're trying to use? Is there a specific API (it doesn't have to be included in Windows) that would allow a Windows developer to target a range of similar devices?
Yes, there is an API, implemented as DLL. See below.
If so, providing an implementation of that API in Wine is probably the best approach. If not, you'll need to either run the Windows driver somehow (very difficult, I would guess) or create a replacement for it (may be much easier, depending on how similar the Linux and Windows API's are, and how complex they are).
My guess is that they are quite similar.
If you can find some documentation for those interfaces, then we can talk more specifically about how to provide them in Wine.
Yes, there is documentation and as far as I know there is no secrecy.
You will find it on this webpage [4]. Look for "1401 Programming Support". After installation (works fine in wine, too), you can find these interfaces:
~/.wine/drive_c/1401Lang/WinSupp/Use1401.h ~/.wine/drive_c/1401Lang/WinSupp/Use1432.dll
Another interesting part on page [4] is the link "Windows installation" leading to a download called "winsupp.exe". After installation, you can find several *.sys and *.dll files in .wine/drive_c/1401/WinDrv/ ced_usb.sys and ced_us64.sys are the driver listed in the registry (on 32 and 64 bit windows, resp) after installation. It contains also the program try1432.exe, which is used for testing the connection to the device.
-- Alois
-
Alois Schlögl -
Vincent Povirk