On Mon, 18 Nov 2002, Greg KH wrote: > > > On Mon, Nov 18, 2002 at 02:29:56PM +0000, Rob Miller wrote: > > > > (1) I just 'grabbed' ioctls 'U' 0x71-0x79 (77-79 in the 0.3 ver at
> It's much better to wrap things like this through a userspace library > that does not use ioctls. It looks like you might be able to do > everything through libusb/usbfs to do the special things this device > has, and let the HID driver take over the mouse part. > > Or am I missing something? maybe, but better if we start with what I'm missing :-) My experience with the HID driver was that once it grabbed the device I couldn't do much with it, in particular I couldn't go in and tell it to switch to 'alternate setting 2' on interface 0. I admit to not getting very far with libusb, and in a previous message I referred to using an 'alternate interface', which was not the correct terminology -- it's all on interface 0. I thought that the hotplug control files would be the right place to tell the HID driver this sort of thing, but that also did not seem to be the case (I know, usb-dev folk also have enough to do :-). If I had been able to switch it to AS2, the HID driver would need to be able to understand the absolute mouse coordinates and (ideally) be able to filter the mouse input based on the 'pressure' reading (on mine the capacitance is sufficient to pick up finger motion 1-2cm above the pad). The absolute coords were reasonably easy to work out by watching them and studying the wacom tablet driver, but they weren't the same as for the wacom and I don't know if there is a standard here. Also I found that just passing the absolute vals to X and telling it to treat it as an absolute mouse worked (this is still a load option for my module) -- but the behaviour isn't what I wanted for a mouse. OTOH, absolute coords internally is exactly what's needed to support (say) some special action when the user touches a drawn button in the upper left corner of the touchpad -- and this might be an appropriate evolution of the driver. Finally, one of my goals was to isolate and filter writes to the bulk endpoint to some extent -- if a sequence starting with '01 01' is written, the eeprom loads whatever comes next and then it's off to the Toshiba repair shop to make the LCD work again (tho the mouse continues to work fine). I've learned that the sequence '01 02' causes it to report parameters from the eeprom, so I put the output in comments in my code and leave it to someone else to work out if there's really enough there to reload it correctly (I've already had my fun with this feature). Anyway, it seems like libusb supporting direct writes to the bulk endpoint leaves things a bit more open to writing the 01 01 sequence in error, whereas my current driver explicitly separates commands starting with 01 into the ioctls (building the messages within the driver). Writes to the LCD controller start with a '02' so my driver explicitly pre-pends this byte to messages coming via the device file i/o -- a bad message to the LCD controller seems like it can always be fixed with a device reset, and there is too much flexibility in the controller commands to want (or be able) to limit actions here with many predefined routines. Opinions, advice, thoughts all happily accepted, rob. ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
