On Monday 28 of July 2014 21:21:26 Murphy, Dan wrote: > Dmitry > > On 07/28/2014 12:59 PM, simon@xxxxxxxxxxxxx wrote: > >>> The initial driver supports the devices > >>> real time playback mode. But the device > >>> has additional wave patterns in ROM. > >> > >> As it presented the device appears to be a memoryless device, however > >> you present it to the rest of the system as if it can support playback > >> of multiple effects simultaneously, which is incorrect. > >> > >> My guess that you need to engage the memoryless input library to schedule > >> handling multiple effects for your device, including ramping up, ramping > >> down, stopping playback when effects runs out, etc. > > > > Hi Dan, > > Elias and Michal (cc'ed) are working on a kernel/userland library to > > handle sending multiple force feedback signals to 'simple' devices, > > perhaps you should engage with them. > > > > Simon Hi Dan, since I spent some time trying to improve the memoryless library I can hopefully provide you with some hints. If I'm reading this right, your device cannot play more than one effect at once but it can operate eihter in RTP mode where the user controls the operation of the motors directly on in an automated mode where the device follows some pre- programmed waveform. These two modes are mutually exclusive. If my understanding of the problem is correct, you will struggle both with memoryless library and your own imlementation. The memoryless library is quite simplistic and it doesn't have any sort of "passthrough" mode so you would not be able to do anything besides RTP that way. On the other hand if you decide to write your own implementation of effect handling you will end up duplicating a lot of code that already exists in the memoryless library and has been proven to work. A possible solution for the problem would be to separate the functions that control effect timing from the memoryless library and make them globally accessible. I believe that this would simplify any customized haptic implementation considerably and it might be a decent interim solution before the project Simon mentioned is ready. If there is anybody interested in such a solution I can probably whip up a patch for it quite quickly. Regards, Michal -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html