* [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer @ 2017-09-13 17:53 David Lin 2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin ` (3 more replies) 0 siblings, 4 replies; 42+ messages in thread From: David Lin @ 2017-09-13 17:53 UTC (permalink / raw) To: corbet, rpurdie, jacek.anaszewski, pavel, hdegoede, gregkh Cc: robh, romlem, linux-doc, linux-kernel, linux-leds, David Lin 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]. David [1] https://patchwork.kernel.org/patch/8664831/ [2] https://lkml.org/lkml/2015/4/28/260 Changes from v1 to v2: - Convert all the bit shifting flag in leds.h to use the BIT macro. - Removed inline modifiers for the timer helper function. 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(-) -- 2.14.1.581.gf28d330327-goog ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros 2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin @ 2017-09-13 17:53 ` David Lin 2017-09-14 19:43 ` Jacek Anaszewski 2017-09-13 17:53 ` [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin ` (2 subsequent siblings) 3 siblings, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-13 17:53 UTC (permalink / raw) To: corbet, rpurdie, jacek.anaszewski, pavel, hdegoede, gregkh Cc: robh, romlem, linux-doc, linux-kernel, linux-leds, David Lin 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 <dtwlin@google.com> --- include/linux/leds.h | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/linux/leds.h b/include/linux/leds.h index bf6db4fe895b..5579c64c8fd6 100644 --- a/include/linux/leds.h +++ b/include/linux/leds.h @@ -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) +#define LED_CORE_SUSPENDRESUME BIT(16) +#define LED_SYSFS_DISABLE BIT(17) +#define LED_DEV_CAP_FLASH BIT(18) +#define LED_HW_PLUGGABLE BIT(19) +#define LED_PANIC_INDICATOR BIT(20) +#define LED_BRIGHT_HW_CHANGED BIT(21) +#define LED_RETAIN_AT_SHUTDOWN BIT(22) /* set_brightness_work / blink_timer flags, atomic, private. */ unsigned long work_flags; -- 2.14.1.581.gf28d330327-goog ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros 2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin @ 2017-09-14 19:43 ` Jacek Anaszewski 0 siblings, 0 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-14 19:43 UTC (permalink / raw) To: David Lin, corbet, rpurdie, pavel, hdegoede, gregkh Cc: robh, romlem, linux-doc, linux-kernel, linux-leds Hi David, Thanks for the patch. On 09/13/2017 07:53 PM, David Lin wrote: > 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 <dtwlin@google.com> > --- > include/linux/leds.h | 18 +++++++++--------- > 1 file changed, 9 insertions(+), 9 deletions(-) > > diff --git a/include/linux/leds.h b/include/linux/leds.h > index bf6db4fe895b..5579c64c8fd6 100644 > --- a/include/linux/leds.h > +++ b/include/linux/leds.h > @@ -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) > +#define LED_CORE_SUSPENDRESUME BIT(16) > +#define LED_SYSFS_DISABLE BIT(17) > +#define LED_DEV_CAP_FLASH BIT(18) > +#define LED_HW_PLUGGABLE BIT(19) > +#define LED_PANIC_INDICATOR BIT(20) > +#define LED_BRIGHT_HW_CHANGED BIT(21) > +#define LED_RETAIN_AT_SHUTDOWN BIT(22) > > /* set_brightness_work / blink_timer flags, atomic, private. */ > unsigned long work_flags; > This one should not raise any doubts. Applied to the for-4.15 branch of linux-leds.git. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag 2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin 2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin @ 2017-09-13 17:53 ` David Lin 2017-09-13 17:54 ` [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin 2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek 3 siblings, 0 replies; 42+ messages in thread From: David Lin @ 2017-09-13 17:53 UTC (permalink / raw) To: corbet, rpurdie, jacek.anaszewski, pavel, hdegoede, gregkh Cc: robh, romlem, linux-doc, linux-kernel, linux-leds, David Lin This patch adds the LED_BRIGHTNESS_FAST flag to allow the driver to indicate that the brightness_set() callback is implemented on a fastpath so that the LED core may choose to for example use a hrtimer to implement the duration of a trigger for better timing accuracy. Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: David Lin <dtwlin@google.com> --- Documentation/leds/leds-class.txt | 5 +++++ include/linux/leds.h | 1 + 2 files changed, 6 insertions(+) diff --git a/Documentation/leds/leds-class.txt b/Documentation/leds/leds-class.txt index 836cb16d6f09..70d7a3dca621 100644 --- a/Documentation/leds/leds-class.txt +++ b/Documentation/leds/leds-class.txt @@ -80,6 +80,11 @@ flag must be set in flags before registering. Calling led_classdev_notify_brightness_hw_changed on a classdev not registered with the LED_BRIGHT_HW_CHANGED flag is a bug and will trigger a WARN_ON. +Optionally, the driver may choose to register with the LED_BRIGHTNESS_FAST flag. +This flag indicates that the driver implements the brightness_set() callback +function using a fastpath so the LED core can use hrtimer if the driver requires +high precision for the trigger timing. + Hardware accelerated blink of LEDs ================================== diff --git a/include/linux/leds.h b/include/linux/leds.h index 5579c64c8fd6..ccfa0a1799fe 100644 --- a/include/linux/leds.h +++ b/include/linux/leds.h @@ -50,6 +50,7 @@ struct led_classdev { #define LED_PANIC_INDICATOR BIT(20) #define LED_BRIGHT_HW_CHANGED BIT(21) #define LED_RETAIN_AT_SHUTDOWN BIT(22) +#define LED_BRIGHTNESS_FAST BIT(23) /* set_brightness_work / blink_timer flags, atomic, private. */ unsigned long work_flags; -- 2.14.1.581.gf28d330327-goog ^ permalink raw reply related [flat|nested] 42+ messages in thread
* [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin 2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin 2017-09-13 17:53 ` [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin @ 2017-09-13 17:54 ` David Lin 2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek 3 siblings, 0 replies; 42+ messages in thread From: David Lin @ 2017-09-13 17:54 UTC (permalink / raw) To: corbet, rpurdie, jacek.anaszewski, pavel, hdegoede, gregkh Cc: robh, romlem, linux-doc, linux-kernel, linux-leds, David Lin This patch adds a hrtimer to ledtrig-transient so that when driver is registered with LED_BRIGHTNESS_FAST, the hrtimer is used for the better time accuracy in handling the duration. Signed-off-by: David Lin <dtwlin@google.com> --- drivers/leds/trigger/ledtrig-transient.c | 59 +++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 5 deletions(-) diff --git a/drivers/leds/trigger/ledtrig-transient.c b/drivers/leds/trigger/ledtrig-transient.c index 7e6011bd3646..7d2ce757b39d 100644 --- a/drivers/leds/trigger/ledtrig-transient.c +++ b/drivers/leds/trigger/ledtrig-transient.c @@ -24,15 +24,18 @@ #include <linux/device.h> #include <linux/slab.h> #include <linux/timer.h> +#include <linux/hrtimer.h> #include <linux/leds.h> #include "../leds.h" struct transient_trig_data { + struct led_classdev *led_cdev; int activate; int state; int restore_state; unsigned long duration; struct timer_list timer; + struct hrtimer hrtimer; }; static void transient_timer_function(unsigned long data) @@ -44,6 +47,54 @@ static void transient_timer_function(unsigned long data) led_set_brightness_nosleep(led_cdev, transient_data->restore_state); } +static enum hrtimer_restart transient_hrtimer_function(struct hrtimer *timer) +{ + struct transient_trig_data *transient_data = + container_of(timer, struct transient_trig_data, hrtimer); + + transient_timer_function((unsigned long)transient_data->led_cdev); + + return HRTIMER_NORESTART; +} + +static void transient_timer_setup(struct led_classdev *led_cdev) +{ + struct transient_trig_data *tdata = led_cdev->trigger_data; + + if (led_cdev->flags & LED_BRIGHTNESS_FAST) { + tdata->led_cdev = led_cdev; + hrtimer_init(&tdata->hrtimer, CLOCK_MONOTONIC, + HRTIMER_MODE_REL); + tdata->hrtimer.function = transient_hrtimer_function; + } else { + setup_timer(&tdata->timer, transient_timer_function, + (unsigned long)led_cdev); + } +} + +static void transient_timer_start(struct led_classdev *led_cdev) +{ + struct transient_trig_data *tdata = led_cdev->trigger_data; + + if (led_cdev->flags & LED_BRIGHTNESS_FAST) { + hrtimer_start(&tdata->hrtimer, ms_to_ktime(tdata->duration), + HRTIMER_MODE_REL); + } else { + mod_timer(&tdata->timer, + jiffies + msecs_to_jiffies(tdata->duration)); + } +} + +static void transient_timer_cancel(struct led_classdev *led_cdev) +{ + struct transient_trig_data *tdata = led_cdev->trigger_data; + + if (led_cdev->flags & LED_BRIGHTNESS_FAST) + hrtimer_cancel(&tdata->hrtimer); + else + del_timer_sync(&tdata->timer); +} + static ssize_t transient_activate_show(struct device *dev, struct device_attribute *attr, char *buf) { @@ -70,7 +121,7 @@ static ssize_t transient_activate_store(struct device *dev, /* cancel the running timer */ if (state == 0 && transient_data->activate == 1) { - del_timer(&transient_data->timer); + transient_timer_cancel(led_cdev); transient_data->activate = state; led_set_brightness_nosleep(led_cdev, transient_data->restore_state); @@ -84,8 +135,7 @@ static ssize_t transient_activate_store(struct device *dev, led_set_brightness_nosleep(led_cdev, transient_data->state); transient_data->restore_state = (transient_data->state == LED_FULL) ? LED_OFF : LED_FULL; - mod_timer(&transient_data->timer, - jiffies + msecs_to_jiffies(transient_data->duration)); + transient_timer_start(led_cdev); } /* state == 0 && transient_data->activate == 0 @@ -182,8 +232,7 @@ static void transient_trig_activate(struct led_classdev *led_cdev) if (rc) goto err_out_state; - setup_timer(&tdata->timer, transient_timer_function, - (unsigned long) led_cdev); + transient_timer_setup(led_cdev); led_cdev->activated = true; return; -- 2.14.1.581.gf28d330327-goog ^ permalink raw reply related [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin ` (2 preceding siblings ...) 2017-09-13 17:54 ` [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin @ 2017-09-13 20:20 ` Pavel Machek 2017-09-13 21:20 ` David Lin 2017-09-14 19:31 ` Jacek Anaszewski 3 siblings, 2 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-13 20:20 UTC (permalink / raw) To: David Lin Cc: corbet, rpurdie, jacek.anaszewski, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 1374 bytes --] 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. Pavel > 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(-) > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek @ 2017-09-13 21:20 ` David Lin 2017-09-13 21:34 ` Pavel Machek 2017-09-14 19:31 ` Jacek Anaszewski 1 sibling, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-13 21:20 UTC (permalink / raw) To: Pavel Machek Cc: Jonathan Corbet, rpurdie, Jacek Anaszewski, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 21:20 ` David Lin @ 2017-09-13 21:34 ` Pavel Machek 2017-09-14 17:31 ` David Lin 0 siblings, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-09-13 21:34 UTC (permalink / raw) To: David Lin Cc: Jonathan Corbet, rpurdie, Jacek Anaszewski, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 1463 bytes --] On Wed 2017-09-13 14:20:58, David Lin wrote: > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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 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? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 21:34 ` Pavel Machek @ 2017-09-14 17:31 ` David Lin 2017-09-14 19:42 ` Pavel Machek 0 siblings, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-14 17:31 UTC (permalink / raw) To: Pavel Machek Cc: Jonathan Corbet, rpurdie, Jacek Anaszewski, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds On Wed, Sep 13, 2017 at 2:34 PM, Pavel Machek <pavel@ucw.cz> wrote: > > On Wed 2017-09-13 14:20:58, David Lin wrote: > > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek <pavel@ucw.cz> 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 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? 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 17:31 ` David Lin @ 2017-09-14 19:42 ` Pavel Machek 0 siblings, 0 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-14 19:42 UTC (permalink / raw) To: David Lin Cc: Jonathan Corbet, rpurdie, Jacek Anaszewski, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 1735 bytes --] Hi! > > > > 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 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. Stop misleading people. No _users_ are using Android on mainline kernel, as there is not a single Android phone supported by mainline kernel. > > 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. Ok. I'm sorry commit 61701df363310a5cbd95e3e1638baa9526e42c9b pushed your libhardware into wrong direction, but that is exactly what happened. LED subsystem is not suitable for vibrations. We have input subsystem for that, it is handling vibrations for 10+ years, and for example Nokia N900 cellphone (which is supported by mainline) uses them. Please fix libhardware accordingly. Thank you, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek 2017-09-13 21:20 ` David Lin @ 2017-09-14 19:31 ` Jacek Anaszewski 2017-09-14 19:38 ` David Lin 2017-09-14 20:58 ` Vibrations in input vs. LED was " Pavel Machek 1 sibling, 2 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-14 19:31 UTC (permalink / raw) To: Pavel Machek, David Lin Cc: corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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. 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. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 19:31 ` Jacek Anaszewski @ 2017-09-14 19:38 ` David Lin 2017-09-14 20:03 ` Jacek Anaszewski 2017-09-14 20:58 ` Vibrations in input vs. LED was " Pavel Machek 1 sibling, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-14 19:38 UTC (permalink / raw) To: Jacek Anaszewski Cc: Pavel Machek, Jonathan Corbet, rpurdie, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote: > 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. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 19:38 ` David Lin @ 2017-09-14 20:03 ` Jacek Anaszewski 0 siblings, 0 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-14 20:03 UTC (permalink / raw) To: David Lin Cc: Pavel Machek, Jonathan Corbet, rpurdie, hdegoede, Greg KH, robh, Rom Lemarchand, linux-doc, linux-kernel, linux-leds On 09/14/2017 09:38 PM, David Lin wrote: > On Thu, Sep 14, 2017 at 12:31 PM, Jacek Anaszewski > <jacek.anaszewski@gmail.com> wrote: >> 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. My concern is that fast LED users would be automatically imposed a hr_timer overhead, which they may not need. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 19:31 ` Jacek Anaszewski 2017-09-14 19:38 ` David Lin @ 2017-09-14 20:58 ` Pavel Machek 2017-09-15 18:34 ` Dmitry Torokhov 2017-09-15 21:55 ` Jacek Anaszewski 1 sibling, 2 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-14 20:58 UTC (permalink / raw) To: Jacek Anaszewski, linux-input Cc: David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 2346 bytes --] 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". Thank you, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 20:58 ` Vibrations in input vs. LED was " Pavel Machek @ 2017-09-15 18:34 ` Dmitry Torokhov 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-15 21:55 ` Jacek Anaszewski 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Torokhov @ 2017-09-15 18:34 UTC (permalink / raw) To: Pavel Machek Cc: Jacek Anaszewski, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. > 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). > 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... 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? Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 18:34 ` Dmitry Torokhov @ 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-15 22:30 ` Dmitry Torokhov 2017-09-16 12:59 ` Pavel Machek 0 siblings, 2 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-15 21:55 UTC (permalink / raw) To: Dmitry Torokhov, Pavel Machek Cc: linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: > On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. >> > > 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? > 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). > >> 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... > > 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. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 21:55 ` Jacek Anaszewski @ 2017-09-15 22:30 ` Dmitry Torokhov 2017-09-17 16:41 ` Jacek Anaszewski 2017-09-28 5:03 ` David Lin 2017-09-16 12:59 ` Pavel Machek 1 sibling, 2 replies; 42+ messages in thread From: Dmitry Torokhov @ 2017-09-15 22:30 UTC (permalink / raw) To: Jacek Anaszewski Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski <jacek.anaszewski@gmail.com> wrote: > On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. >>> >> >> 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? 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. > >> 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). >> >>> 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... >> >> 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 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. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 22:30 ` Dmitry Torokhov @ 2017-09-17 16:41 ` Jacek Anaszewski 2017-09-17 18:22 ` Pavel Machek 2017-09-28 5:03 ` David Lin 1 sibling, 1 reply; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-17 16:41 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On 09/16/2017 12:30 AM, Dmitry Torokhov wrote: > On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski > <jacek.anaszewski@gmail.com> wrote: >> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. >>>> >>> >>> 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? > > 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. 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 >> >>> 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). >>> >>>> 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... >>> >>> 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 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. Generally I agree, provided that user will be able to achieve the same using force feedback device as in case of LED transient trigger, with the same easy guidance on how to employ it to do this particular task with given hardware configuration. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-17 16:41 ` Jacek Anaszewski @ 2017-09-17 18:22 ` Pavel Machek 2017-09-17 21:15 ` Pavel Machek 2017-09-18 20:50 ` Jacek Anaszewski 0 siblings, 2 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-17 18:22 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 1867 bytes --] 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. 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. > 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. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-17 18:22 ` Pavel Machek @ 2017-09-17 21:15 ` Pavel Machek 2017-09-18 20:50 ` Jacek Anaszewski 1 sibling, 0 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-17 21:15 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 334 bytes --] Hi! > > However only if following conditions are met: > > - force feedback driver supports gpio driven devices INPUT_PWM_VIBRA option was just merged into v4.14. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-17 18:22 ` Pavel Machek 2017-09-17 21:15 ` Pavel Machek @ 2017-09-18 20:50 ` Jacek Anaszewski 2017-09-18 22:29 ` Dmitry Torokhov 2017-09-20 11:26 ` Pavel Machek 1 sibling, 2 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-18 20:50 UTC (permalink / raw) To: Pavel Machek Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-18 20:50 ` Jacek Anaszewski @ 2017-09-18 22:29 ` Dmitry Torokhov 2017-09-19 20:45 ` Jacek Anaszewski 2017-09-20 11:26 ` Pavel Machek 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Torokhov @ 2017-09-18 22:29 UTC (permalink / raw) To: Jacek Anaszewski Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-18 22:29 ` Dmitry Torokhov @ 2017-09-19 20:45 ` Jacek Anaszewski 2017-09-19 21:07 ` Dmitry Torokhov 2017-09-20 11:29 ` Pavel Machek 0 siblings, 2 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-19 20:45 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-19 20:45 ` Jacek Anaszewski @ 2017-09-19 21:07 ` Dmitry Torokhov 2017-09-20 19:31 ` Jacek Anaszewski 2017-09-20 11:29 ` Pavel Machek 1 sibling, 1 reply; 42+ messages in thread From: Dmitry Torokhov @ 2017-09-19 21:07 UTC (permalink / raw) To: Jacek Anaszewski Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-19 21:07 ` Dmitry Torokhov @ 2017-09-20 19:31 ` Jacek Anaszewski 0 siblings, 0 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-20 19:31 UTC (permalink / raw) To: Dmitry Torokhov Cc: Pavel Machek, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-19 20:45 ` Jacek Anaszewski 2017-09-19 21:07 ` Dmitry Torokhov @ 2017-09-20 11:29 ` Pavel Machek 2017-09-20 20:08 ` Jacek Anaszewski 1 sibling, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-09-20 11:29 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 1392 bytes --] > >>> 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-20 11:29 ` Pavel Machek @ 2017-09-20 20:08 ` Jacek Anaszewski 2017-10-06 11:48 ` Pavel Machek 0 siblings, 1 reply; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-20 20:08 UTC (permalink / raw) To: Pavel Machek Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-20 20:08 ` Jacek Anaszewski @ 2017-10-06 11:48 ` Pavel Machek 2017-10-06 20:57 ` Jacek Anaszewski 0 siblings, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-10-06 11:48 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 2075 bytes --] On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote: > 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. So please write it. > > 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. Yes, my patch is removing dangerously misleading documentation about LED subsystem. Please apply it. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-10-06 11:48 ` Pavel Machek @ 2017-10-06 20:57 ` Jacek Anaszewski 0 siblings, 0 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-10-06 20:57 UTC (permalink / raw) To: Pavel Machek Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On 10/06/2017 01:48 PM, Pavel Machek wrote: > On Wed 2017-09-20 22:08:42, Jacek Anaszewski wrote: >> 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. > > So please write it. This is my demand as a reviewer. I've already laid out the conditions under which I'll accept the patch. It seems that you're proficient in the subject enough to cope with this task. >>> 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. > > Yes, my patch is removing dangerously misleading documentation about > LED subsystem. It's neither dangerous nor misleading. > Please apply it. Right after I'll get the patch with the tool showing how to use input subsystem to achieve the same effect as with use of ledtrig-transient. -- Best regards, Jacek Anaszewski ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-18 20:50 ` Jacek Anaszewski 2017-09-18 22:29 ` Dmitry Torokhov @ 2017-09-20 11:26 ` Pavel Machek 1 sibling, 0 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-20 11:26 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 1785 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 22:30 ` Dmitry Torokhov 2017-09-17 16:41 ` Jacek Anaszewski @ 2017-09-28 5:03 ` David Lin 2017-09-28 5:43 ` Dmitry Torokhov 1 sibling, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-28 5:03 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jacek Anaszewski, Pavel Machek, linux-input, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds Dmitry, On Fri, Sep 15, 2017 at 3:30 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski > <jacek.anaszewski@gmail.com> wrote: >> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. >>>> >>> >>> 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? > > 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. > >> >>> 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). >>> >>>> 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... >>> >>> 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 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. David ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-28 5:03 ` David Lin @ 2017-09-28 5:43 ` Dmitry Torokhov 2017-09-28 19:22 ` David Lin 0 siblings, 1 reply; 42+ messages in thread From: Dmitry Torokhov @ 2017-09-28 5:43 UTC (permalink / raw) To: David Lin Cc: Jacek Anaszewski, Pavel Machek, linux-input, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On September 27, 2017 10:03:28 PM PDT, David Lin <dtwlin@google.com> wrote: >Dmitry, > >On Fri, Sep 15, 2017 at 3:30 PM, Dmitry Torokhov ><dmitry.torokhov@gmail.com> wrote: >> On Fri, Sep 15, 2017 at 2:55 PM, Jacek Anaszewski >> <jacek.anaszewski@gmail.com> wrote: >>> On 09/15/2017 08:34 PM, Dmitry Torokhov wrote: >>>> On Thu, Sep 14, 2017 at 1:58 PM, Pavel Machek <pavel@ucw.cz> 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. >>>>> >>>> >>>> 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? >> >> 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. >> >>> >>>> 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). >>>> >>>>> 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... >>>> >>>> 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 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. 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. > >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. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-28 5:43 ` Dmitry Torokhov @ 2017-09-28 19:22 ` David Lin 2017-10-05 0:40 ` Dmitry Torokhov 0 siblings, 1 reply; 42+ messages in thread From: David Lin @ 2017-09-28 19:22 UTC (permalink / raw) To: Dmitry Torokhov Cc: Jacek Anaszewski, Pavel Machek, linux-input, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: >>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. > >> >>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. 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] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-28 19:22 ` David Lin @ 2017-10-05 0:40 ` Dmitry Torokhov 0 siblings, 0 replies; 42+ messages in thread From: Dmitry Torokhov @ 2017-10-05 0:40 UTC (permalink / raw) To: David Lin Cc: Jacek Anaszewski, Pavel Machek, linux-input, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds On Thu, Sep 28, 2017 at 12:22:13PM -0700, David Lin wrote: > On Wed, Sep 27, 2017 at 10:43 PM, Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > >>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. > > > > >> > >>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. > > 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] Yes, given ABI constraints that is not really feasible. I think for effects longer than 30 seconds you'd have to handle it in the framework by using replay.length 0 and cancelling the effect some time later. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-15 22:30 ` Dmitry Torokhov @ 2017-09-16 12:59 ` Pavel Machek 1 sibling, 0 replies; 42+ messages in thread From: Pavel Machek @ 2017-09-16 12:59 UTC (permalink / raw) To: Jacek Anaszewski Cc: Dmitry Torokhov, linux-input, David Lin, Jonathan Corbet, Richard Purdie, Hans de Goede, Greg Kroah-Hartman, Rob Herring, Rom Lemarchand, linux-doc, lkml, linux-leds [-- Attachment #1: Type: text/plain, Size: 2754 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-14 20:58 ` Vibrations in input vs. LED was " Pavel Machek 2017-09-15 18:34 ` Dmitry Torokhov @ 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-16 1:58 ` Pavel Machek 1 sibling, 1 reply; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-15 21:55 UTC (permalink / raw) To: Pavel Machek, linux-input Cc: David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-15 21:55 ` Jacek Anaszewski @ 2017-09-16 1:58 ` Pavel Machek 2017-09-17 16:41 ` Jacek Anaszewski 0 siblings, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-09-16 1:58 UTC (permalink / raw) To: Jacek Anaszewski Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-16 1:58 ` Pavel Machek @ 2017-09-17 16:41 ` Jacek Anaszewski 2017-09-17 17:50 ` Pavel Machek 0 siblings, 1 reply; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-17 16:41 UTC (permalink / raw) To: Pavel Machek Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-17 16:41 ` Jacek Anaszewski @ 2017-09-17 17:50 ` Pavel Machek 2017-09-18 20:43 ` Jacek Anaszewski 0 siblings, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-09-17 17:50 UTC (permalink / raw) To: Jacek Anaszewski Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 1006 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-17 17:50 ` Pavel Machek @ 2017-09-18 20:43 ` Jacek Anaszewski 2017-09-20 11:15 ` Pavel Machek 0 siblings, 1 reply; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-18 20:43 UTC (permalink / raw) To: Pavel Machek Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-18 20:43 ` Jacek Anaszewski @ 2017-09-20 11:15 ` Pavel Machek 2017-09-20 18:44 ` Jacek Anaszewski 0 siblings, 1 reply; 42+ messages in thread From: Pavel Machek @ 2017-09-20 11:15 UTC (permalink / raw) To: Jacek Anaszewski Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds [-- Attachment #1: Type: text/plain, Size: 1477 bytes --] 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 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 181 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer 2017-09-20 11:15 ` Pavel Machek @ 2017-09-20 18:44 ` Jacek Anaszewski 0 siblings, 0 replies; 42+ messages in thread From: Jacek Anaszewski @ 2017-09-20 18:44 UTC (permalink / raw) To: Pavel Machek Cc: linux-input, David Lin, corbet, rpurdie, hdegoede, gregkh, robh, romlem, linux-doc, linux-kernel, linux-leds 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 ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2017-10-06 20:58 UTC | newest] Thread overview: 42+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-09-13 17:53 [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer David Lin 2017-09-13 17:53 ` [PATCH v2 1/3] leds: Replace flags bit shift with BIT() macros David Lin 2017-09-14 19:43 ` Jacek Anaszewski 2017-09-13 17:53 ` [PATCH v2 2/3] leds: Add the LED_BRIGHTNESS_FAST flag David Lin 2017-09-13 17:54 ` [PATCH v2 3/3] led: ledtrig-transient: add support for hrtimer David Lin 2017-09-13 20:20 ` [PATCH v2 0/3] " Pavel Machek 2017-09-13 21:20 ` David Lin 2017-09-13 21:34 ` Pavel Machek 2017-09-14 17:31 ` David Lin 2017-09-14 19:42 ` Pavel Machek 2017-09-14 19:31 ` Jacek Anaszewski 2017-09-14 19:38 ` David Lin 2017-09-14 20:03 ` Jacek Anaszewski 2017-09-14 20:58 ` Vibrations in input vs. LED was " Pavel Machek 2017-09-15 18:34 ` Dmitry Torokhov 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-15 22:30 ` Dmitry Torokhov 2017-09-17 16:41 ` Jacek Anaszewski 2017-09-17 18:22 ` Pavel Machek 2017-09-17 21:15 ` Pavel Machek 2017-09-18 20:50 ` Jacek Anaszewski 2017-09-18 22:29 ` Dmitry Torokhov 2017-09-19 20:45 ` Jacek Anaszewski 2017-09-19 21:07 ` Dmitry Torokhov 2017-09-20 19:31 ` Jacek Anaszewski 2017-09-20 11:29 ` Pavel Machek 2017-09-20 20:08 ` Jacek Anaszewski 2017-10-06 11:48 ` Pavel Machek 2017-10-06 20:57 ` Jacek Anaszewski 2017-09-20 11:26 ` Pavel Machek 2017-09-28 5:03 ` David Lin 2017-09-28 5:43 ` Dmitry Torokhov 2017-09-28 19:22 ` David Lin 2017-10-05 0:40 ` Dmitry Torokhov 2017-09-16 12:59 ` Pavel Machek 2017-09-15 21:55 ` Jacek Anaszewski 2017-09-16 1:58 ` Pavel Machek 2017-09-17 16:41 ` Jacek Anaszewski 2017-09-17 17:50 ` Pavel Machek 2017-09-18 20:43 ` Jacek Anaszewski 2017-09-20 11:15 ` Pavel Machek 2017-09-20 18:44 ` Jacek Anaszewski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).