Re: IFeel support

[Johann D. <jo...@do...>]

On Thu, 7 Feb 2002, Adam Goode wrote:

> I have a couple such mice, and I had wanted to start such work last summer.
> 
> But I ran into a few issues, and kind of just put things on hold.
> Perhaps these are now adequately solved?
> 
> Issues:
> 
>  * The HID driver which controls mice and mice-like devices had no support
>    for force feedback stuff, and I really didn't want to make a 
>    completely new driver which was specific to the iFeel and yet
>    was 99% identical to the generic HID stuff.

Other people here are working on implementing force-feedback using the pid
specification. So you are not alone on this. However, you raise a valid
issue. It seems we have many hid/ff combinations:
- hid/iforce
- hid/pid
- hid/whatever...

How to handle this while keeping the code clean is going to be an
interesting design issue.

> 
>  * When I was playing with libusb in testing, I orginially was sending
>    control transfers (which usb-robot supported). But I found out that
>    the (more-correct?) way to drive the device was through interrupt
>    transfers, which libusb didn't support. Does this now work with
>    "one-shot interrupt" support in usbdevfs?

It seems one-shot interrupt urbs can be successfuly emulated with bulk
urbs anyway.

> 
>  * It seemed like overkill to build a full kernel space driver for this
>    device. This is the big question:
> 
>    Should the iFeel be controlled by the generic HID driver like a normal
>    mouse, with some additional user space stuff (like libusb) controlling
>    the vibration?

No, we allready have a kernel interface (evdev) for force feedback. So
libusb is not going to help us here. Unless we use a combination of
evdev/libusb.

> 
> 
> I think the user space vs. kernel space issue is important. What does
> everyone think?
> 
> 
> Points:
> 
>  * User space driver: does not require (much?) modification to existing
>                       kernel drivers, should be easier to develop and
>                       test, but might cause issues related to finding
>                       the correct devices and perhaps permissions problems
> 
>  * Kernel space driver: might require making a whole new driver or
>                         adding special cases to the existing HID structures,
>                         needs some userspace stuff anyway (to manage
>                         interaction with GUI elements, etc.)

There are already people here who are working on a user-space
libff.

> 
> 
> These are just some issues, but I am leaning towards just having a
> user space driver. I am looking forward to comments on this....
> 

Having a working user-space implementation won't hurt anyway, especially
if you find it easier to develop.

-- 
Johann Deneux