On Thu, Sep 28, 2017 at 12:22:13PM -0700, David Lin wrote: > On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov > <dmitry.torok...@gmail.com> wrote: > >>One thing I noticed is that input_ff_create_memless() also does not > >>use high-resolution timer hence it also does not have the stop-time > >>precision that I'm looking for. > > > > I'll take patches for high resolution timers in ff memless, they should > > also help with more accurate scheduling of ramping up and fading of events. > > Thanks. > > > > >> > >>Another thing is that ff_reply duration value is maxed-out at 32767 ms > >>(u16) while the Android/userspace requires size long for performing > >>long notification alert. > >> > > > > You need unattended vibrations lasting longer than 30 seconds? Anyway, > > replay.length == 0 means endless IIRC, so you only need to schedule > > stopping. We still will clean up properly if your process crashes or exits > > or closes the fd. > > Yes, it's up to the application to vibrate for as long as it requires. > Is there any concern making the duration variable a type long? [If > this is getting off-topic, I'll follow up with another email]
Yes, given ABI constraints that is not really feasible. I think for effects longer than 30 seconds you'd have to handle it in the framework by using replay.length 0 and cancelling the effect some time later. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
