Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1731753 > unrolled thread

[PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
    [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin <dtwlin@google.com> - 2017-09-13 20:00 +0200
      Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 21:50 +0200
    Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-13 22:30 +0200
      Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-13 23:30 +0200
        Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-13 23:40 +0200
          Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-14 19:40 +0200
            Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-14 21:50 +0200
      Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 21:40 +0200
        Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin <dtwlin@google.com> - 2017-09-14 21:40 +0200
          Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-14 22:10 +0200
        Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-14 23:00 +0200
          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-15 20:40 +0200
            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-16 00:00 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-16 00:40 +0200
                Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-17 18:50 +0200
                  Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 20:30 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 23:20 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-18 23:00 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-19 00:30 +0200
                        Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-19 22:50 +0200
                          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-09-19 23:10 +0200
                            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 21:40 +0200
                          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:30 +0200
                            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 22:10 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:30 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-16 15:10 +0200
          Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-16 00:00 +0200
            Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-16 14:40 +0200
              Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-17 18:50 +0200
                Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-17 20:00 +0200
                  Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-18 22:50 +0200
                    Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Pavel Machek <pavel@ucw.cz> - 2017-09-20 13:20 +0200
                      Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led:  ledtrig-transient: add support for hrtimer Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-09-20 20:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1734477 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi,

On 09/17/2017 08:22 PM, Pavel Machek wrote:
> Hi!
> 
>>> If your objection is that FF is not easily engaged from the shell -
>>> yes, but I do not think that actual users who want to do vibration do
>>> that via shell either. On the other hand, can you drop privileges and
>>> still allow a certain process control your vibrator via LED interface?
>>> With FF you can pass an FD to whoever you deem worthy and later revoke
>>> access.
>>>
>>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>>> use them in real frameworks, where you need to think about proper
>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>>> better.
>>
>> I'd leave the decision to the user. We could add a note to the
>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>> should be preferable choice for driving vibrate devices.
> 
> We don't want to leave decision to the user; because then we'll end up
> with userland applications having to support _both_ interfaces.

This state has lasted for five years now. I don't recall any
complaints. Do you?

> Plus, it is not really your decision. Dmitry is maintainer of input
> subsystem, input was doing force feedback for 10+ years, and he
> already made a decision.

It seems that you applied a fait accompli method here.

Actually could you share what the decision is? AFAIK we're not
discussing here any patch for the input subsystem?

>> However only if following conditions are met:
>> - force feedback driver supports gpio driven devices
>> - there is sample application in tools/input showing how to
>>   setup gpio driven vibrate device with use of ff interface
>> - it will be possible to setup vibrate interval with 1ms accuracy,
>>   similarly to what the discussed patch allows to do
> 
> I agree these would be nice. Interested parties are welcome to help
> there. But I don't think this should have any impact on LED
> susbystem. Force feedback just does not belong to LED subsystem.

You cut off important piece of my text from the beginning of this
paragraph. It was:

> I'd leave the decision to the user. We could add a note to the
> Documentation/leds/ledtrig-transient.txt that force feedback interface
> should be preferable choice for driving vibrate devices.
> However only if following conditions are met:

What I meant is that it is my decision, as a LED subsystem maintainer,
to accept the addition of a note about some other subsystem offering
an equivalent or even better substitute of the feature being available
in the subsystem I am responsible for. And I will accept such a patch
only if mentioned conditions are met.

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1734519 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
> Hi,
>
> On 09/17/2017 08:22 PM, Pavel Machek wrote:
>> Hi!
>>
>>>> If your objection is that FF is not easily engaged from the shell -
>>>> yes, but I do not think that actual users who want to do vibration do
>>>> that via shell either. On the other hand, can you drop privileges and
>>>> still allow a certain process control your vibrator via LED interface?
>>>> With FF you can pass an FD to whoever you deem worthy and later revoke
>>>> access.
>>>>
>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>>>> use them in real frameworks, where you need to think about proper
>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>>>> better.
>>>
>>> I'd leave the decision to the user. We could add a note to the
>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>> should be preferable choice for driving vibrate devices.
>>
>> We don't want to leave decision to the user; because then we'll end up
>> with userland applications having to support _both_ interfaces.
>
> This state has lasted for five years now. I don't recall any
> complaints. Do you?

I was telling Shuah 5 years ago that using LED for what she wanted was
not the right idea. I even made a patch for her implementing the
functionality they were after: https://lkml.org/lkml/2012/4/10/41

Unfortunately this still somehow made it into the kernel. I guess the
angle of having LEDs auto-shutoff makes sense still; using it for
haptics does not.

>
>> Plus, it is not really your decision. Dmitry is maintainer of input
>> subsystem, input was doing force feedback for 10+ years, and he
>> already made a decision.
>
> It seems that you applied a fait accompli method here.
>
> Actually could you share what the decision is? AFAIK we're not
> discussing here any patch for the input subsystem?

No, we are discussing if it makes sense encouraging 2nd interface for
haptic. We are also discussing whether it makes sense to implement new
features in LED subsystem that seem to be only beneficial for this
interface (I assume the "normal" LEDs do not need that kind of
precision?).

>
>>> However only if following conditions are met:
>>> - force feedback driver supports gpio driven devices
>>> - there is sample application in tools/input showing how to
>>>   setup gpio driven vibrate device with use of ff interface
>>> - it will be possible to setup vibrate interval with 1ms accuracy,
>>>   similarly to what the discussed patch allows to do
>>
>> I agree these would be nice. Interested parties are welcome to help
>> there. But I don't think this should have any impact on LED
>> susbystem. Force feedback just does not belong to LED subsystem.
>
> You cut off important piece of my text from the beginning of this
> paragraph. It was:
>
>> I'd leave the decision to the user. We could add a note to the
>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>> should be preferable choice for driving vibrate devices.
>> However only if following conditions are met:
>
> What I meant is that it is my decision, as a LED subsystem maintainer,
> to accept the addition of a note about some other subsystem offering
> an equivalent or even better substitute of the feature being available
> in the subsystem I am responsible for. And I will accept such a patch
> only if mentioned conditions are met.

Having the wording in documentation does not in any way stops Android
folks from continuing [ab]using the transient trigger. But this is
their choice. The purpose of documentation is to document the best
practices, not all possible crazy solutions one can come up with.

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1735249 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On 09/19/2017 12:29 AM, Dmitry Torokhov wrote:
> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>> Hi,
>>
>> On 09/17/2017 08:22 PM, Pavel Machek wrote:
>>> Hi!
>>>
>>>>> If your objection is that FF is not easily engaged from the shell -
>>>>> yes, but I do not think that actual users who want to do vibration do
>>>>> that via shell either. On the other hand, can you drop privileges and
>>>>> still allow a certain process control your vibrator via LED interface?
>>>>> With FF you can pass an FD to whoever you deem worthy and later revoke
>>>>> access.
>>>>>
>>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>>>>> use them in real frameworks, where you need to think about proper
>>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>>>>> better.
>>>>
>>>> I'd leave the decision to the user. We could add a note to the
>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>>> should be preferable choice for driving vibrate devices.
>>>
>>> We don't want to leave decision to the user; because then we'll end up
>>> with userland applications having to support _both_ interfaces.
>>
>> This state has lasted for five years now. I don't recall any
>> complaints. Do you?
> 
> I was telling Shuah 5 years ago that using LED for what she wanted was
> not the right idea. I even made a patch for her implementing the
> functionality they were after: https://lkml.org/lkml/2012/4/10/41
> 
> Unfortunately this still somehow made it into the kernel. I guess the
> angle of having LEDs auto-shutoff makes sense still; using it for
> haptics does not.

Thanks for the pointer.

>>
>>> Plus, it is not really your decision. Dmitry is maintainer of input
>>> subsystem, input was doing force feedback for 10+ years, and he
>>> already made a decision.
>>
>> It seems that you applied a fait accompli method here.
>>
>> Actually could you share what the decision is? AFAIK we're not
>> discussing here any patch for the input subsystem?
> 
> No, we are discussing if it makes sense encouraging 2nd interface for
> haptic. We are also discussing whether it makes sense to implement new
> features in LED subsystem that seem to be only beneficial for this
> interface (I assume the "normal" LEDs do not need that kind of
> precision?).

As you noticed in one of the previous messages, thanks to the leds-gpio
driver we can drive a wide range of devices from the level of
LED subsystem. LED trigger mechanism makes it even more versatile,
and, in this area, even somehow akin to the GPIO subsystem. In the
future we could think of making this trigger mechanism accessible by
the two and thus any initiative aiming at enhancing it shouldn't be
discouraged.

>>>> However only if following conditions are met:
>>>> - force feedback driver supports gpio driven devices
>>>> - there is sample application in tools/input showing how to
>>>>   setup gpio driven vibrate device with use of ff interface
>>>> - it will be possible to setup vibrate interval with 1ms accuracy,
>>>>   similarly to what the discussed patch allows to do
>>>
>>> I agree these would be nice. Interested parties are welcome to help
>>> there. But I don't think this should have any impact on LED
>>> susbystem. Force feedback just does not belong to LED subsystem.
>>
>> You cut off important piece of my text from the beginning of this
>> paragraph. It was:
>>
>>> I'd leave the decision to the user. We could add a note to the
>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>> should be preferable choice for driving vibrate devices.
>>> However only if following conditions are met:
>>
>> What I meant is that it is my decision, as a LED subsystem maintainer,
>> to accept the addition of a note about some other subsystem offering
>> an equivalent or even better substitute of the feature being available
>> in the subsystem I am responsible for. And I will accept such a patch
>> only if mentioned conditions are met.
> 
> Having the wording in documentation does not in any way stops Android
> folks from continuing [ab]using the transient trigger. But this is
> their choice. The purpose of documentation is to document the best
> practices, not all possible crazy solutions one can come up with.

Yes. but if the information has been in place for years, we can't
just remove it without giving an instruction on how to use the
substitute.

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1735265 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On Tue, Sep 19, 2017 at 1:45 PM, Jacek Anaszewski
<jacek.anaszewski@gmail.com> wrote:
> On 09/19/2017 12:29 AM, Dmitry Torokhov wrote:
>> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
>> <jacek.anaszewski@gmail.com> wrote:
>>> Hi,
>>>
>>> On 09/17/2017 08:22 PM, Pavel Machek wrote:
>>>> Hi!
>>>>
>>>>>> If your objection is that FF is not easily engaged from the shell -
>>>>>> yes, but I do not think that actual users who want to do vibration do
>>>>>> that via shell either. On the other hand, can you drop privileges and
>>>>>> still allow a certain process control your vibrator via LED interface?
>>>>>> With FF you can pass an FD to whoever you deem worthy and later revoke
>>>>>> access.
>>>>>>
>>>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>>>>>> use them in real frameworks, where you need to think about proper
>>>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>>>>>> better.
>>>>>
>>>>> I'd leave the decision to the user. We could add a note to the
>>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>>>> should be preferable choice for driving vibrate devices.
>>>>
>>>> We don't want to leave decision to the user; because then we'll end up
>>>> with userland applications having to support _both_ interfaces.
>>>
>>> This state has lasted for five years now. I don't recall any
>>> complaints. Do you?
>>
>> I was telling Shuah 5 years ago that using LED for what she wanted was
>> not the right idea. I even made a patch for her implementing the
>> functionality they were after: https://lkml.org/lkml/2012/4/10/41
>>
>> Unfortunately this still somehow made it into the kernel. I guess the
>> angle of having LEDs auto-shutoff makes sense still; using it for
>> haptics does not.
>
> Thanks for the pointer.
>
>>>
>>>> Plus, it is not really your decision. Dmitry is maintainer of input
>>>> subsystem, input was doing force feedback for 10+ years, and he
>>>> already made a decision.
>>>
>>> It seems that you applied a fait accompli method here.
>>>
>>> Actually could you share what the decision is? AFAIK we're not
>>> discussing here any patch for the input subsystem?
>>
>> No, we are discussing if it makes sense encouraging 2nd interface for
>> haptic. We are also discussing whether it makes sense to implement new
>> features in LED subsystem that seem to be only beneficial for this
>> interface (I assume the "normal" LEDs do not need that kind of
>> precision?).
>
> As you noticed in one of the previous messages, thanks to the leds-gpio
> driver we can drive a wide range of devices from the level of
> LED subsystem.

Yes, you can create whatever. It goes normally as this: crap, we need
to ship something really soon, factory build is a week from now and we
have absolutely no time to think about proper interface. Hey, let's
quickly bolt on some quirk on an unrelated interface, it almost does
what we want. We do not care that out use case does not really fit
here, our custom one-off userspace will know how to deal with it.

> LED trigger mechanism makes it even more versatile,
> and, in this area, even somehow akin to the GPIO subsystem. In the
> future we could think of making this trigger mechanism accessible by
> the two and thus any initiative aiming at enhancing it shouldn't be
> discouraged.

If there is a use case that would benefit from this functionality:
certainly. Do you have one in mind?

Thanks.

-- 
Dmitry

[toc] | [prev] | [next] | [standalone]

#1736043 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On 09/19/2017 11:07 PM, Dmitry Torokhov wrote:
> On Tue, Sep 19, 2017 at 1:45 PM, Jacek Anaszewski
> <jacek.anaszewski@gmail.com> wrote:
>> On 09/19/2017 12:29 AM, Dmitry Torokhov wrote:
>>> On Mon, Sep 18, 2017 at 1:50 PM, Jacek Anaszewski
>>> <jacek.anaszewski@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> On 09/17/2017 08:22 PM, Pavel Machek wrote:
>>>>> Hi!
>>>>>
>>>>>>> If your objection is that FF is not easily engaged from the shell -
>>>>>>> yes, but I do not think that actual users who want to do vibration do
>>>>>>> that via shell either. On the other hand, can you drop privileges and
>>>>>>> still allow a certain process control your vibrator via LED interface?
>>>>>>> With FF you can pass an FD to whoever you deem worthy and later revoke
>>>>>>> access.
>>>>>>>
>>>>>>> IOW sysfs interfaces are nice for quick hacks, but when you want to
>>>>>>> use them in real frameworks, where you need to think about proper
>>>>>>> namespaces, isolation, etc, etc, other kinds of interfaces might suit
>>>>>>> better.
>>>>>>
>>>>>> I'd leave the decision to the user. We could add a note to the
>>>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>>>>> should be preferable choice for driving vibrate devices.
>>>>>
>>>>> We don't want to leave decision to the user; because then we'll end up
>>>>> with userland applications having to support _both_ interfaces.
>>>>
>>>> This state has lasted for five years now. I don't recall any
>>>> complaints. Do you?
>>>
>>> I was telling Shuah 5 years ago that using LED for what she wanted was
>>> not the right idea. I even made a patch for her implementing the
>>> functionality they were after: https://lkml.org/lkml/2012/4/10/41
>>>
>>> Unfortunately this still somehow made it into the kernel. I guess the
>>> angle of having LEDs auto-shutoff makes sense still; using it for
>>> haptics does not.
>>
>> Thanks for the pointer.
>>
>>>>
>>>>> Plus, it is not really your decision. Dmitry is maintainer of input
>>>>> subsystem, input was doing force feedback for 10+ years, and he
>>>>> already made a decision.
>>>>
>>>> It seems that you applied a fait accompli method here.
>>>>
>>>> Actually could you share what the decision is? AFAIK we're not
>>>> discussing here any patch for the input subsystem?
>>>
>>> No, we are discussing if it makes sense encouraging 2nd interface for
>>> haptic. We are also discussing whether it makes sense to implement new
>>> features in LED subsystem that seem to be only beneficial for this
>>> interface (I assume the "normal" LEDs do not need that kind of
>>> precision?).
>>
>> As you noticed in one of the previous messages, thanks to the leds-gpio
>> driver we can drive a wide range of devices from the level of
>> LED subsystem.
> 
> Yes, you can create whatever. It goes normally as this: crap, we need
> to ship something really soon, factory build is a week from now and we
> have absolutely no time to think about proper interface. Hey, let's
> quickly bolt on some quirk on an unrelated interface, it almost does
> what we want. We do not care that out use case does not really fit
> here, our custom one-off userspace will know how to deal with it.
> 
>> LED trigger mechanism makes it even more versatile,
>> and, in this area, even somehow akin to the GPIO subsystem. In the
>> future we could think of making this trigger mechanism accessible by
>> the two and thus any initiative aiming at enhancing it shouldn't be
>> discouraged.
> 
> If there is a use case that would benefit from this functionality:
> certainly. Do you have one in mind?

Few minutes of googling gave below results. People are doing that
anyway so adding EXPERIMENTAL support in mainline maybe wouldn't
be such a wrong idea. It seems that there would be many testers.

[0]
https://stackoverflow.com/questions/16534668/how-to-generate-a-steady-37khz-gpio-trigger-from-inside-linux-kernel
[1]
https://discuss.96boards.org/t/generate-high-frequency-square-wave-on-a-gpio-pin/2615/4
[2]
https://stackoverflow.com/questions/4634991/how-to-generate-100khz-clock-signal-in-liunx-kernel-module-with-bit-banging
[3] http://www.friendlyarm.net/forum/topic/3566
[4] http://codeandlife.com/2016/04/18/beaglebone-black-gpio-benchmark/
[5] https://www.raspberrypi.org/forums/viewtopic.php?t=56748
-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1735728 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Multipart message — attachments visible in raw view] — view raw

> >>> I'd leave the decision to the user. We could add a note to the
> >>> Documentation/leds/ledtrig-transient.txt that force feedback interface
> >>> should be preferable choice for driving vibrate devices.
> >>> However only if following conditions are met:
> >>
> >> What I meant is that it is my decision, as a LED subsystem maintainer,
> >> to accept the addition of a note about some other subsystem offering
> >> an equivalent or even better substitute of the feature being available
> >> in the subsystem I am responsible for. And I will accept such a patch
> >> only if mentioned conditions are met.
> > 
> > Having the wording in documentation does not in any way stops Android
> > folks from continuing [ab]using the transient trigger. But this is
> > their choice. The purpose of documentation is to document the best
> > practices, not all possible crazy solutions one can come up with.
> 
> Yes. but if the information has been in place for years, we can't
> just remove it without giving an instruction on how to use the
> substitute.

I gave you information how to use the substitute.

I already suggested patch to documentation. If you do the same, maybe
we can agree on documentation update.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1736062 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

On 09/20/2017 01:29 PM, Pavel Machek wrote:
>>>>> I'd leave the decision to the user. We could add a note to the
>>>>> Documentation/leds/ledtrig-transient.txt that force feedback interface
>>>>> should be preferable choice for driving vibrate devices.
>>>>> However only if following conditions are met:
>>>>
>>>> What I meant is that it is my decision, as a LED subsystem maintainer,
>>>> to accept the addition of a note about some other subsystem offering
>>>> an equivalent or even better substitute of the feature being available
>>>> in the subsystem I am responsible for. And I will accept such a patch
>>>> only if mentioned conditions are met.
>>>
>>> Having the wording in documentation does not in any way stops Android
>>> folks from continuing [ab]using the transient trigger. But this is
>>> their choice. The purpose of documentation is to document the best
>>> practices, not all possible crazy solutions one can come up with.
>>
>> Yes. but if the information has been in place for years, we can't
>> just remove it without giving an instruction on how to use the
>> substitute.
> 
> I gave you information how to use the substitute.

That information was quite vague. I'd like to see a sample application
in tools/input.

> I already suggested patch to documentation. If you do the same, maybe
> we can agree on documentation update.

Your patch was just removing few lines of documentation. I'd expect more
empathic approach to the current users, i.e.:

- pointer to the sample application in tools/input showing how to
  setup gpio driven vibrate device with use of ff interface with
  1kHz vibration frequency.


-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1735727 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Multipart message — attachments visible in raw view] — view raw

