--- Hiji hijinio@yahoo.com wrote:
--- Lars Segerlund lars.segerlund@comsys.se wrote:
What is the status of wines USB support ?
I have an IDE for a developement board and I
really
would like to flash it from Linux, ( I don't have windows), and this uses USB to talk to the board. Is there anything done yet or am I on my own ?
Can someone also giva a hint on the feasibiliyt, complexity of managing a USB implementation for wine ? I am rather good at
linux
device drivers and such.
/ regards, Lars Segerlund.
There's not much I can say in the way of development, but as a user, getting USB support (beyond what's supported in the kernel) would be a HUGE leap of improvement for Wine. I think others have said before that there are a lot of apps out there that will run on Wine, but are useless because they depend on their hardware counterpart. (In the music world, Guitarport comes to mind.)
Hiji
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
I have proposed several possible solutions for using USB under Linux. In fact, I have given 4 possible ways of doing it, one of which I have hacked up (and gotten to work, at least partially).
If you're interested in the details, let me know, and I'll email you (or look at the "Wine device drivers proposal" email in the Wine archives in the past month or so).
Briefly, Windows apps never use USB directly (there is no equivalent of libusb on Windows; well there is libusb-win32, but no closed-source projects use it). They open a "device file" of the form \Device\Options; so for instance my scanner driver opens \MiiScan0 and \MiiScan0\0\0\2. This opening is done using CreateFile(), which returns a handle.
3 other important functions are then used: WriteFile() - USB bulk writes ReadFile() - USB bulk reads DeviceIoControl() - USB control messages
Windows 2000 and XP have a set interface for using scanners, for example, so the parameters to these functions would be well known. For most other hardware it is trivial to reverse engineer it if necessary.
The problem is, Wine does all I/O (ie. ReadFile(), WriteFile(), DeviceIoControl()) using the @&#$!"* wineserver, by querying the wineserver for a file descriptor (int obtained by the POSIX open() function in Linux), and then doing read() or write(), while DeviceIoControl() in wine delegates to CDROM_DeviceIoControl() or fails.
CreateFile() is reasonably easy to hack - but the problem is that you need ways to:
1. Associate particular file descriptors to a dynamically linked library that would be identified by the CreateFile() argument (eg. for \MiiScan0, maybe the library would be MiiScan0.so).
2. Load up the library on CreateFile() with a reference count of 1 and unload it when CloseHandle() decrements the reference count to 0.
3. Use the library's functions for reading, writing, and ioctl's.
4. (This is the hardest part) Make ReadFile(), WriteFile() and DeviceIoControl() aware of which file descriptor identifies which library, and call the right libraries functions. This probably requires changes to the wineserver.
Phew, I thought I'd type a short reply! Interested in working on this? I can't do it all alone.
Bye Damjan
__________________________________ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide