wine / Linux kernel interaction

[Kuba Ober]

> > 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