Hi!

> >> However only if following conditions are met:
> >> - force feedback driver supports gpio driven devices
> >> - there is sample application in tools/input showing how to
> >>   setup gpio driven vibrate device with use of ff interface
> >> - it will be possible to setup vibrate interval with 1ms accuracy,
> >>   similarly to what the discussed patch allows to do
> > 
> > I agree these would be nice. Interested parties are welcome to help
> > there. But I don't think this should have any impact on LED
> > susbystem. Force feedback just does not belong to LED subsystem.
> 
> You cut off important piece of my text from the beginning of this
> paragraph. It was:
> 
> > I'd leave the decision to the user. We could add a note to the
> > Documentation/leds/ledtrig-transient.txt that force feedback interface
> > should be preferable choice for driving vibrate devices.
> > However only if following conditions are met:

And that's very bad idea.

As a user of these interfaces, I am telling you: I want _single_
kernel interface to control vibration. Not different interfaces
depending on which phone I'm running at.

> What I meant is that it is my decision, as a LED subsystem maintainer,
> to accept the addition of a note about some other subsystem offering
> an equivalent or even better substitute of the feature being available
> in the subsystem I am responsible for. And I will accept such a patch
> only if mentioned conditions are met.

If you want to improve input, please go ahead.

If you want to encourage haptic feedback to use LED subsystem, that is
not welcome.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1733278 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Multipart message — attachments visible in raw view] — view raw

