wine / Linux kernel interaction
dj015 at yahoo.com
Fri Oct 21 00:17:53 CDT 2005
--- Kuba Ober <kuba at mareimbrium.org> wrote:
> > > So unless you need extra kernel-level
> > > or I'm completely
> > > off-track, I don't see why one would need that
> > > 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
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
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
> 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
> 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
> 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.
Start your day with Yahoo! - Make it your home page!
More information about the wine-devel