Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.torokhov@xxxxxxxxx> 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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux