Michal Thanks for the feedback On 07/29/2014 07:09 AM, Michal Malý wrote: > 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. Actually there is one other mode here, that is the ability to program in a waveform to be played. So that makes 3 modes I have to think about supporting. I know there are products out there that would like to and do customize their feedback based on certain user actions. For the custom mode I could use the FF_CUSTOM id but not sure how that fits into the Periodic structure. If I can get two out of 3 that would be great. > > 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. How far are you on finishing the project? If it is only a little bit out I can just keep with the memless RTP mode as a start and then implement the other functions once the solution is accepted. Dan > > If there is anybody interested in such a solution I can probably whip up a > patch for it quite quickly. > > Regards, > Michal > -- ------------------ Dan Murphy -- 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