On Tuesday 20 of May 2014 11:32:14 Roland Bosa wrote:

On 05/20/2014 02:27 AM, Michal Malý wrote:

quoted

On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:

quoted

On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Malý wrote:

quoted

Hi Dmitry,

thank you for reviewing this.

On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:

quoted

On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:

quoted

+
+/** DEFINITION OF TERMS
+ *
+ * Combined effect - An effect whose force is a superposition of
forces
+ *                   generated by all effects that can be added
together.
+ *                   Only one combined effect can be playing at a
time.
+ *                   Effects that can be added together to create a
combined + *                   effect are FF_CONSTANT, FF_PERIODIC and
FF_RAMP. + * Uncombinable effect - An effect that cannot be combined
with
another effect. + *                       All conditional effects -
FF_DAMPER, FF_FRICTION, + *                       FF_INERTIA and
FF_SPRING are uncombinable. + *                       Number of
uncombinable effects playing simultaneously + *
depends on the capabilities of the hardware. + * Rumble effect - An
effect generated by device's rumble motors instead of + *
force feedback actuators.
+ *
+ *
+ * HANDLING OF UNCOMBINABLE EFFECTS
+ *
+ * Uncombinable effects cannot be combined together into just one
effect,
at + * least not in a clear and obvious manner. Therefore these
effects
have to + * be handled individually by ff-memless-next. Handling of
these
effects is + * left entirely to the hardware-specific driver,
ff-memless-next merely + * passes these effects to the
hardware-specific
driver at appropriate time. + * ff-memless-next provides the UPLOAD
command to notify the hardware-specific + * driver that the userspace
is
about to request playback of an uncombinable + * effect. The
hardware-specific driver shall take all steps needed to make + * the
device ready to play the effect when it receives the UPLOAD command. +
*
The actual playback shall commence when START_UNCOMB command is
received.
+ * Opposite to the UPLOAD command is the ERASE command which tells +
*
the hardware-specific driver that the playback has finished and that +
*
the effect will not be restarted. STOP_UNCOMB command tells
+ * the hardware-specific driver that the playback shall stop but the
device + * shall still be ready to resume the playback immediately.
+ *
+ * In case it is not possible to make the device ready to play an
uncombinable + * effect (all hardware effect slots are occupied), the
hardware-specific + * driver may return an error when it receives an
UPLOAD command. If the

This part concerns me. It seems to me that devices supporting
"uncombinable" effects are in fact not memoryless devices and we should
not be introducing this term here. If the goal is to work around
limited
number of effect slots in the devices by combining certain effects then
it needs to be done at ff-core level as it will be potentially useful
for all devices.

Force generated by a conditional effect (referred to as "uncombinable"
within ff-memless-next to make the distinction clear) depends on a
position of the device. For instance the more a device is deflected from
a neutral position the greater force FF_SPRING generates. A truly
memoryless device would have to report its position to the driver, have
it calculate the appropriate force and send it back to the device. IMHO
such a loop would require a very high USB polling rate to play
conditional effects with acceptable quality.

We know for a fact that at least many (all?) Logitech devices that
support
conditional effects use this "semi-memoryless" approach where
FF_CONSTANT
and FF_PERIODIC are handled in the memoryless fashion and conditional
effects are uploaded to the device (in a somewhat simplified form). The
amount of effects that can be uploaded to a device is limited which is
why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to
handle these effects.

Conditional effects - even if they are of the same type - cannot be
effectively combined into one because superposition doesn't seem to work
here so they have to be processed one by one.

If we ever come across a really memoryless device it should not be
particularly difficult to add another callback to ff-memless-next which
would emulate conditional effects with constant force.

Thank you for the explanation. This further solidifies for me the idea
that handling of such effects that are in fact uploaded to and managed
by the device should not be handled by the memoryless core but rather by
the driver itself. I.e. such drivers should implement their own play(),
upload(), erase(), etc, and decide whether to use a hardware slot for
the effect or handle effect in memoryless fashion (if possible). We can
open ff-memless to allow such drivers to use parts of memoryless
handling.

Thanks.

To bring this to a conclusion we could go from, would this be an
acceptable
solution?

- Have the HW-specific driver talk directly to ff-core and reimplement
upload(), play(), etc.
- Rewrite "ff-memless-next" so that it is not a self-contained module but
a
library of functions.

- Have the driver either:
  - Upload an effect to a device directly if the device can fully manage
  the

effect by itself.

  - Use provided timing functions to know when an effect should start,
  stop,

restart etc...

  - Use provided timing AND processing functions to combine effects that
  can be> 
combined into one, calculate periodic waveforms etc?

I have no problem with throwing my current approach away but before I
start
working on a new one I'd like to know which way to go...

Thanks,
Michal

Hi everyone

Allow me to introduce myself. I'm Roland Bosa and I work for Logitech,
more specifically the gaming group. I have been tasked to look into
gaming device support for Linux and I just started following this list
and studying the kernel code related to the Logitech Force Feedback
devices. The 'ff-memless-next' module sounds tailor-made for our
devices. Please let me know how I can help with its development.

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

Thanks for any help you can get us,
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html