Hi!

> >> 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.
> >>
> > 
> > I would like to know more about why you find the FF interface hard,
> 
> led-transient trigger can be activated using only following bash
> commands:
> 
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ]; do echo 1 > activate; sleep 3; done
> 
> Could you share sample sequence of commands to use ff driver?

Well, LED transient trigger can be activated like that. But that will
not work on any hardware currently supported by the mainline kernel.

Equivalent command with forcefeedback is:

(echo 5; sleep 1; echo -1) | sudo fftest /dev/input/event2

You would not want to use either in production.

> >> But having half devices use one interface and half use different one
> >> is just bad...
> > 
> > Completely agree here. I just merged PWM vibra driver from Sebastian
> > Reichel, we already had regulator-haptic driver, do we need gpio-based
> > one? Or make regulator-based one working with fixed regulators?
> 
> Just to clarify: the background of this discussion is the question
> whether we should remove the following lines from
> Documentation/leds/ledtrig-transient.txt:
> 
> -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.
> whether we should remove the following use case example from
> 
> In effect Pavel has objections to increasing ledtrig-transient
> interval accuracy by adding hr_timer support to it, because vibrate
> devices, as one of the use cases, can benefit from it.
> 
> So there are two issues:
> 1. Addition of hr_timer support to LED trigger.
> 2. Removal of vibrate devices use case from ledtrig-transient doc.
> 
> I am in favour of 1. and against 2. since we're not gaining anything
> by hiding information about some kernel functionality when it will
> still be there. It also doesn't define the location of any vibrate
> device drivers, since sheer leds-gpio driver can be used for that
> purpose.

