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