Re: Logitech Spring FF

Re: Logitech Spring FF

[johann deneux]

I'm forwarding this mail to linux-input, that's a better place for
this discussion.
Richard is working on adding support for spring force feedback effects
to the hid-lgff driver.

On 4/7/07, Richard Bolkey <rbolkey@cs.utexas.edu> wrote:
> johann deneux wrote:
> > Yes. It's possible to implement everything using a constant force
> > effect updated at regular intervals.
> > Are you working to extending the driver in the kernel, or are you
> > doing the work in user-space?
> Working off the driver in the kernel.  Can/should I do this in user
> space?  I also noticed with the latest kernels there is a ff-memless.c.

I'm not sure. Doing in the kernel would allow for a shorter update
cycle, I think. I had initially intended to do what you are doing in
the kernel, but I never actually finished the task.
One of the problem I remember encountering was related to computing
sine values when simulating a periodic effect. Is there a math lib
available in the kernel?

> Is that an attempt to do all effect calculations in a single module, and
> a driver like hid-lgff.c would just need to do the device recognitions?

I guess so, but you should check with the author.

Re: Logitech Spring FF

[Anssi Hannula]

johann deneux wrote:
> I'm forwarding this mail to linux-input, that's a better place for
> this discussion.
> Richard is working on adding support for spring force feedback effects
> to the hid-lgff driver.
> 
> On 4/7/07, Richard Bolkey <rbolkey@cs.utexas.edu> wrote:
>> johann deneux wrote:
>> > Yes. It's possible to implement everything using a constant force
>> > effect updated at regular intervals.
>> > Are you working to extending the driver in the kernel, or are you
>> > doing the work in user-space?
>> Working off the driver in the kernel.  Can/should I do this in user
>> space?  I also noticed with the latest kernels there is a ff-memless.c.
> 
> I'm not sure. Doing in the kernel would allow for a shorter update
> cycle, I think. I had initially intended to do what you are doing in
> the kernel, but I never actually finished the task.

The correct way to implement this is to do it in ff-memless.c, and it
already has the framework to do effect conversions.

> One of the problem I remember encountering was related to computing
> sine values when simulating a periodic effect. Is there a math lib
> available in the kernel?

There is your fixp-arith.h in /drivers/input and apparently some random
math functions in /lib.

(and I think the fixp-arith.h should really be in /lib as well)

>> Is that an attempt to do all effect calculations in a single module, and
>> a driver like hid-lgff.c would just need to do the device recognitions?
> 
> I guess so, but you should check with the author.
> 

Yes, it is.


-- 
Anssi Hannula

Re: Logitech Spring FF

[Richard Bolkey]

First off, I've never made a patch before, which I guess I better learn, 
but for now if anyone wants to add the device_type for the Logitech 
Force 3D Pro Joystick to hid-lgff.c, it's { 0x046d, 0xc286, ff_joystick }.

Now for a few follow up questions (this is a whole lot of new stuff, so 
bear with me).

1) I'm gathering that Logitech keeps their hid reports secret and 
non-standard, or else I'd just be using the HID PID driver?  So, were 
the values in the reports found in hid_lgff_play discovered through 
trial and error?  How would I find what the report for FF_SPRING should 
look like?

2) Previous question assumes that is where I should implement the effect 
since ml->play_effect is referencing that function in ff_memless.c.  But 
it sounded like Anssi was recommending doing a spring->constant 
conversion akin to what looks like a periodic->rumble conversion in 
ml_combine_effects?

Thanks,
Rick

Re: Logitech Spring FF

[Dmitry Torokhov]

On Tuesday 10 April 2007 01:45, Richard Bolkey wrote:
> First off, I've never made a patch before, which I guess I better learn, 
> but for now if anyone wants to add the device_type for the Logitech 
> Force 3D Pro Joystick to hid-lgff.c, it's { 0x046d, 0xc286, ff_joystick }.
>

That would be Jiri Kosina (CCed).
 
> Now for a few follow up questions (this is a whole lot of new stuff, so 
> bear with me).
> 
> 1) I'm gathering that Logitech keeps their hid reports secret and 
> non-standard, or else I'd just be using the HID PID driver?  So, were 
> the values in the reports found in hid_lgff_play discovered through 
> trial and error?  How would I find what the report for FF_SPRING should 
> look like?
> 
> 2) Previous question assumes that is where I should implement the effect 
> since ml->play_effect is referencing that function in ff_memless.c.  But 
> it sounded like Anssi was recommending doing a spring->constant 
> conversion akin to what looks like a periodic->rumble conversion in 
> ml_combine_effects?
> 
> Thanks,
> Rick
> 

