On Fri, 5 Oct 2001, James Simmons wrote:

> 
> > Part 2 doesn't exist yet, because we don't have Part 1... ;)
> 
> Well we pretty much do. 

Indeed. At least, we have an API that should not be to hard to extend for
mice support. Of course, we also need a driver behind the API !

> 
> >  a) The lack of a good way to send interrupt messages to USB devices
> >     from userspace (like libusb, but someone suggested this isn't too
> >     hard to fix),
> 
> By interrupt messages what do you mean exactly.
> 
> >  b) the somewhat more troubling problem of where to fit the iFeel driver.
> >     The iFeel mouse is a regular old HID device, and I think that the
> >     HID driver does a wonderful job in controlling it. But the iFeel has
> >     an extra interrupt endpoint which takes the force feedback commands,
> >     and I wasn't sure the best way to put this nonstandard extension
> >     into the current USB framework without rewriting or duplicating a
> >     lot of code nicely implemented in the HID driver.

I guess you could simply extend the existing hid driver. There are
callbacks in the input_dev structure, which are currently not used in hid.
These callbacks are:
* upload_effect to upload a new effect to the device or update an existing 
one
* erase_effect to suppress an effect
* event is used to play and stop effects

> 
> > Problem b is a more complicated issue, and I think this needs to be resolved
> > before we can move forward. I don't think it's a huge issue, but it needs
> > to be addressed. The place to do it is with the linuxconsole folks...
> 
> Hm. Do you have documentation on the iFeel protocol to how we can fit
> things together?
> 

I guess Adam knows pretty well the protocol. Anyway, I found this:
http://moore.cx/out/ifeel/


-- 
Johann Deneux


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to