wine / Linux kernel interaction
kuba at mareimbrium.org
Thu Oct 20 09:24:13 CDT 2005
> > 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
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
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.
More information about the wine-devel