> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
