linuxconsole-dev

IFeel support

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

Hi,

Does anyone have an IFeel mouse at hand here ? Information about the
protocol can be found here:
http://moore.cx/out/ifeel/

If no one with an IFeel mouse feels like starting to implement a driver
using the information available above, I may well volunteer to do it, but
that means I would need to buy such a mouse.

-- 
Johann Deneux

Re: IFeel support

[Adam G. <ad...@ev...>]

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.

 * 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 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?


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.)


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



Adam




On Tue, Feb 05, 2002 at 10:06:49AM +0100, Johann Deneux wrote:
> Hi,
> 
> Does anyone have an IFeel mouse at hand here ? Information about the
> protocol can be found here:
> http://moore.cx/out/ifeel/
> 
> If no one with an IFeel mouse feels like starting to implement a driver
> using the information available above, I may well volunteer to do it, but
> that means I would need to buy such a mouse.
> 
> -- 
> Johann Deneux
> 
> 
> 
> _______________________________________________
> Linuxconsole-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxconsole-dev
> 

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

Re: IFeel support

[Vojtech P. <vo...@su...>]

On Thu, Feb 07, 2002 at 12:56:06PM -0500, 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.

I think the HID driver can be extended to handle ifeel. The same way as
it will have to be extened to handle PID. There isn't much difference,
really. By the way, we could get rid of the Wacoms in the black list
this way as well.

-- 
Vojtech Pavlik
SuSE Labs