wine / Linux kernel interaction

[Damjan Jovanovic]

--- Kuba Ober <kuba at mareimbrium.org> wrote:

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

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
ioctl's (USBSCAN_READ_REGISTERS,
USBSCAN_WRITE_REGISTERS,
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
> 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
> 
> 
> 



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs