led: ledtrig-transient: add support for hrtimer

This is for readability as well as to avoid checkpatch warnings when adding new bit flag information in the future.

Signed-off-by David Lin <[email protected]>

---
 include/linux/leds.h | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

include/linux/leds.h +2 -9

index bf6db4fe895b..5579c64c8fd6 100644
@@ -40,16 +40,16 @@ struct led_classdev {
 	int			 flags;
 
 	/* Lower 16 bits reflect status */
-#define LED_SUSPENDED		(1 << 0)
-#define LED_UNREGISTERING	(1 << 1)
+#define LED_SUSPENDED		BIT(0)
+#define LED_UNREGISTERING	BIT(1)
 	/* Upper 16 bits reflect control information */
-#define LED_CORE_SUSPENDRESUME	(1 << 16)
-#define LED_SYSFS_DISABLE	(1 << 17)
-#define LED_DEV_CAP_FLASH	(1 << 18)
-#define LED_HW_PLUGGABLE	(1 << 19)
-#define LED_PANIC_INDICATOR	(1 << 20)
-#define LED_BRIGHT_HW_CHANGED	(1 << 21)
-#define LED_RETAIN_AT_SHUTDOWN	(1 << 22)

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

David Lin (3):
leds: Replace flags bit shift with BIT() macros
leds: Add the LED_BRIGHTNESS_FAST flag
led: ledtrig-transient: add support for hrtimer

 Documentation/leds/leds-class.txt        |  5 +++
 drivers/leds/trigger/ledtrig-transient.c | 59 +++++++++++++++++++++++++++++---
 include/linux/leds.h                     | 19 +++++-----
 3 files changed, 69 insertions(+), 14 deletions(-)

Hi!

Quoted 8 lines

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.

Quoted 17 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 2 lines

Input subsystem includes support for vibrations and force feedback. Please use that instead.

I thought we are already over this discussion. As of now, the support of vibrator through ledtrig is documented (Documentation/leds/ledtrig-transient.txt) and there are users using it.

Quoted 18 lines · David Lin

Quoted 17 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 7 lines

Quoted 2 lines

Input subsystem includes support for vibrations and force feedback. Please use that instead.

I thought we are already over this discussion. As of now, the support of vibrator through ledtrig is documented (Documentation/leds/ledtrig-transient.txt) and there are users using it.

I also thought we are over with that discussion.

Yes, I'm working on fixing the docs.

What mainline users are doing that?

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

NAK.

LEDs do not need extra overhead, and vibrator control should not go through LED subsystem.

Quoted 7 lines

Quoted 7 lines

Quoted 2 lines

Input subsystem includes support for vibrations and force feedback. Please use that instead.

I thought we are already over this discussion. As of now, the support of vibrator through ledtrig is documented (Documentation/leds/ledtrig-transient.txt) and there are users using it.

Quoted 5 lines

I also thought we are over with that discussion.

Yes, I'm working on fixing the docs.

What mainline users are doing that?

Please refer to patch:
https://patchwork.kernel.org/patch/8664831/ and
https://android.googlesource.com/platform%2Fhardware%2Flibhardware/+/61701df363310a5cbd95e3e1638baa9526e42c9b

I don't think currently there are drivers in the mainline using it yet, the reason being most of the Android devices are still on 4.4 kernel which still uses the legacy timed_output device.

Hi!

Quoted 8 lines

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 would change one more thing in this patch, though. The hr_timer engine should be made optional and not used by default for fast LEDs. It could be made configurable by exposing additional sysfs file from ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.

Quoted 4 lines · Jacek Anaszewski

I would change one more thing in this patch, though. The hr_timer engine should be made optional and not used by default for fast LEDs. It could be made configurable by exposing additional sysfs file from ledtrig-transient.c, e.g. hr_timer_support, accepting boolean value.

Do you mean in additional to checking the LED_BRIGHTNESS_FAST flag, userspace has to explicitly enable it via sysfs for ledtrig to select hrtimer? This seems to be redundant to me. Could you please explain your concerns and the benefit of doing this? Thanks.

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 2 lines

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.

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 38 lines · Pavel Machek

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 3 lines

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,

given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should take care of handling duration of the effect, ramping it up and decaying, if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD being revoked).

Quoted 4 lines

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.

Quoted 2 lines

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?

Quoted 39 lines · Dmitry Torokhov

Quoted 38 lines · Pavel Machek

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 5 lines

Quoted 3 lines

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?

Quoted 12 lines

given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should take care of handling duration of the effect, ramping it up and decaying, if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD being revoked).

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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:

(quoted diff) +0 -5

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

Quoted 46 lines · Jacek Anaszewski

Quoted 39 lines · Dmitry Torokhov

Quoted 38 lines · Pavel Machek

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 5 lines

Quoted 3 lines

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,

Quoted 8 lines

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?

Cut what you need from this:
https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c

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.

Quoted 38 lines

Quoted 12 lines

given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should take care of handling duration of the effect, ramping it up and decaying, if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD being revoked).

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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:

(quoted diff) +0 -5

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

Quoted 5 lines

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 say that while leds-gpio can be used to do whatever (you can wire PS/2 mouse to a set of gpios and probably manage to drive it through a set of leds-gpio devices) it does not make it right interface for everything. We do have a standard interface for haptic (via rumble FF), at this moment I see no reason why we need another one. It just confuses userspace as it now needs to implement multiple interfaces, depending on the system it runs. Android expects that HAL will take care of hiding all of that from their upper layers and does not really pay close attention to kernel ABIs, but I think we should.

Quoted 7 lines

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.

Quoted 4 lines

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.

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

Quoted 2 lines

However only if following conditions are met:
- force feedback driver supports gpio driven devices

Hi!

Quoted 12 lines

Quoted 11 lines

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.

Quoted 3 lines

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.

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.

Quoted 6 lines

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.

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:

Hi,

Quoted 18 lines · Pavel Machek

Hi!

Quoted 15 lines

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 4 lines

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?

Quoted 11 lines

Quoted 7 lines

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:

Quoted 4 lines

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.

Quoted 21 lines · Jacek Anaszewski

Hi,

Quoted 18 lines · Pavel Machek

Hi!

Quoted 15 lines

Quoted 11 lines

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.

Quoted 5 lines

Quoted 2 lines

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.

Quoted 7 lines

Quoted 4 lines

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.

Quoted 2 lines

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

Quoted 19 lines

Quoted 10 lines

Quoted 6 lines

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:

Quoted 4 lines

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:

Quoted 5 lines

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.

Quoted 29 lines · Dmitry Torokhov

Quoted 21 lines · Jacek Anaszewski

Hi,

Quoted 18 lines · Pavel Machek

Hi!

Quoted 15 lines

Quoted 11 lines

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.

Quoted 5 lines

Quoted 2 lines

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?

Quoted 7 lines

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.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 2 lines

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.

Quoted 56 lines · Jacek Anaszewski

Quoted 29 lines · Dmitry Torokhov

Quoted 21 lines · Jacek Anaszewski

Hi,

Quoted 18 lines · Pavel Machek

Hi!

Quoted 15 lines

Quoted 11 lines

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.

Quoted 5 lines

Quoted 2 lines

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?

Quoted 7 lines

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.

Quoted 7 lines

Quoted 7 lines

Quoted 4 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 3 lines

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.

Quoted 5 lines

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?

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 16 lines

Quoted 15 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 16 lines · Pavel Machek

Quoted 16 lines

Quoted 15 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 5 lines

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 21 lines · Jacek Anaszewski

Quoted 20 lines · Pavel Machek

Quoted 19 lines

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

Quoted 1 line

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.

So please write it.

Quoted 6 lines

Quoted 2 lines

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

Quoted 3 lines

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

Yes, my patch is removing dangerously misleading documentation about LED subsystem.

Please apply it.

Quoted 7 lines

Quoted 6 lines

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

Quoted 3 lines

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:

Quoted 4 lines

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.

Quoted 46 lines · Jacek Anaszewski

Quoted 39 lines · Dmitry Torokhov

Quoted 38 lines · Pavel Machek

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 5 lines

Quoted 3 lines

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,

Quoted 8 lines

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?

Cut what you need from this:
https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c

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.

Quoted 38 lines

Quoted 12 lines

given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should take care of handling duration of the effect, ramping it up and decaying, if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD being revoked).

Quoted 4 lines

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.

Quoted 6 lines

Quoted 2 lines

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:

(quoted diff) +0 -5

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

Quoted 5 lines

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 say that while leds-gpio can be used to do whatever (you can wire PS/2 mouse to a set of gpios and probably manage to drive it through a set of leds-gpio devices) it does not make it right interface for everything. We do have a standard interface for haptic (via rumble FF), at this moment I see no reason why we need another one. It just confuses userspace as it now needs to implement multiple interfaces, depending on the system it runs. Android expects that HAL will take care of hiding all of that from their upper layers and does not really pay close attention to kernel ABIs, but I think we should.

Dmitry,

Quoted 4 lines · Dmitry Torokhov

Quoted 2 lines · Jacek Anaszewski

Quoted 1 line · Dmitry Torokhov

On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <[email protected]> wrote:

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines · Jacek Anaszewski

Quoted 7 lines

Hi David and Pavel,

Quoted 4 lines · Pavel Machek

Hi!

Quoted 2 lines

These patch series add the LED_BRIGHTNESS_FAST flag support for ledtrig-transient to use hrtimer so that platforms with

high-resolution timer

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

support can have better accuracy in the trigger duration

timing. The need for

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

this support is driven by the fact that Android has removed the

timed_ouput [1]

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

and is now using led-trigger for handling vibrator control

which requires the

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

timer to be accurate up to a millisecond. However, this flag

support would also

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

allow hrtimer to co-exist with the ktimer without causing

warning to the

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 1 line

existing drivers [2].

NAK.

LEDs do not need extra overhead, and vibrator control should not

go

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 11 lines

Quoted 10 lines

Quoted 4 lines

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.

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

Quoted 6 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

have situation where "on phones A, D and E, vibrations are handled

via

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

Quoted 4 lines

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.

Quoted 13 lines

Quoted 4 lines

Quoted 3 lines

Quoted 1 line

I would like to know more about why you find the FF interface hard,

Quoted 8 lines

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?

Quoted 7 lines

Cut what you need from this:
https://github.com/flosse/linuxconsole/blob/master/utils/fftest.c

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?

Quoted 1 line

With FF you can pass an FD to whoever you deem worthy and later

revoke

Quoted 10 lines

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.

Quoted 3 lines

Quoted 3 lines

given that for rumble you need calls - one ioctl to set up rumble parameters, and a write to start the playback. The FF core should

take

Quoted 1 line

Quoted 1 line

Quoted 1 line

care of handling duration of the effect, ramping it up and

decaying,

Quoted 2 lines

Quoted 2 lines

Quoted 2 lines

if desired, and we make sure to automatically stop effects when userspace closes the fd (because of ordinary exit or crash or FD

being

Quoted 7 lines

Quoted 7 lines

Quoted 7 lines

revoked).

Quoted 5 lines

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

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

is just bad...

Completely agree here. I just merged PWM vibra driver from

Sebastian

Quoted 1 line

Quoted 1 line

Quoted 1 line

Reichel, we already had regulator-haptic driver, do we need

gpio-based

Quoted 7 lines

Quoted 7 lines

Quoted 1 line

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

Quoted 1 line

Quoted 1 line

-phones. Vibrate function on phones is implemented using PWM pins on

SoC or

Quoted 1 line

Quoted 1 line

-PMIC. There is a need to activate one shot timer to control the

vibrate

Quoted 1 line

Quoted 1 line

-feature, to prevent user space crashes leaving the phone in vibrate

mode

Quoted 17 lines

Quoted 11 lines

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

Quoted 5 lines

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.

Quoted 9 lines

I would say that while leds-gpio can be used to do whatever (you can wire PS/2 mouse to a set of gpios and probably manage to drive it through a set of leds-gpio devices) it does not make it right interface for everything. We do have a standard interface for haptic (via rumble FF), at this moment I see no reason why we need another one. It just confuses userspace as it now needs to implement multiple interfaces, depending on the system it runs. Android expects that HAL will take care of hiding all of that from their upper layers and does not really pay close attention to kernel ABIs, but I think we should.

One thing I noticed is that input_ff_create_memless() also does not use high-resolution timer hence it also does not have the stop-time precision that I'm looking for.

Another thing is that ff_reply duration value is maxed-out at 32767 ms (u16) while the Android/userspace requires size long for performing long notification alert.

Quoted 3 lines

One thing I noticed is that input_ff_create_memless() also does not use high-resolution timer hence it also does not have the stop-time precision that I'm looking for.

I'll take patches for high resolution timers in ff memless, they should also help with more accurate scheduling of ramping up and fading of events.

Quoted 6 lines

Another thing is that ff_reply duration value is maxed-out at 32767 ms (u16) while the Android/userspace requires size long for performing long notification alert.

You need unattended vibrations lasting longer than 30 seconds? Anyway, replay.length == 0 means endless IIRC, so you only need to schedule stopping. We still will clean up properly if your process crashes or exits or closes the fd.

Quoted 5 lines · Dmitry Torokhov

Quoted 3 lines

One thing I noticed is that input_ff_create_memless() also does not use high-resolution timer hence it also does not have the stop-time precision that I'm looking for.

I'll take patches for high resolution timers in ff memless, they should also help with more accurate scheduling of ramping up and fading of events.

Thanks.

Quoted 7 lines

Quoted 6 lines

Another thing is that ff_reply duration value is maxed-out at 32767 ms (u16) while the Android/userspace requires size long for performing long notification alert.

Quoted 1 line

You need unattended vibrations lasting longer than 30 seconds? Anyway, replay.length == 0 means endless IIRC, so you only need to schedule stopping. We still will clean up properly if your process crashes or exits or closes the fd.

Yes, it's up to the application to vibrate for as long as it requires. Is there any concern making the duration variable a type long? [If this is getting off-topic, I'll follow up with another email]

Quoted 5 lines

Quoted 3 lines

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?

Quoted 6 lines

Quoted 2 lines

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:

(quoted diff) +0 -5

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

Quoted 19 lines · Jacek Anaszewski

Hi David and Pavel,

Quoted 16 lines · Pavel Machek

Hi!

Quoted 8 lines

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.

Quoted 8 lines

Quoted 2 lines

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

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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

Quoted 8 lines

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?

Hi!

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

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

...

Quoted 14 lines

Quoted 8 lines

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.

Quoted 2 lines

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?

Quoted 8 lines

Quoted 2 lines

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

Hi!

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

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

Hi,

Quoted 20 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 1 line

(*) 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?

Quoted 23 lines · Jacek Anaszewski

Hi,

Quoted 20 lines · Pavel Machek

Hi!

Quoted 10 lines

Quoted 8 lines

Quoted 2 lines

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?

Quoted 5 lines

Quoted 1 line

(*) 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?