All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Pavel Machek <pavel@ucw.cz>, linux-input@vger.kernel.org
Cc: David Lin <dtwlin@google.com>,
	corbet@lwn.net, rpurdie@rpsys.net, hdegoede@redhat.com,
	gregkh@linuxfoundation.org, robh@kernel.org, romlem@google.com,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-leds@vger.kernel.org
Subject: Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer
Date: Fri, 15 Sep 2017 23:55:37 +0200	[thread overview]
Message-ID: <ef3472a0-1e70-e64f-fe11-7fdfd768fc85@gmail.com> (raw)
In-Reply-To: <20170914205804.GA24339@amd>

On 09/14/2017 10:58 PM, Pavel Machek wrote:
> On Thu 2017-09-14 21:31:31, Jacek Anaszewski wrote:
>> Hi David and Pavel,
>>
>> On 09/13/2017 10:20 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>> These patch series add the LED_BRIGHTNESS_FAST flag support for
>>>> ledtrig-transient to use hrtimer so that platforms with high-resolution timer
>>>> support can have better accuracy in the trigger duration timing. The need for
>>>> this support is driven by the fact that Android has removed the timed_ouput [1]
>>>> and is now using led-trigger for handling vibrator control which requires the
>>>> timer to be accurate up to a millisecond. However, this flag support would also
>>>> allow hrtimer to co-exist with the ktimer without causing warning to the
>>>> existing drivers [2].
>>>
>>> NAK.
>>>
>>> LEDs do not need extra overhead, and vibrator control should not go
>>> through LED subsystem.
>>>
>>> Input subsystem includes support for vibrations and force
>>> feedback. Please use that instead.
>>
>> I think that most vital criterion here is the usability of the
>> interface. If it can be harnessed for doing the work seemingly
>> unrelated to the primary subsystem's purpose, that's fine.
>> Moreover, it is extremely easy to use in comparison to the force
>> feedback one.
> 
> Well, no.
> 
> Kernel is supposed to provide hardware abstraction, that means it
> should hide differences between different devices.
> 
> And we already have devices using input as designed. We don't want to
> have situation where "on phones A, D and E, vibrations are handled via
> input, while on B, C and F, they are handled via /sys/class/leds".
> 
> 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.
> 
> If we want to say "lets move all vibrations from input to LED
> subsystem"... I don't think that is good idea, but its a valid
> discussion. Some good reasons would be needed.
> 
> But having half devices use one interface and half use different one
> is just bad... especially when only reason to do it that way is
> "David wants to do it that way, android library made a mistake and he
> now wants it to propagate to whole world".

This is not the only reason. Adding hr_timer support to
ledtrig-transient (and similarly to ledtrig-timer) would allow
to increase the accuracy and stability of delay_on/delay_off
intervals at low values.

Do you think such an improvement could be harmful in some way,
even if it was made optional?

-- 
Best regards,
Jacek Anaszewski

  parent reply	other threads:[~2017-09-15 21:56 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin
2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin
2017-09-14 19:43   ` Jacek Anaszewski
2017-09-13 17:53 ` [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin
2017-09-13 17:54 ` [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin
2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek
2017-09-13 21:20   ` David Lin
2017-09-13 21:34     ` Pavel Machek
2017-09-14 17:31       ` David Lin
2017-09-14 19:42         ` Pavel Machek
2017-09-14 19:31   ` Jacek Anaszewski
2017-09-14 19:38     ` David Lin
2017-09-14 20:03       ` Jacek Anaszewski
2017-09-14 20:58     ` Vibrations in input vs. LED was " Pavel Machek
2017-09-15 18:34       ` Dmitry Torokhov
2017-09-15 21:55         ` Jacek Anaszewski
2017-09-15 22:30           ` Dmitry Torokhov
2017-09-17 16:41             ` Jacek Anaszewski
2017-09-17 18:22               ` Pavel Machek
2017-09-17 21:15                 ` Pavel Machek
2017-09-18 20:50                 ` Jacek Anaszewski
2017-09-18 22:29                   ` Dmitry Torokhov
2017-09-19 20:45                     ` Jacek Anaszewski
2017-09-19 21:07                       ` Dmitry Torokhov
2017-09-20 19:31                         ` Jacek Anaszewski
2017-09-20 11:29                       ` Pavel Machek
2017-09-20 20:08                         ` Jacek Anaszewski
2017-10-06 11:48                           ` Pavel Machek
2017-10-06 20:57                             ` Jacek Anaszewski
2017-09-20 11:26                   ` Pavel Machek
2017-09-28  5:03             ` David Lin
2017-09-28  5:43               ` Dmitry Torokhov
2017-09-28 19:22                 ` David Lin
2017-10-05  0:40                   ` Dmitry Torokhov
2017-09-16 12:59           ` Pavel Machek
2017-09-15 21:55       ` Jacek Anaszewski [this message]
2017-09-16  1:58         ` Pavel Machek
2017-09-17 16:41           ` Jacek Anaszewski
2017-09-17 17:50             ` Pavel Machek
2017-09-18 20:43               ` Jacek Anaszewski
2017-09-20 11:15                 ` Pavel Machek
2017-09-20 18:44                   ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef3472a0-1e70-e64f-fe11-7fdfd768fc85@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dtwlin@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=robh@kernel.org \
    --cc=romlem@google.com \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.