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]
Date:   Sat, 16 Sep 2017 14:59:58 +0200
From:   Pavel Machek <>
To:     Jacek Anaszewski <>
Cc:     Dmitry Torokhov <>,
        "" <>,
        David Lin <>,
        Jonathan Corbet <>,
        Richard Purdie <>,
        Hans de Goede <>,
        Greg Kroah-Hartman <>,
        Rob Herring <>,
        Rom Lemarchand <>,
        "" <>,
        lkml <>,
        "" <>
Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:
 ledtrig-transient: add support for hrtimer


> >> If we want to have discussion "how to make vibrations in input
> >> easier to use", well that's fair. But I don't think it is particulary hard.
> >>
> > 
> > I would like to know more about why you find the FF interface hard,
> led-transient trigger can be activated using only following bash
> commands:
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ]; do echo 1 > activate; sleep 3; done
> Could you share sample sequence of commands to use ff driver?

Well, LED transient trigger can be activated like that. But that will
not work on any hardware currently supported by the mainline kernel.

Equivalent command with forcefeedback is:

(echo 5; sleep 1; echo -1) | sudo fftest /dev/input/event2

You would not want to use either in production.

> >> But having half devices use one interface and half use different one
> >> is just bad...
> > 
> > Completely agree here. I just merged PWM vibra driver from Sebastian
> > Reichel, we already had regulator-haptic driver, do we need gpio-based
> > one? Or make regulator-based one working with fixed regulators?
> Just to clarify: the background of this discussion is the question
> whether we should remove the following lines from
> Documentation/leds/ledtrig-transient.txt:
> -As a specific example of this use-case, let's look at vibrate feature on
> -phones. Vibrate function on phones is implemented using PWM pins on SoC or
> -PMIC. There is a need to activate one shot timer to control the vibrate
> -feature, to prevent user space crashes leaving the phone in vibrate mode
> -permanently causing the battery to drain.
> whether we should remove the following use case example from
> In effect Pavel has objections to increasing ledtrig-transient
> interval accuracy by adding hr_timer support to it, because vibrate
> devices, as one of the use cases, can benefit from it.
> So there are two issues:
> 1. Addition of hr_timer support to LED trigger.
> 2. Removal of vibrate devices use case from ledtrig-transient doc.
> I am in favour of 1. and against 2. since we're not gaining anything
> by hiding information about some kernel functionality when it will
> still be there. It also doesn't define the location of any vibrate
> device drivers, since sheer leds-gpio driver can be used for that
> purpose.

I would like to see reasonable explanation why we want 1. (and
vibrations are not that) and certainly 2. because we don't want people
to use LED subsystem for vibrations.

We already have perfectly good interface for that.
(cesky, pictures)

Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)

Powered by blists - more mailing lists