From: Johann D. <jo...@Do...> - 2001-10-05 21:39:45
|
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 |