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  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:   Sun, 17 Sep 2017 19:50:14 +0200
From:   Pavel Machek <>
To:     Jacek Anaszewski <>
Cc:, David Lin <>,,,,,,,,,
Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:
 ledtrig-transient: add support for hrtimer


> >> Do you think such an improvement could be harmful in some way,
> >> even if it was made optional?
> > 
> > Of course, we can make LED timing accurate down to microseconds. It will
> > mean increased overhead -- for "improvement" human can not perceive.
> > 
> > If someone has problems with LED delays not being accurate enough... we
> > may want to fix it. But that is not the case here, is it?
> AFAIR David was mentioning that the hr_timer support is perceivable

He said that hr_timer support is perceivable _when he is driving
vibration motor_. Which he should not do in the first place.

Yes, if the difference is perceivable with LED in non-crazy
configuration (*), we can take the patch. Is it? Do we have someone
not from Google observing it?

(*) emulating PWM using blink trigger counts as "crazy" :-)

(cesky, pictures)

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

Powered by blists - more mailing lists