-- 
Dmitry

Re: Logitech Spring FF

[johann deneux]

On 4/10/07, Richard Bolkey <rbolkey@cs.utexas.edu> wrote:
> First off, I've never made a patch before, which I guess I better learn,
> but for now if anyone wants to add the device_type for the Logitech
> Force 3D Pro Joystick to hid-lgff.c, it's { 0x046d, 0xc286, ff_joystick }.
>
> Now for a few follow up questions (this is a whole lot of new stuff, so
> bear with me).
>
> 1) I'm gathering that Logitech keeps their hid reports secret and
> non-standard, or else I'd just be using the HID PID driver?  So, were
> the values in the reports found in hid_lgff_play discovered through
> trial and error?  How would I find what the report for FF_SPRING should
> look like?

You can do that by spying on the USB traffic generated by an existing driver.
That's what I did. I thought I had managed to identify the report used
for springs, but at that point my device died and that's where I
stopped.

>
> 2) Previous question assumes that is where I should implement the effect
> since ml->play_effect is referencing that function in ff_memless.c.  But
> it sounded like Anssi was recommending doing a spring->constant
> conversion akin to what looks like a periodic->rumble conversion in
> ml_combine_effects?

That's another way of doing it.

>
> Thanks,
> Rick
>

Re: Logitech Spring FF (effect on/off)

[Richard Bolkey]

Alright, I can turn the spring effect on; however, I can't turn it off 
right now.  There is a separate report that needs to be sent to turn off 
the spring effect for each axis.  I can't see an obvious place to put 
that kind of functionality into the framework of ff-memless.  I'm 
wondering if this means my device isn't "memoryless"?  Any advice?

Re: Logitech Spring FF (effect on/off)

[Anssi Hannula]

Richard Bolkey kirjoitti:
> Alright, I can turn the spring effect on; however, I can't turn it off 
> right now.  There is a separate report that needs to be sent to turn off 
> the spring effect for each axis.  I can't see an obvious place to put 
> that kind of functionality into the framework of ff-memless.  I'm 
> wondering if this means my device isn't "memoryless"?  Any advice?

For the FF_RUMBLE and FF_CONSTANT effects, if I remember correctly, 
ff-memless sends a zero-magnitude effect to the device driver when the 
effect is supposed to be turned off. You can do it similarly for the 
spring effect.

-- 
Anssi Hannula

Re: Logitech Spring FF (effect on/off)

[johann deneux]

On the subject of the protocole used by Logitech devices for
force-feedback, here is some information that could be interesting:

http://vdrift.net/Forum/viewtopic.php?t=412&postdays=0&postorder=asc&start=60

The user named "anrp" has found information that I suspect is not
limited to the G25.

On 4/11/07, Richard Bolkey <rbolkey@cs.utexas.edu> wrote:
> Alright, I can turn the spring effect on; however, I can't turn it off
> right now.  There is a separate report that needs to be sent to turn off
> the spring effect for each axis.  I can't see an obvious place to put
> that kind of functionality into the framework of ff-memless.  I'm
> wondering if this means my device isn't "memoryless"?  Any advice?
>

Re: Logitech Spring FF

[Jiri Kosina]

On Tue, 10 Apr 2007, Richard Bolkey wrote:

> First off, I've never made a patch before, which I guess I better learn, but
> for now if anyone wants to add the device_type for the Logitech Force 3D Pro
> Joystick to hid-lgff.c, it's { 0x046d, 0xc286, ff_joystick }.

Queued support for 0x046d/0xc286 in my tree for upstream. Thanks.

> 1) I'm gathering that Logitech keeps their hid reports secret and 
>    non-standard, or else I'd just be using the HID PID driver?  So, were 
>    the values in the reports found in hid_lgff_play discovered through 
>    trial and error?  How would I find what the report for FF_SPRING 
>    should look like?

You can monitor how other already existing drivers behave, and try to 
simulate the behavior in your driver.

-- 
Jiri Kosina