lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 Oct 2017 17:40:45 -0700 From: Dmitry Torokhov <dmitry.torokhov@...il.com> To: David Lin <dtwlin@...gle.com> Cc: Jacek Anaszewski <jacek.anaszewski@...il.com>, Pavel Machek <pavel@....cz>, "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>, Jonathan Corbet <corbet@....net>, Richard Purdie <rpurdie@...ys.net>, Hans de Goede <hdegoede@...hat.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Rob Herring <robh@...nel.org>, Rom Lemarchand <romlem@...gle.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, lkml <linux-kernel@...r.kernel.org>, "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org> Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 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@...il.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
Powered by blists - more mailing lists