> 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.
You can't simply change settings from under a running driver.
It's a bad idea even in principle. We have a model which has drivers
bind to and claim an interface for a reason. If you need this, add
the feature to the hid driver.
[..]
> 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.
No, if the device generates absolute coordinates, report them.
There's no use in lying.
> 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,
Yes, you need to filter this. This means you need a kernel driver.
Security must be done in kernel.
> 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.
Again, it's a display, so write an fb driver.
Regards
Oliver
-------------------------------------------------------
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
