Re: [PATCH v4 01/24] input: Add ff-memless-next module

[Roland Bosa]

On 05/20/2014 12:00 PM, Michal Malý wrote:
> Hi,
> 
> "ff-memless-next" was designed with behavior of Logitech devices in mind, 
> however it was always meant as a general replacement for the current "ff-
> memless". After some followup discussion it's unlikely that it will be 
> mainlined in its current form. See the discussion here 
> "http://www.spinics.net/lists/linux-input/msg31426.html"; for more details.
> 
> We would however really appreciate some information regarding Logitech devices 
> specifically. Although we have reverse engineered most of things, I believe 
> there are still areas we're not entirely clear about. I realize that you'd 
> probably have to take it up with the legal deparment but if someone at 
> Logitech could at least take a look at what we've found so far at fill in the 
> blanks it'd be most helpful.

I'm your guy, then. Please send any questions my way and I'll dig out
the information you need - with the lawyer's blessings, if need be.

> Please note that we found numerous bugs and DirectInput specs violations in 
> the Windows driver which might have impacted our understading of how the 
> driver works. "ff-memless-next" and "lg4ff" tries to fix or work around these. A 
> link to out-of-tree update to lg4ff which takes full advantage of "ff-memless-
> next" is also provided in this thread.

lg4ff is mostly wheels, from what I saw. We should be able to fold in
the G940 (Flight System) as well as other joysticks into the same
driver. The underlying model driving the forces of our devices is
essentially the same, there are just slight improvements made over the
years to accommodate higher resolutions and more powerful micro processors.

Each device has a unique number (say 2 or 4) of force 'slots' per axis,
which is running a force calculation in firmware. Typically, one of
these slots is allocated by the host driver for a constant force, that's
streamed to the device (and comprises all constant and periodic forces
sent by the 'game' - that's the combined type of your code, as far as I
can tell). The other slot may be used for position-based effects
(springs, centering spring) as well as velocity-based effects (dampers,
friction) - that's the un-combinable type. There's a healthy amount of
code in the Windows driver that you would call 'quirks' which deals with
deciding how to allocate multiple springs and dampers to a single slot.
Sometimes, even the springs and dampers are being streamed in via the
constants force, but that requires (as you pointed out earlier) a fast
update rate and some "smartness" (I'm getting in hot territory with the
lawyers now - let me stop).

One of the key features of the design is the decoupling of the USB
updates from the force feedback IOCTL's from the 'game'. I don't think
this is currently the case with today's drivers. I was able to send
force updates to a gamepad faster than the USB update rate, which led to
some lost packets which in turn left the device in a inconsistent state
- the motors were still rumbling although they should have stopped. If
the 'ff-memless-next' driver offers this decoupling, it is a step in the
right direction, IMO.

I will try to apply the patch mentioned in this thread and see where it
leads me...

Thanks
roland

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/