linux-kernel - Re: [PATCH RESEND] LEDS-One-Shot-Timer-Trigger-implementation

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]

Date:	Mon, 9 Apr 2012 09:42:19 +1000
From:	NeilBrown <neilb@...e.de>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Shuah Khan <shuahkhan@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	rpurdie@...ux.intel.com, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND] LEDS-One-Shot-Timer-Trigger-implementation

On Sat, 7 Apr 2012 14:56:41 -0700 Dmitry Torokhov <dmitry.torokhov@...il.com>
wrote:

> Hi Shuah,
> 
> On Sat, Apr 07, 2012 at 08:13:44AM -0600, Shuah Khan wrote:
> > 
> > > > +This feature will help implement vibrate functionality which requires one
> > > > +time activation of vibrate mode without a continuous vibrate on/off cycles.
> > > 
> > > They make vibrating LED? ;)
> > > 
> > > What's going on here?  You're proposing to repurpose the LEDs code to
> > > drive vibration devices?  Or some devices couple a LED with a vibration
> > > device?
> > 
> > I owe you filling in the blanks type explanation. Let me describe the
> > use-case I am trying to address first. Vibrater function on phones is
> > implemented using PWM pins on SoC or PMIC. When there is no such
> > hardware present, a software solution is needed. Currently two drivers
> > timed-gpio and timed-output (under staging/android in Linux 3.3)
> > together implement the software vibrate feature. The main functionality
> > it implements is the one time enables of timer to prevent user space
> > crashes leaving the phone in vibrate mode causing the battery to drain.
> > leds as it is implemented currently, is not suitable to address this
> > use-case as it doesn't support one time enables.
> 
> So why do not you use memoryless force feedback framework that other
> devices use (see drivers/input/misc/*vibra.c drivers).
> 
> Thanks.
> 

I don't see that using a "force feedback" "input" device to control a
vibrator - which is neither "force feedback" nor "input", makes any more
sense than using an "led" device to control something that isn't an LED.
So we are even there.

I think driving leds by writing to sysfs files is lot easier (for scripting
languages particularly) than the ioctls or binary writes needed for managing
input devices.

Of course, if the 'input' framework were used for controlling all LEDs -
rather than just the LEDs on keyboard - then it might make sense...

Also, I don't think 'ff' allows for "vibrate for N milliseconds".
It appears that one uses the "rumble" effect and have to say "turn it on",
then "turn it off".  Is that correct?
I found 'struct ff_replay' which has a 'length' which is a duration, but it
doesn't seem to be used.

How would you tell the force feedback framework to play the vibrator for
120ms, then stop?

Thanks,
NeilBrown

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