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

Hi all,
If the driver itself (hid-logitech, via hid-lg4ff for example) is more
involved in the creation/timing/management of the effects, does this mean
that we end up with code duplicated in lots of places?

Also, does this mean that the 'old' ff-memless system would remain in
kernel? If not, who will reworking each driver?



Regarding the question of emulated vs. real effects, can we extend the API
so that applications can know which effects are really supported, and
enable/disable emulation somehow?

Apologies for asking some many questions, without answering anything...
Simon