[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a17f76a4-9c9b-6154-6b5e-d30fd499efa7@gmail.com>
Date: Mon, 18 Sep 2017 22:43:40 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: linux-input@...r.kernel.org, David Lin <dtwlin@...gle.com>,
corbet@....net, rpurdie@...ys.net, hdegoede@...hat.com,
gregkh@...uxfoundation.org, robh@...nel.org, romlem@...gle.com,
linux-doc@...r.kernel.org, linux-kernel@...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
Hi,
On 09/17/2017 07:50 PM, Pavel Machek wrote:
> Hi!
>
>>>> 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?
>
> Pavel
> (*) emulating PWM using blink trigger counts as "crazy" :-)
How about adding CONFIG_LED_TRIGGERS_HR_TIMER_SUPPORT, guarding the
hr timer support in triggers (timer trigger could also benefit from it)
with it, and adding "(EXPERIMENTAL)" tag to the config description?
--
Best regards,
Jacek Anaszewski
Powered by blists - more mailing lists