[lkml]   [2017]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Documentation: small fixes for LEDs, hide notes about vibration
On Tue, 29 Aug 2017, Pavel Machek <> wrote:
> Hi!
>> > -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.
>> I'm not sure if it is a good idea to remove this description. Users will
>> still be able to use transient trigger this way. It has been around for
>> five years already and there are users which employ it in this
>> particular way [0].
> I am. Yes, people were doing that, but no, vibration motor is not a
> LED. PWM behaviour is different, for example, motor is likely to stop
> at low PWM values. We do not want people to do that.
>> Apart from that it's the only documented kernel API for vibrate devices
> Input subsystem has force-feedback protocol, which is very often just
> vibrations. Documentation/input/ff.rst . Nokia N900 phone actually
> uses that API.

N900 as shipped by Nokia used an ad hoc sysfs interface. Because that
sucked, I advocated using the force feedback API for N950 and
N9. Because what is vibration but force feedback? It's a much more
versatile API for vibration than a simple trigger. You get to upload
effects and have the kernel play them for you, also stopping them in a
timely manner regardless of the userspace dying and whatnot. I didn't
double check now, but IIRC you could also link the input to force
feedback, e.g. for touch vibrations.


Jani Nikula, Intel Open Source Technology Center

 \ /
  Last update: 2017-08-31 09:53    [W:0.041 / U:1.604 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site