I would like to see reasonable explanation why we want 1. (and
vibrations are not that) and certainly 2. because we don't want people
to use LED subsystem for vibrations.

We already have perfectly good interface for that.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1733115 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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

[toc] | [prev] | [next] | [standalone]

#1733276 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

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
...
> > 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?

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?
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1733496 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi,

On 09/16/2017 03:58 AM, 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
> ...
>>> 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?
> 
> 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

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1733510 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Multipart message — attachments visible in raw view] — view raw

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" :-)


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1734469 — 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

[toc] | [prev] | [next] | [standalone]

#1735720 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Multipart message — attachments visible in raw view] — view raw

On Mon 2017-09-18 22:43:40, Jacek Anaszewski wrote:
> 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?
> > 
> > (*) 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?

Why would we want to add code in the LED subsystem that is useless for
LEDs?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1736007 — Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

Hi,

On 09/20/2017 01:15 PM, Pavel Machek wrote:
> On Mon 2017-09-18 22:43:40, Jacek Anaszewski wrote:
>> 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?
>>>
>>> (*) 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?
> 
> Why would we want to add code in the LED subsystem that is useless for
> LEDs?

It could be used for software pwm trigger, there has been at least one
an attempt to add such [0].

[0] https://lkml.org/lkml/2015/4/27/493
-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web