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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPzFB+U-mCj7N2dM2HHQTCxxWeEBT4zpQ3zc_H6y1mmQFwqB_w@mail.gmail.com>
Date:   Thu, 28 Sep 2017 12:22:13 -0700
From:   David Lin <dtwlin@...gle.com>
To:     Dmitry Torokhov <dmitry.torokhov@...il.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 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]