Re: wine / Linux kernel interaction and TWAIN
This area can be a real problem under Wine. The high end scanners such as the Minolta MS6000 simply aren't supported by SANE backend. If you want to use one then you must write code for the backend. You can usually get a basic TWAIN driver which is for Win. 98. These usually run under Wine. The real problem is doing anything with the TWAIN result. Things such as Acrobat Professional don't currently work under Wine. Neither does most of the picture software such as the Kodak software supplied in Win 98. This is the result of several unimplemented stubs and a couple of missing dlls. Some of the Omnipage software may work under Wine but I haven't had time to test it. I don't know of a good solution for the TWAIN problem under Wine or directly under Linux. If anyone else has a solution let's hear it.
This may be WAYYY off the mark, but does the windows version of the GIMP work in wine (I believe that it does) and if so, I think it has a font end for acquiring images from a scanner, I would assume through TWAIN. I own a HP scanjet 3570c that has no support under SANE, and I would love to get it working. It comes with it's own graphics front end program, but I have yet to get it working under wine. Randall Walls gslink wrote:
This area can be a real problem under Wine. The high end scanners such as the Minolta MS6000 simply aren't supported by SANE backend. If you want to use one then you must write code for the backend. You can usually get a basic TWAIN driver which is for Win. 98. These usually run under Wine. The real problem is doing anything with the TWAIN result. Things such as Acrobat Professional don't currently work under Wine. Neither does most of the picture software such as the Kodak software supplied in Win 98. This is the result of several unimplemented stubs and a couple of missing dlls. Some of the Omnipage software may work under Wine but I haven't had time to test it. I don't know of a good solution for the TWAIN problem under Wine or directly under Linux. If anyone else has a solution let's hear it.
On Fri, 21 Oct 2005 12:12, Randall Walls wrote:
I own a HP scanjet 3570c that has no support under SANE, and I would love to get it working. It comes with it's own graphics front end program, but I have yet to get it working under wine.
Actually it does, it's just that only two people have the code right now and neither has gotten around to packaging it in a releasable form.
--- Troy Rollo <wine(a)troy.rollo.name> wrote:
On Fri, 21 Oct 2005 12:12, Randall Walls wrote:
I own a HP scanjet 3570c that has no support under SANE, and I would love to get it working. It comes with it's own graphics front end program, but I have yet to get it working under wine.
A lot of you seem to not understand... In Windows: Windows App | v TWAIN | v TWAIN backend (scanner-specific) | v (other vendor-specific components) | v STI (made by Microsoft) | v STI minidriver (made by vendor) | v KERNEL32.DLL (ReadFile, WriteFile, DeviceIoControl) | | (user mode) --+--------------- | (kernel mode) | v USBSCAN.SYS (or SCSISCAN.SYS, infrared, serial etc. drivers) (made by Microsoft) | v Scanner (made by vendor) What I got working under Linux (well, only the Windows app branch, and that only for an app that bypasses TWAIN) is: Linux app Windows app | | v | SANE | | | v / SANE-to-TWAIN / | _____________/ v v wine TWAIN | v TWAIN backend | v wine STI | v STI minidriver | v wine | | (user mode) -+----------------- | (kernel mode) v windows_usbscan.ko /dev/USBSCAN... | v Linux USB stack | v Scanner In more detail: *Changed CreateFile() to check for \\.\USBSCAN..., and if so open /dev/USBSCAN... instead of calling VXD_Open(). Then it does wine_server_fd_to_handle(). *Changed NtDeviceIoControlFile() to check for the ioctl code 0x8000.... (FILE_DEVICE_USB_SCAN I think) and if so, instead of calling CDROM_DeviceIoControl(), it does... struct wine_packed_ioctl { LPVOID inputBuffer; DWORD inputBufferSize; LPVOID outputBuffer; DWORD outputBufferSize; } packed; packed.inputBuffer = .....; packed....... wine_server_handle_to_fd(...); ioctl(fd, 0x8000...., &packed); wine_server_release_fd(...); The kernel module behaves just like USBSCAN.SYS, reading and writing do raw USB bulk pipe reads and writes, and the ioctl's mostly do USB control pipe operations. And I made a thin little STI.DLL, just the bare minimum (my scanner driver only uses IStillImage::GetDeviceList() and IStillImage::GetDeviceValue()). Now, back to my original questions: how do I generalise the kernel module to work with more scanners (it's currently hardcoded for my scanner)? I need access to wine's registry / SetupAPI to know which scanners are installed. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On 10/20/05, Damjan Jovanovic <dj015(a)yahoo.com> wrote:
*Changed CreateFile() to check for \\.\USBSCAN..., and if so open /dev/USBSCAN... instead of calling VXD_Open(). Then it does wine_server_fd_to_handle(). ... The kernel module behaves just like USBSCAN.SYS, reading and writing do raw USB bulk pipe reads and writes, and the ioctl's mostly do USB control pipe operations.
And I made a thin little STI.DLL, just the bare minimum (my scanner driver only uses IStillImage::GetDeviceList() and IStillImage::GetDeviceValue()).
Sounds pretty cool! When will you post the sources?
Now, back to my original questions: how do I generalise the kernel module to work with more scanners (it's currently hardcoded for my scanner)? I need access to wine's registry / SetupAPI to know which scanners are installed.
You might have to have a userspace winelib daemon listening for requests from the kernel, and fulfilling them by calling the registry API.
--- Dan Kegel <daniel.r.kegel(a)gmail.com> wrote:
On 10/20/05, Damjan Jovanovic <dj015(a)yahoo.com> wrote:
*Changed CreateFile() to check for \\.\USBSCAN..., and if so open /dev/USBSCAN... instead of calling VXD_Open(). Then it does wine_server_fd_to_handle(). ... The kernel module behaves just like USBSCAN.SYS, reading and writing do raw USB bulk pipe reads and writes, and the ioctl's mostly do USB control pipe operations.
And I made a thin little STI.DLL, just the bare minimum (my scanner driver only uses IStillImage::GetDeviceList() and IStillImage::GetDeviceValue()).
Sounds pretty cool! When will you post the sources?
When my exams are over and I have some time to turn the hacks into semi-decent code (ie. 2-3 weeks).
Now, back to my original questions: how do I generalise the kernel module to work with more scanners (it's currently hardcoded for my scanner)? I need access to wine's registry / SetupAPI to know which scanners are installed.
You might have to have a userspace winelib daemon listening for requests from the kernel, and fulfilling them by calling the registry API.
I had a brief look at the Windows 2000 STI.DLL import table: most of the SetupAPI functions it uses are stubs on wine :-(. It seems a lot of work to implement them too: there are handles to various structures etc. Anyone in the mood? __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
--- Dan Kegel <daniel.r.kegel(a)gmail.com> wrote:
You might have to have a userspace winelib daemon listening for requests from the kernel, and fulfilling them by calling the registry API.
I had a brief look at the Windows 2000 STI.DLL import table: most of the SetupAPI functions it uses are stubs on wine :-(. It seems a lot of work to implement them too: there are handles to various structures etc. Anyone in the mood?
May the ReactOS code tree help you? http://reactos.geldorp.nl/dir_000323.html
--- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
--- Dan Kegel <daniel.r.kegel(a)gmail.com> wrote:
You might have to have a userspace winelib
daemon
listening for requests from the kernel, and fulfilling them by calling the registry API.
I had a brief look at the Windows 2000 STI.DLL import table: most of the SetupAPI functions it uses are stubs on wine :-(. It seems a lot of work to implement them too: there are handles to various structures etc. Anyone in the mood?
May the ReactOS code tree help you? http://reactos.geldorp.nl/dir_000323.html
Nice! Why isn't this part of wine already? __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
--- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
I had a brief look at the Windows 2000 STI.DLL import table: most of the SetupAPI functions it uses are stubs on wine :-(. It seems a lot of work to implement them too: there are handles to various structures etc. Anyone in the mood?
May the ReactOS code tree help you? http://reactos.geldorp.nl/dir_000323.html
Nice! Why isn't this part of wine already?
AFAIK, Some parts definitely are, but ROS folks just may be busy enough to sync both trees in realtime. :-/ Steven Edwards should have more clear idea about this, I guess. :-)
From: Saulius Krasuckas
* On Fri, 21 Oct 2005, Damjan Jovanovic wrote:
--- Saulius Krasuckas <saulius2(a)ar.fi.lt> wrote:
May the ReactOS code tree help you? http://reactos.geldorp.nl/dir_000323.html
Nice! Why isn't this part of wine already?
AFAIK, Some parts definitely are, but ROS folks just may be busy enough to sync both trees in realtime. :-/ Steven Edwards should have more clear idea about this, I guess. :-)
The ReactOS setupapi started out as a copy of the Wine setupapi. Recently, a lot of stuff was added on the ReactOS side. Usually, we try to merge changes back to Wine, but for various reasons this sometimes fails. For example, some of our developers don't run Linux and therefore do not have the possibility to test their changes under Wine too. There's also the feeling that Wine should be responsible for their own codebase so it would be more logical if a Wine developer was to take on the task of the backmerge. Anyway, we effectively forked setupapi at Wine-20050524, the codebases became too different to keep in sync easily. (We forked another component, widl, at Wine-20050628). Of course, our changes are available to Wine, I'd be happy to work with one of you guys to get the Wine/ReactOS versions back in sync. BTW, I'm the guy who usually merges the Wine changes into the ReactOS tree after a Wine release. Ge van Geldorp.
A lot of you seem to not understand...
In Windows:
Windows App v TWAIN v TWAIN backend (scanner-specific) v (other vendor-specific components) v STI (made by Microsoft) v STI minidriver (made by vendor) v KERNEL32.DLL (ReadFile, WriteFile, DeviceIoControl) | (user mode) --+--------------- | (kernel mode) v USBSCAN.SYS (or SCSISCAN.SYS, infrared, serial etc. drivers) (made by Microsoft) v Scanner (made by vendor)
One only hopes that most scanners work that way. The STI minidriver is free to open any device, not necessarily xxxSCAN.sys made by Microsoft. Now, if the majority works that way, then I guess we're all set. Kuba
participants (8)
-
Damjan Jovanovic -
Dan Kegel -
Ge van Geldorp -
gslink -
Kuba Ober -
Randall Walls -
Saulius Krasuckas -
Troy Rollo