I am working on STI for wine, and there is an issue I want to ask about.
At present, I changed CreateFile() to open /dev/USBSCAN... on a "\.\USBSCAN..." device, where /dev/USBSCAN... comes from a Linux kernel module that does the equivalent of Window's USBSCAN.SYS. And NtDeviceIoControl() checks whether the i/o control code is 0x8000.... (USB scanner ioctl) and if so, calls ioctl(). It all works (but most is hardcoded for my scanner at the moment).
But, the kernel module needs to know whether a newly added USB device is a scanner or not, which requires access to the wine registry / SetupAPI. One option is to make some user-space utility that the module can query for this info. The other way it could be done is to give wine the ability to load the kernel module when wine starts, and pass it a list of parameters which are the scanners it should drive. And the third way is to use a private ioctl or the proc filesystem so wine gives a running instance of the module the list of scanners, when wine itself starts running.
And how would the kernel module tell wine / STI a new scanner has arrived?
Finally, could this kernel module be distributed with wine? Its acceptance into the Linux kernel tree is doubtful.
Thank you Damjan
P.S. Is anyone working on kernel handles for wine?
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Hi,
On Wed, Oct 19, 2005 at 09:55:49AM -0700, Damjan Jovanovic wrote:
Finally, could this kernel module be distributed with wine? Its acceptance into the Linux kernel tree is doubtful.
I'm afraid I can't answer your questions, but is there really a need to development a kernel module for your USB scanner??
SANE has been having USB user-space modules for ages, I believe (via libusb functionality?).
So unless you need extra kernel-level functionality or I'm completely off-track, I don't see why one would need that (much less want that!).
Andreas Mohr
--- Andreas Mohr andi@rhlx01.fht-esslingen.de wrote:
Hi,
On Wed, Oct 19, 2005 at 09:55:49AM -0700, Damjan Jovanovic wrote:
Finally, could this kernel module be distributed
with
wine? Its acceptance into the Linux kernel tree is doubtful.
I'm afraid I can't answer your questions, but is there really a need to development a kernel module for your USB scanner??
SANE has been having USB user-space modules for ages, I believe (via libusb functionality?).
If you know a way to change ReadFile(), WriteFile(), and DeviceIoControl() to call libusb functions, please tell me, that's what I wanted to do from the beginning. In Wine, a HANDLE _is_ a file descriptor, which doesn't help at all.
So unless you need extra kernel-level functionality or I'm completely off-track, I don't see why one would need that (much less want that!).
Because the scanner, like too many others, is unsupported by SANE.
Andreas Mohr
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On 10/20/05, Damjan Jovanovic dj015@yahoo.com wrote:
Because the scanner, like too many others, is unsupported by SANE.
Ah. Then here's my suggestion: go ahead and implement your kernel module. It's ok if it's not widely used; it can just be a prototype showing how useful the idea is.
Perhaps your kernel module will make it easier to reverse-engineer the protocol used by various USB devices and add support for them to SANE later.
So unless you need extra kernel-level functionality or I'm completely off-track, I don't see why one would need that (much less want that!).
Because the scanner, like too many others, is unsupported by SANE.
This makes no sense. What does lack of support in SANE have to do with development of a kernel module?
Libusb is a userspace library that gives you raw access to any usb device. Using libusb you're able to accomplish almost everything that a kernel driver would. Libusb is perfect for devices that are used by one application at a time.
Now, the thing about ReadFile(), WriteFile() and DeviceIoControl() in windows is that the underlying driver doesn't necessarily directly forward those to the usb device in question. E.g. ReadFile() might be reading formatted image data, while the scanner itself is sending something in a different format that needs calibration and so on inside of the driver. It's is the scanner driver in question that gets the ReadFile() and WriteFile() requests and then decides how to translate them into relevant usb transactions.
One only hopes that scanner developers are lazy and they used some example DDK code w/o changes, so that we'd be able to translate ReadFile(), etc. into relevant usb requests in a similar way and it'd 'just work'. So, it's sheer luck that ReadFile() and WriteFile() would translate directly to sending data over say a bulk endpoint. So it might work for one scanner, but not work with some other scanner.
So, the luck might be on our side as driver development is typically best avoided, so that scanner people might well put as little functionality into the scanner driver as possible, relegating it all to the userland application.
The DeviceIoControl() is driver specific too. It's up to the driver to decide how those are handled. If windows has similar fallback mechanism over the driver layers as linux has, then one might hope that the application that invokes DeviceIoControl() is using common windows USB IOCTL's and directly interrogating say the device descriptors and so on. That'd require some DDK reading to ascertain. Even though in windows the driver is free to incercept those DeviceIoControl calls and filter them as it pleases.
The only way that works everytime would be to load the device's .vxd/.sys into the userspace, provide some WDM APIs that a USB device driver expects, and simulate the windows USB stack with libusb.
This feat has been accomplished, in the kernel land and for network adapters, by ndiswrapper project. They did a partial WDM (windoze driver model) API implementation inside of the linux kernel. Wine might be able to do the same in the userland, especially that one hopes that e.g. USB scanner drivers are not as timing-critical as wireless network drivers.
I hope I cleared up some misunderstanding.
Kuba
Pretty much all scanners I have seen implement a standard API (such as TWAIN or whatever the "scanners and cameras" folder maps to) which programs like Photoshop and GIMP use to talk to the scanner directly.
On linux, it seems like the equivelent is SANE.
To me, the right answer is for WINE to emulate TWAIN and the other APIs on top of SANE. And then for a mapper driver written to go the other way so that apps (including WINE) would talk to SANE and then SANE would talk to the TWAIN stuff which would in turn talk to the device driver (which could talk to the hardware itself via libusb)
Pretty much all scanners I have seen implement a standard API (such as TWAIN or whatever the "scanners and cameras" folder maps to) which programs like Photoshop and GIMP use to talk to the scanner directly.
On linux, it seems like the equivelent is SANE.
To me, the right answer is for WINE to emulate TWAIN and the other APIs on top of SANE. And then for a mapper driver written to go the other way so that apps (including WINE) would talk to SANE and then SANE would talk to the TWAIN stuff which would in turn talk to the device driver (which could talk to the hardware itself via libusb)
Something like that, yes. Although most twain device implementations suck, because they present a UI before a scanning job can be started. That seriously degrades ability to do programmatic control of scanning process.
For SANE devices which would use the wine-twain (assume that'd be the name) backend, wine might as well talk directly to the twain implementation. I.e.
(view in fixed font)
0. windoze app 1. wine twain API 2a. windoze twain driver | 2b. sane device, backend != wine-twain 3a. windoze device driver | 3b. sane backend 4. device
0. unix app 1. sane API 2a. sane backend != wine-twain | 2b. sane backend = wine-twain 3a. device | 3b. wine twain API . | 4b. windoze device driver . | 5b. device
Kuba
On 10/20/05, Jonathan Wilson jonwil@tpgi.com.au wrote:
To me, the right answer is for WINE to emulate TWAIN and the other APIs on top of SANE.
Um... we already do. Of course, it requires xscanimage for the front end and that should probably be updated to use a newer sane-frontends interface.
-Brian
--- Kuba Ober kuba@mareimbrium.org wrote:
So unless you need extra kernel-level
functionality
or I'm completely off-track, I don't see why one would need that
(much
less want that!).
Because the scanner, like too many others, is unsupported by SANE.
This makes no sense. What does lack of support in SANE have to do with development of a kernel module?
Libusb is a userspace library that gives you raw access to any usb device. Using libusb you're able to accomplish almost everything that a kernel driver would. Libusb is perfect for devices that are used by one application at a time.
I've used it before.
Now, the thing about ReadFile(), WriteFile() and DeviceIoControl() in windows is that the underlying driver doesn't necessarily directly forward those to the usb device in question.
Yes it does, look at include/ddk/usbscan.h in mingw32, or MSDN's STI/WIA documentation, the section on USBSCAN.SYS. Reading and writing do raw bulk pipe transfers, ioctl's do specific things: particular ioctl's (USBSCAN_READ_REGISTERS, USBSCAN_WRITE_REGISTERS, USBSCAN_SEND_DEVICE_REQUEST...) build and send control pipe USB packets. I did implement the kernel module and it really works, in case I forgot to mention it.
E.g. ReadFile() might be reading formatted image data, while the scanner itself is sending something in a different format that needs calibration and so on inside of the driver. It's is the scanner driver in question that gets the ReadFile() and WriteFile() requests and then decides how to translate them into relevant usb transactions.
One only hopes that scanner developers are lazy and they used some example DDK code w/o changes, so that we'd be able to translate ReadFile(), etc. into relevant usb requests in a similar way and it'd 'just work'. So, it's sheer luck that ReadFile() and WriteFile() would translate directly to sending data over say a bulk endpoint. So it might work for one scanner, but not work with some other scanner.
So, the luck might be on our side as driver development is typically best avoided, so that scanner people might well put as little functionality into the scanner driver as possible, relegating it all to the userland application.
The DeviceIoControl() is driver specific too. It's up to the driver to decide how those are handled. If windows has similar fallback mechanism over the driver layers as linux has, then one might hope that the application that invokes DeviceIoControl() is using common windows USB IOCTL's and directly interrogating say the device descriptors and so on. That'd require some DDK reading to ascertain. Even though in windows the driver is free to incercept those DeviceIoControl calls and filter them as it pleases.
The only way that works everytime would be to load the device's .vxd/.sys into the userspace, provide some WDM APIs that a USB device driver expects, and simulate the windows USB stack with libusb.
This feat has been accomplished, in the kernel land and for network adapters, by ndiswrapper project. They did a partial WDM (windoze driver model) API implementation inside of the linux kernel. Wine might be able to do the same in the userland, especially that one hopes that e.g. USB scanner drivers are not as timing-critical as wireless network drivers.
I hope I cleared up some misunderstanding.
Kuba
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
Yes it does, look at include/ddk/usbscan.h in mingw32, or MSDN's STI/WIA documentation, the section on USBSCAN.SYS. Reading and writing do raw bulk pipe transfers, ioctl's do specific things: particular ioctl's (USBSCAN_READ_REGISTERS, USBSCAN_WRITE_REGISTERS, USBSCAN_SEND_DEVICE_REQUEST...) build and send control pipe USB packets. I did implement the kernel module and it really works, in case I forgot to mention it.
Although it will surely work for scanners that use that code, there's no way to guarantee that all scanners behave that way. Their implementers are free to code whatever they want in the driver. So while this solution works for devices that use the usbscan.sys, it doesn't cover other devices. I don't know any statistics about who uses usbscan.sys and who doesn't, so maybe it's all a moot point.
Kuba
On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote:
Because the scanner, like too many others, is unsupported by SANE.
Which scanner?
--- Troy Rollo wine@troy.rollo.name wrote:
On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote:
Because the scanner, like too many others, is unsupported by SANE.
Which scanner?
Microtek ScanMaker 3800
__________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Fri, 21 Oct 2005 15:20, Damjan Jovanovic wrote:
--- Troy Rollo wine@troy.rollo.name wrote:
On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote:
Because the scanner, like too many others, is unsupported by SANE.
Which scanner?
Microtek ScanMaker 3800
Have you looked at http://www.ziplabel.com/sm3840/?
--- Troy Rollo wine@troy.rollo.name wrote:
On Fri, 21 Oct 2005 15:20, Damjan Jovanovic wrote:
--- Troy Rollo wine@troy.rollo.name wrote:
On Thu, 20 Oct 2005 17:15, Damjan Jovanovic
wrote:
Because the scanner, like too many others, is unsupported by SANE.
Which scanner?
Microtek ScanMaker 3800
Have you looked at http://www.ziplabel.com/sm3840/?
And tried it. The scanner protocol is virtually identical, but a few little differences here and there result in scary noises coming from the scanner, and it doesn't budge.
__________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
- --- Troy Rollo wine@troy.rollo.name wrote:
Microtek ScanMaker 3800
Have you looked at http://www.ziplabel.com/sm3840/?
And tried it. The scanner protocol is virtually identical, but a few little differences here and there result in scary noises coming from the scanner, and it doesn't budge.
Do you mean you've already patched USB IDs, as the page mentions? It might be interesting to see, if 3800 uses the same chip (SCAN08).
Am Freitag, den 21.10.2005, 10:47 +1000 schrieb Troy Rollo:
On Thu, 20 Oct 2005 17:15, Damjan Jovanovic wrote:
Because the scanner, like too many others, is unsupported by SANE.
Which scanner?
Lexmark x5130
http://www.sane-project.org/unsupported/lexmark-x5130.html
-
Andreas Mohr -
Brian Vincent -
Damjan Jovanovic -
Dan Kegel -
Detlef Riekenberg -
Jonathan Wilson -
Kuba Ober -
Saulius Krasuckas -
Troy Rollo