* [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
@ 2016-03-01 21:26 Heiner Kallweit
2016-03-04 9:04 ` Jacek Anaszewski
2016-03-29 10:02 ` Pavel Machek
0 siblings, 2 replies; 46+ messages in thread
From: Heiner Kallweit @ 2016-03-01 21:26 UTC (permalink / raw)
To: Jacek Anaszewski; +Cc: linux-leds, Benjamin Tissoires, linux-kernel, linux-usb
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation
color components.This allows to implement the color extension w/o
changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation
should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0
0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- move extension-specific code into a separate source file and
introduce config symbol LEDS_HSV for it
- create separate patch for the extension to sysfs
- use variable name led_cdev as in the rest if the core
- rename to_hsv to led_validate_brightness
- rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
- introduce helper is_off for checking whether V part
of a HSV value is zero
v3:
- change Kconfig to use depend instead of select, add help message,
and change config symbol to LEDS_COLOR
- change LED core object file name in Makefile
- rename flag LED_SET_HSV to LED_SET_COLOR
- rename is_off to led_is_off
- rename led_validate-brightness to led_confine_brightness
- rename variable in led_confine_brightness
- add dummy enum led_brightness value to enforce 32bit enum
- rename led-hsv-core.c to led-color-core.c
- move check of provided brightness value to led_confine_brightness
v4:
- change config symbol name to LEDS_RGB
- change name of new file to led-rgb-core.c
- factor out part of led_confine_brightness
- change led_is_off to __is_set_brightness
- in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
- rename LED_SET_COLOR to LED_SET_HUE_SAT
v5:
- change "RGB Color LED" to "RGB LED" in Kconfig
- move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
- rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
---
drivers/leds/Kconfig | 11 +++++++++++
drivers/leds/Makefile | 4 +++-
drivers/leds/led-class.c | 2 +-
drivers/leds/led-core.c | 16 +++++++++-------
drivers/leds/led-rgb-core.c | 40 ++++++++++++++++++++++++++++++++++++++++
drivers/leds/leds.h | 18 ++++++++++++++++++
include/linux/leds.h | 9 +++++++++
7 files changed, 91 insertions(+), 9 deletions(-)
create mode 100644 drivers/leds/led-rgb-core.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 7f940c2..5b1c852 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -13,6 +13,13 @@ menuconfig NEW_LEDS
if NEW_LEDS
+config LEDS_RGB
+ bool "RGB LED Support"
+ help
+ This option enables support for RGB LED devices.
+ Sysfs attribute brightness is interpreted as a HSV color value.
+ For details see Documentation/leds/leds-class.txt.
+
config LEDS_CLASS
tristate "LED Class Support"
help
@@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
as a module.
+if LEDS_RGB
+comment "RGB LED drivers"
+endif # LEDS_RGB
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index e9d5309..cc3676f 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -1,6 +1,8 @@
# LED Core
-obj-$(CONFIG_NEW_LEDS) += led-core.o
+obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
+led-core-objs-y := led-core.o
+led-core-objs-$(CONFIG_LEDS_RGB) += led-rgb-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
index aa84e5b..007a5b3 100644
--- a/drivers/leds/led-class.c
+++ b/drivers/leds/led-class.c
@@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
if (ret)
goto unlock;
- if (state == LED_OFF)
+ if (!__is_brightness_set(state))
led_trigger_remove(led_cdev);
led_set_brightness(led_cdev, state);
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 3495d5d..e75b0c8 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -62,7 +62,7 @@ static void led_timer_function(unsigned long data)
}
brightness = led_get_brightness(led_cdev);
- if (!brightness) {
+ if (!__is_brightness_set(brightness)) {
/* Time to switch the LED on. */
brightness = led_cdev->blink_brightness;
delay = led_cdev->blink_delay_on;
@@ -133,8 +133,9 @@ static void led_set_software_blink(struct led_classdev *led_cdev,
if (current_brightness)
led_cdev->blink_brightness = current_brightness;
if (!led_cdev->blink_brightness)
- led_cdev->blink_brightness = led_cdev->max_brightness;
-
+ led_cdev->blink_brightness =
+ led_confine_brightness(led_cdev,
+ led_cdev->max_brightness);
led_cdev->blink_delay_on = delay_on;
led_cdev->blink_delay_off = delay_off;
@@ -235,12 +236,13 @@ void led_set_brightness(struct led_classdev *led_cdev,
* work queue task to avoid problems in case we are called
* from hard irq context.
*/
- if (brightness == LED_OFF) {
+ if (!__is_brightness_set(brightness)) {
led_cdev->flags |= LED_BLINK_DISABLE;
schedule_work(&led_cdev->set_brightness_work);
} else {
led_cdev->flags |= LED_BLINK_BRIGHTNESS_CHANGE;
- led_cdev->blink_brightness = brightness;
+ led_cdev->blink_brightness =
+ led_confine_brightness(led_cdev, brightness);
}
return;
}
@@ -265,7 +267,7 @@ EXPORT_SYMBOL_GPL(led_set_brightness_nopm);
void led_set_brightness_nosleep(struct led_classdev *led_cdev,
enum led_brightness value)
{
- led_cdev->brightness = min(value, led_cdev->max_brightness);
+ led_cdev->brightness = led_confine_brightness(led_cdev, value);
if (led_cdev->flags & LED_SUSPENDED)
return;
@@ -280,7 +282,7 @@ int led_set_brightness_sync(struct led_classdev *led_cdev,
if (led_cdev->blink_delay_on || led_cdev->blink_delay_off)
return -EBUSY;
- led_cdev->brightness = min(value, led_cdev->max_brightness);
+ led_cdev->brightness = led_confine_brightness(led_cdev, value);
if (led_cdev->flags & LED_SUSPENDED)
return 0;
diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
new file mode 100644
index 0000000..f6591f1
--- /dev/null
+++ b/drivers/leds/led-rgb-core.c
@@ -0,0 +1,40 @@
+/*
+ * LED Class Color Support
+ *
+ * Author: Heiner Kallweit <hkallweit1@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/kernel.h>
+#include <linux/leds.h>
+#include "leds.h"
+
+/*
+ * The color extension handles RGB LEDs but uses a HSV color model internally.
+ * led_rgb_adjust_hue_sat sets hue and saturation part of the HSV color value.
+ */
+static enum led_brightness led_rgb_adjust_hue_sat(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ /* LED_SET_HUE_SAT sets hue and saturation even if both are zero */
+ if (value & LED_SET_HUE_SAT || value > LED_FULL)
+ return value & LED_HUE_SAT_MASK;
+ else
+ return led_cdev->brightness & ~LED_BRIGHTNESS_MASK;
+}
+
+enum led_brightness led_confine_brightness(struct led_classdev *led_cdev,
+ enum led_brightness value)
+{
+ enum led_brightness brightness = 0;
+
+ if (led_cdev->flags & LED_DEV_CAP_RGB)
+ brightness = led_rgb_adjust_hue_sat(led_cdev, value);
+
+ return brightness |
+ min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
+}
diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
index db3f20d..b853f54 100644
--- a/drivers/leds/leds.h
+++ b/drivers/leds/leds.h
@@ -16,17 +16,35 @@
#include <linux/rwsem.h>
#include <linux/leds.h>
+#define LED_BRIGHTNESS_MASK 0x000000ff
+#define LED_HUE_SAT_MASK 0x00ffff00
+
static inline int led_get_brightness(struct led_classdev *led_cdev)
{
return led_cdev->brightness;
}
+static inline bool __is_brightness_set(enum led_brightness brightness)
+{
+ return (brightness & LED_BRIGHTNESS_MASK) != LED_OFF;
+}
+
void led_init_core(struct led_classdev *led_cdev);
void led_stop_software_blink(struct led_classdev *led_cdev);
void led_set_brightness_nopm(struct led_classdev *led_cdev,
enum led_brightness value);
void led_set_brightness_nosleep(struct led_classdev *led_cdev,
enum led_brightness value);
+#if IS_ENABLED(CONFIG_LEDS_RGB)
+enum led_brightness led_confine_brightness(struct led_classdev *led_cdev,
+ enum led_brightness value);
+#else
+static inline enum led_brightness led_confine_brightness(
+ struct led_classdev *led_cdev, enum led_brightness value)
+{
+ return min(value, led_cdev->max_brightness);
+}
+#endif
extern struct rw_semaphore leds_list_lock;
extern struct list_head leds_list;
diff --git a/include/linux/leds.h b/include/linux/leds.h
index f203a8f..bbf24bb 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -29,8 +29,16 @@ enum led_brightness {
LED_OFF = 0,
LED_HALF = 127,
LED_FULL = 255,
+ /*
+ * dummy enum value to make gcc use a 32 bit type for the enum
+ * even if compiled with -fshort-enums. This is needed for
+ * the enum to store hsv values.
+ */
+ LED_LEVEL_DUMMY = 0xffffffff,
};
+#define LED_SET_HUE_SAT BIT(24)
+
struct led_classdev {
const char *name;
enum led_brightness brightness;
@@ -50,6 +58,7 @@ struct led_classdev {
#define LED_SYSFS_DISABLE (1 << 22)
#define LED_DEV_CAP_FLASH (1 << 23)
#define LED_HW_PLUGGABLE (1 << 24)
+#define LED_DEV_CAP_RGB (1 << 25)
/* Set LED brightness level
* Must not sleep. Use brightness_set_blocking for drivers
--
2.7.1
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-01 21:26 [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's Heiner Kallweit
@ 2016-03-04 9:04 ` Jacek Anaszewski
2016-03-29 10:02 ` Pavel Machek
1 sibling, 0 replies; 46+ messages in thread
From: Jacek Anaszewski @ 2016-03-04 9:04 UTC (permalink / raw)
To: Heiner Kallweit; +Cc: linux-leds, Benjamin Tissoires, linux-kernel, linux-usb
Hi Heiner,
Thanks for the updated version. Some nitpicking below.
Please remove "Color" from the patch title.
On 03/01/2016 10:26 PM, Heiner Kallweit wrote:
> Add generic support for RGB Color LED's.
^^^
Ditto.
>
> Basic idea is to use enum led_brightness also for the hue and saturation
> color components.This allows to implement the color extension w/o
> changes to struct led_classdev.
>
> Select LEDS_RGB to enable building drivers using the RGB extension.
>
> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> should be overridden even if the provided values are zero.
>
> Some examples for writing values to /sys/class/leds/<xx>/brightness:
> (now also hex notation can be used)
>
> 255 -> set full brightness and keep existing color if set
> 0 -> switch LED off but keep existing color so that it can be restored
> if the LED is switched on again later
> 0x1000000 -> switch LED off and set also hue and saturation to 0
> 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
>
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
> ---
> v2:
> - move extension-specific code into a separate source file and
> introduce config symbol LEDS_HSV for it
> - create separate patch for the extension to sysfs
> - use variable name led_cdev as in the rest if the core
> - rename to_hsv to led_validate_brightness
> - rename LED_BRIGHTNESS_SET_COLOR to LED_SET_HSV
> - introduce helper is_off for checking whether V part
> of a HSV value is zero
> v3:
> - change Kconfig to use depend instead of select, add help message,
> and change config symbol to LEDS_COLOR
> - change LED core object file name in Makefile
> - rename flag LED_SET_HSV to LED_SET_COLOR
> - rename is_off to led_is_off
> - rename led_validate-brightness to led_confine_brightness
> - rename variable in led_confine_brightness
> - add dummy enum led_brightness value to enforce 32bit enum
> - rename led-hsv-core.c to led-color-core.c
> - move check of provided brightness value to led_confine_brightness
> v4:
> - change config symbol name to LEDS_RGB
> - change name of new file to led-rgb-core.c
> - factor out part of led_confine_brightness
> - change led_is_off to __is_set_brightness
> - in led_set_software_blink pass led_cdev->max_brightness instead of LED_FULL
> - rename LED_SET_COLOR to LED_SET_HUE_SAT
> v5:
> - change "RGB Color LED" to "RGB LED" in Kconfig
> - move definition of LED_HUE_SAT_MASK to drivers/leds/leds.h
> - rename LED_DEV_CAP_HSV to LED_DEV_CAP_RGB
> ---
> drivers/leds/Kconfig | 11 +++++++++++
> drivers/leds/Makefile | 4 +++-
> drivers/leds/led-class.c | 2 +-
> drivers/leds/led-core.c | 16 +++++++++-------
> drivers/leds/led-rgb-core.c | 40 ++++++++++++++++++++++++++++++++++++++++
> drivers/leds/leds.h | 18 ++++++++++++++++++
> include/linux/leds.h | 9 +++++++++
> 7 files changed, 91 insertions(+), 9 deletions(-)
> create mode 100644 drivers/leds/led-rgb-core.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index 7f940c2..5b1c852 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -13,6 +13,13 @@ menuconfig NEW_LEDS
>
> if NEW_LEDS
>
> +config LEDS_RGB
> + bool "RGB LED Support"
> + help
> + This option enables support for RGB LED devices.
> + Sysfs attribute brightness is interpreted as a HSV color value.
> + For details see Documentation/leds/leds-class.txt.
> +
> config LEDS_CLASS
> tristate "LED Class Support"
> help
> @@ -29,6 +36,10 @@ config LEDS_CLASS_FLASH
> for the flash related features of a LED device. It can be built
> as a module.
>
> +if LEDS_RGB
> +comment "RGB LED drivers"
> +endif # LEDS_RGB
> +
> comment "LED drivers"
>
> config LEDS_88PM860X
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index e9d5309..cc3676f 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -1,6 +1,8 @@
>
> # LED Core
> -obj-$(CONFIG_NEW_LEDS) += led-core.o
> +obj-$(CONFIG_NEW_LEDS) += led-core-objs.o
> +led-core-objs-y := led-core.o
> +led-core-objs-$(CONFIG_LEDS_RGB) += led-rgb-core.o
> obj-$(CONFIG_LEDS_CLASS) += led-class.o
> obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
> obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index aa84e5b..007a5b3 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -53,7 +53,7 @@ static ssize_t brightness_store(struct device *dev,
> if (ret)
> goto unlock;
>
> - if (state == LED_OFF)
> + if (!__is_brightness_set(state))
> led_trigger_remove(led_cdev);
> led_set_brightness(led_cdev, state);
>
> diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
> index 3495d5d..e75b0c8 100644
> --- a/drivers/leds/led-core.c
> +++ b/drivers/leds/led-core.c
> @@ -62,7 +62,7 @@ static void led_timer_function(unsigned long data)
> }
>
> brightness = led_get_brightness(led_cdev);
> - if (!brightness) {
> + if (!__is_brightness_set(brightness)) {
> /* Time to switch the LED on. */
> brightness = led_cdev->blink_brightness;
> delay = led_cdev->blink_delay_on;
> @@ -133,8 +133,9 @@ static void led_set_software_blink(struct led_classdev *led_cdev,
> if (current_brightness)
> led_cdev->blink_brightness = current_brightness;
> if (!led_cdev->blink_brightness)
> - led_cdev->blink_brightness = led_cdev->max_brightness;
> -
> + led_cdev->blink_brightness =
> + led_confine_brightness(led_cdev,
> + led_cdev->max_brightness);
> led_cdev->blink_delay_on = delay_on;
> led_cdev->blink_delay_off = delay_off;
>
> @@ -235,12 +236,13 @@ void led_set_brightness(struct led_classdev *led_cdev,
> * work queue task to avoid problems in case we are called
> * from hard irq context.
> */
> - if (brightness == LED_OFF) {
> + if (!__is_brightness_set(brightness)) {
> led_cdev->flags |= LED_BLINK_DISABLE;
> schedule_work(&led_cdev->set_brightness_work);
> } else {
> led_cdev->flags |= LED_BLINK_BRIGHTNESS_CHANGE;
> - led_cdev->blink_brightness = brightness;
> + led_cdev->blink_brightness =
> + led_confine_brightness(led_cdev, brightness);
> }
> return;
> }
> @@ -265,7 +267,7 @@ EXPORT_SYMBOL_GPL(led_set_brightness_nopm);
> void led_set_brightness_nosleep(struct led_classdev *led_cdev,
> enum led_brightness value)
> {
> - led_cdev->brightness = min(value, led_cdev->max_brightness);
> + led_cdev->brightness = led_confine_brightness(led_cdev, value);
>
> if (led_cdev->flags & LED_SUSPENDED)
> return;
> @@ -280,7 +282,7 @@ int led_set_brightness_sync(struct led_classdev *led_cdev,
> if (led_cdev->blink_delay_on || led_cdev->blink_delay_off)
> return -EBUSY;
>
> - led_cdev->brightness = min(value, led_cdev->max_brightness);
> + led_cdev->brightness = led_confine_brightness(led_cdev, value);
>
> if (led_cdev->flags & LED_SUSPENDED)
> return 0;
> diff --git a/drivers/leds/led-rgb-core.c b/drivers/leds/led-rgb-core.c
> new file mode 100644
> index 0000000..f6591f1
> --- /dev/null
> +++ b/drivers/leds/led-rgb-core.c
> @@ -0,0 +1,40 @@
> +/*
> + * LED Class Color Support
> + *
> + * Author: Heiner Kallweit <hkallweit1@gmail.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include <linux/kernel.h>
The seems to be redundant here.
> +#include <linux/leds.h>
> +#include "leds.h"
> +
> +/*
> + * The color extension handles RGB LEDs but uses a HSV color model internally.
> + * led_rgb_adjust_hue_sat sets hue and saturation part of the HSV color value.
> + */
> +static enum led_brightness led_rgb_adjust_hue_sat(struct led_classdev *led_cdev,
> + enum led_brightness value)
> +{
> + /* LED_SET_HUE_SAT sets hue and saturation even if both are zero */
> + if (value & LED_SET_HUE_SAT || value > LED_FULL)
> + return value & LED_HUE_SAT_MASK;
> + else
> + return led_cdev->brightness & ~LED_BRIGHTNESS_MASK;
> +}
> +
> +enum led_brightness led_confine_brightness(struct led_classdev *led_cdev,
> + enum led_brightness value)
> +{
> + enum led_brightness brightness = 0;
> +
> + if (led_cdev->flags & LED_DEV_CAP_RGB)
> + brightness = led_rgb_adjust_hue_sat(led_cdev, value);
> +
> + return brightness |
> + min(value & LED_BRIGHTNESS_MASK, led_cdev->max_brightness);
> +}
> diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
> index db3f20d..b853f54 100644
> --- a/drivers/leds/leds.h
> +++ b/drivers/leds/leds.h
> @@ -16,17 +16,35 @@
> #include <linux/rwsem.h>
> #include <linux/leds.h>
>
> +#define LED_BRIGHTNESS_MASK 0x000000ff
> +#define LED_HUE_SAT_MASK 0x00ffff00
> +
> static inline int led_get_brightness(struct led_classdev *led_cdev)
> {
> return led_cdev->brightness;
> }
>
> +static inline bool __is_brightness_set(enum led_brightness brightness)
> +{
> + return (brightness & LED_BRIGHTNESS_MASK) != LED_OFF;
> +}
> +
> void led_init_core(struct led_classdev *led_cdev);
> void led_stop_software_blink(struct led_classdev *led_cdev);
> void led_set_brightness_nopm(struct led_classdev *led_cdev,
> enum led_brightness value);
> void led_set_brightness_nosleep(struct led_classdev *led_cdev,
> enum led_brightness value);
> +#if IS_ENABLED(CONFIG_LEDS_RGB)
> +enum led_brightness led_confine_brightness(struct led_classdev *led_cdev,
> + enum led_brightness value);
> +#else
> +static inline enum led_brightness led_confine_brightness(
> + struct led_classdev *led_cdev, enum led_brightness value)
> +{
> + return min(value, led_cdev->max_brightness);
> +}
> +#endif
>
> extern struct rw_semaphore leds_list_lock;
> extern struct list_head leds_list;
> diff --git a/include/linux/leds.h b/include/linux/leds.h
> index f203a8f..bbf24bb 100644
> --- a/include/linux/leds.h
> +++ b/include/linux/leds.h
> @@ -29,8 +29,16 @@ enum led_brightness {
> LED_OFF = 0,
> LED_HALF = 127,
> LED_FULL = 255,
> + /*
> + * dummy enum value to make gcc use a 32 bit type for the enum
> + * even if compiled with -fshort-enums. This is needed for
> + * the enum to store hsv values.
> + */
> + LED_LEVEL_DUMMY = 0xffffffff,
> };
>
> +#define LED_SET_HUE_SAT BIT(24)
> +
> struct led_classdev {
> const char *name;
> enum led_brightness brightness;
> @@ -50,6 +58,7 @@ struct led_classdev {
> #define LED_SYSFS_DISABLE (1 << 22)
> #define LED_DEV_CAP_FLASH (1 << 23)
> #define LED_HW_PLUGGABLE (1 << 24)
> +#define LED_DEV_CAP_RGB (1 << 25)
Please keep CAP flags next to each other. You can change values
of the existing flags, they're internal to kernel.
>
> /* Set LED brightness level
> * Must not sleep. Use brightness_set_blocking for drivers
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-01 21:26 [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's Heiner Kallweit
2016-03-04 9:04 ` Jacek Anaszewski
@ 2016-03-29 10:02 ` Pavel Machek
2016-03-29 20:38 ` Heiner Kallweit
1 sibling, 1 reply; 46+ messages in thread
From: Pavel Machek @ 2016-03-29 10:02 UTC (permalink / raw)
To: Heiner Kallweit, Greg KH
Cc: Jacek Anaszewski, linux-leds, Benjamin Tissoires, linux-kernel,
linux-usb
Hi!
First, please Cc me on RGB color support.
> Add generic support for RGB Color LED's.
>
> Basic idea is to use enum led_brightness also for the hue and saturation
> color components.This allows to implement the color extension w/o
> changes to struct led_classdev.
>
> Select LEDS_RGB to enable building drivers using the RGB extension.
>
> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> should be overridden even if the provided values are zero.
>
> Some examples for writing values to /sys/class/leds/<xx>/brightness:
> (now also hex notation can be used)
>
> 255 -> set full brightness and keep existing color if set
> 0 -> switch LED off but keep existing color so that it can be restored
> if the LED is switched on again later
> 0x1000000 -> switch LED off and set also hue and saturation to 0
> 0x00ffff -> set full brightness, full saturation and set hue to 0
> (red)
Umm, that's rather strange interface -- and three values in single sysfs
file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which
we already have supported in the tree. (At least nokia N900 and Sony
motion controller already contain supported three-color LEDs).
Now... yes, there's work to be done for the 3-color LEDs. Currently,
they are treated as three different LEDs. (Which makes some sense, you
can use "battery charging" trigger for LED, and CPU activity trigger
for green, for example). It would be good to have some kind of
grouping, so that userspace can tell "these 3 leds are actually
combined into one light".
Second, we should define that LED brightness has similar gamma to the
monitor, so that expected colors are displayed when user requests
them.
(And then.. I guess we should talk about more advanced stuff, like
hardware that can drive the LED changes independently of the main
CPU.)
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 10:02 ` Pavel Machek
@ 2016-03-29 20:38 ` Heiner Kallweit
2016-03-29 21:43 ` Pavel Machek
2016-03-30 7:57 ` Jacek Anaszewski
0 siblings, 2 replies; 46+ messages in thread
From: Heiner Kallweit @ 2016-03-29 20:38 UTC (permalink / raw)
To: Pavel Machek, Greg KH
Cc: Jacek Anaszewski, linux-leds, Benjamin Tissoires, linux-kernel,
linux-usb
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> Hi!
>
> First, please Cc me on RGB color support.
>
>> Add generic support for RGB Color LED's.
>>
>> Basic idea is to use enum led_brightness also for the hue and saturation
>> color components.This allows to implement the color extension w/o
>> changes to struct led_classdev.
>>
>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>
>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>> should be overridden even if the provided values are zero.
>>
>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>> (now also hex notation can be used)
>>
>> 255 -> set full brightness and keep existing color if set
>> 0 -> switch LED off but keep existing color so that it can be restored
>> if the LED is switched on again later
>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>> (red)
>
> Umm, that's rather strange interface -- and three values in single sysfs
> file is actually forbidden.
>
> Plus, it is very much unlike existing interfaces for RGB LEDs, which
> we already have supported in the tree. (At least nokia N900 and Sony
> motion controller already contain supported three-color LEDs).
>
> Now... yes, there's work to be done for the 3-color LEDs. Currently,
> they are treated as three different LEDs. (Which makes some sense, you
> can use "battery charging" trigger for LED, and CPU activity trigger
> for green, for example). It would be good to have some kind of
> grouping, so that userspace can tell "these 3 leds are actually
> combined into one light".
>
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices
might have been implemented due to the lack of alternatives.
With one trigger controlling the red LED and another controlling the green
LED we may end up with a yellow light. Not sure whether this is what we want.
One driver for this extension was the idea of triggers using color
to visualize states etc.
Therefore it's not only about userspace controlling the color.
As a trigger is bound to a led_classdev we need a led_classdev
representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate
attributes for hue, saturation, and (existing) brightness.
Rgds, Heiner
>
> Second, we should define that LED brightness has similar gamma to the
> monitor, so that expected colors are displayed when user requests
> them.
>
> (And then.. I guess we should talk about more advanced stuff, like
> hardware that can drive the LED changes independently of the main
> CPU.)
>
> Best regards,
> Pavel
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 20:38 ` Heiner Kallweit
@ 2016-03-29 21:43 ` Pavel Machek
2016-03-29 22:03 ` Pavel Machek
` (2 more replies)
2016-03-30 7:57 ` Jacek Anaszewski
1 sibling, 3 replies; 46+ messages in thread
From: Pavel Machek @ 2016-03-29 21:43 UTC (permalink / raw)
To: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge
Cc: Greg KH, Jacek Anaszewski, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb
Hi!
> > First, please Cc me on RGB color support.
> >
> >> Add generic support for RGB Color LED's.
> >>
> >> Basic idea is to use enum led_brightness also for the hue and saturation
> >> color components.This allows to implement the color extension w/o
> >> changes to struct led_classdev.
> >>
> >> Select LEDS_RGB to enable building drivers using the RGB extension.
> >>
> >> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> >> should be overridden even if the provided values are zero.
> >>
> >> Some examples for writing values to /sys/class/leds/<xx>/brightness:
> >> (now also hex notation can be used)
> >>
> >> 255 -> set full brightness and keep existing color if set
> >> 0 -> switch LED off but keep existing color so that it can be restored
> >> if the LED is switched on again later
> >> 0x1000000 -> switch LED off and set also hue and saturation to 0
> >> 0x00ffff -> set full brightness, full saturation and set hue to 0
> >> (red)
> >
> > Umm, that's rather strange interface -- and three values in single sysfs
> > file is actually forbidden.
> >
> > Plus, it is very much unlike existing interfaces for RGB LEDs, which
> > we already have supported in the tree. (At least nokia N900 and Sony
> > motion controller already contain supported three-color LEDs).
> >
> > Now... yes, there's work to be done for the 3-color LEDs. Currently,
> > they are treated as three different LEDs. (Which makes some sense, you
> > can use "battery charging" trigger for LED, and CPU activity trigger
> > for green, for example). It would be good to have some kind of
> > grouping, so that userspace can tell "these 3 leds are actually
> > combined into one light".
> >
> At first thanks for the review comments.
> Treating the three physical LEDs of a RGB LED as separate LED devices
> might have been implemented due to the lack of alternatives.
To be fair... they _are_ separate LED devices. In N900 case, you can
even see light comming from slightly different places if you look closely.
> With one trigger controlling the red LED and another controlling the green
> LED we may end up with a yellow light. Not sure whether this is what
> we want.
Well, it should be understandable for most people.
> One driver for this extension was the idea of triggers using color
> to visualize states etc.
> Therefore it's not only about userspace controlling the color.
> As a trigger is bound to a led_classdev we need a led_classdev
> representing a RGB LED device.
>
> And ok: If required the sysfs interface can be splitted into separate
> attributes for hue, saturation, and (existing) brightness.
Required.
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we
need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
and it is what hardware implements. (But we'd need to do gamma
correction).
c) My hardware has "acceleration engine", LED is independend from
CPU. That's rather big deal. Does yours? It seems to be quite common,
at least in cellphones.
Ideally, I'd like to have "triggers", but different ones. As in: if
charging, do yellow " .xX" pattern. If fully charged, do green steady
light. If message is waiting, do blue " x x" pattern. If none of
above, do slow white blinking. (Plus priorities of events). But that's
quite different from existing support...)
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 21:43 ` Pavel Machek
@ 2016-03-29 22:03 ` Pavel Machek
2016-03-30 5:58 ` Heiner Kallweit
2016-03-30 8:07 ` Jacek Anaszewski
2 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-03-29 22:03 UTC (permalink / raw)
To: Heiner Kallweit, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, khilman-DgEjT+Ai2ygdnm+yROfE0A,
aaro.koskinen-X3B1VOXEql0,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
patrikbachan-Re5JQEeQqe8AvxtiuMwx3w,
serge-A9i7LUbDfNHQT0dZR+AlfA
Cc: Greg KH, Jacek Anaszewski, linux-leds-u79uwXL29TY76Z2rM5mHXA,
Benjamin Tissoires, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Hi!
> > One driver for this extension was the idea of triggers using color
> > to visualize states etc.
> > Therefore it's not only about userspace controlling the color.
> > As a trigger is bound to a led_classdev we need a led_classdev
> > representing a RGB LED device.
> >
> > And ok: If required the sysfs interface can be splitted into separate
> > attributes for hue, saturation, and (existing) brightness.
>
> Required.
>
> Ok, so:
>
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
And subquestion: if using existing subsystem, should the RGB led be
one led, or three?
Kernel currently uses three leds for one RGB led, and even before
that, there were leds such as "charging::yellow", "charging::green"
that were as close as leds in RGB module are.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
@ 2016-03-29 22:03 ` Pavel Machek
0 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-03-29 22:03 UTC (permalink / raw)
To: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge
Cc: Greg KH, Jacek Anaszewski, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb
Hi!
> > One driver for this extension was the idea of triggers using color
> > to visualize states etc.
> > Therefore it's not only about userspace controlling the color.
> > As a trigger is bound to a led_classdev we need a led_classdev
> > representing a RGB LED device.
> >
> > And ok: If required the sysfs interface can be splitted into separate
> > attributes for hue, saturation, and (existing) brightness.
>
> Required.
>
> Ok, so:
>
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
And subquestion: if using existing subsystem, should the RGB led be
one led, or three?
Kernel currently uses three leds for one RGB led, and even before
that, there were leds such as "charging::yellow", "charging::green"
that were as close as leds in RGB module are.
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 21:43 ` Pavel Machek
2016-03-29 22:03 ` Pavel Machek
@ 2016-03-30 5:58 ` Heiner Kallweit
2016-04-01 12:52 ` Pavel Machek
2016-03-30 8:07 ` Jacek Anaszewski
2 siblings, 1 reply; 46+ messages in thread
From: Heiner Kallweit @ 2016-03-30 5:58 UTC (permalink / raw)
To: Pavel Machek, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge
Cc: Greg KH, Jacek Anaszewski, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb
Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
>>>> Add generic support for RGB Color LED's.
>>>>
>>>> Basic idea is to use enum led_brightness also for the hue and saturation
>>>> color components.This allows to implement the color extension w/o
>>>> changes to struct led_classdev.
>>>>
>>>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>>>
>>>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>>>> should be overridden even if the provided values are zero.
>>>>
>>>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>>>> (now also hex notation can be used)
>>>>
>>>> 255 -> set full brightness and keep existing color if set
>>>> 0 -> switch LED off but keep existing color so that it can be restored
>>>> if the LED is switched on again later
>>>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>>>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>>>> (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
>
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
>
I mainly work with encapsulated USB HID LED devices like Thingm blink(1).
Due to the diffuse plastic cover you don't see the individual LEDs on the chip.
>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
>
> Well, it should be understandable for most people.
>
>> One driver for this extension was the idea of triggers using color
>> to visualize states etc.
>> Therefore it's not only about userspace controlling the color.
>> As a trigger is bound to a led_classdev we need a led_classdev
>> representing a RGB LED device.
>>
>> And ok: If required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
>
> Required.
>
> Ok, so:
>
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
>
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
>
HSV has the charme that the current monochrome V-only is a subset.
Therefore the current API can be used also with color LEDs.
However there might be good reasons for using RGB too.
> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
>
Devices like blink(1) support storing and re-playing patterns, fading etc.
> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
>
I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED
device. Most likely you don't want to split yellow into its red + green
component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange
is nicer than yellow.
> Pavel
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 5:58 ` Heiner Kallweit
@ 2016-04-01 12:52 ` Pavel Machek
0 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 12:52 UTC (permalink / raw)
To: Heiner Kallweit
Cc: pali.rohar, sre, khilman, aaro.koskinen, ivo.g.dimitrov.75,
patrikbachan, serge, Greg KH, Jacek Anaszewski, linux-leds,
Benjamin Tissoires, linux-kernel, linux-usb
Hi!
> > To be fair... they _are_ separate LED devices. In N900 case, you can
> > even see light comming from slightly different places if you look closely.
> >
> I mainly work with encapsulated USB HID LED devices like Thingm blink(1).
> Due to the diffuse plastic cover you don't see the individual LEDs on the chip.
Yeah, so on N900, you can't really see the individual LEDs, either.
But white is not uniform white.
On PS/3 motion controller (another device that is already supported),
diffusing works a bit better.
> > Required.
> >
> > Ok, so:
> >
> > a) Do we want RGB leds to be handled by existing subsystem, or do we
> > need separate layer on top of that?
> >
> > b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> > and it is what hardware implements. (But we'd need to do gamma
> > correction).
> >
> HSV has the charme that the current monochrome V-only is a subset.
> Therefore the current API can be used also with color LEDs.
> However there might be good reasons for using RGB too.
Yes, nice, but we already have RGB LED support in kernel, and it looks
different from what is proposed here. And quite incompatible.
> > c) My hardware has "acceleration engine", LED is independend from
> > CPU. That's rather big deal. Does yours? It seems to be quite common,
> > at least in cellphones.
> >
> Devices like blink(1) support storing and re-playing patterns, fading etc.
>
> > Ideally, I'd like to have "triggers", but different ones. As in: if
> > charging, do yellow " .xX" pattern. If fully charged, do green steady
> > light. If message is waiting, do blue " x x" pattern. If none of
> > above, do slow white blinking. (Plus priorities of events). But that's
> > quite different from existing support...)
> >
> I think for this a separate layer would be helpful.
> Your primary intention is to e.g. display "charging" on the RGB LED
> device. Most likely you don't want to split yellow into its red + green
> component and then write to the respective (sub-)LEDs.
> Also just think of the case that later you might decide that orange
> is nicer than yellow.
Well, so what about keeping existing red/green/blue LED devices (to
stay backward compatible) and then add separate device that links to
these, and controls patterns and colors?
Small complication is that (at least on N900) the pattern capability
can control keyboard backlight LEDs, too. It has nine channels, and
you select 3 channels that are connected to pattern generator.
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 21:43 ` Pavel Machek
@ 2016-03-30 8:07 ` Jacek Anaszewski
2016-03-30 5:58 ` Heiner Kallweit
2016-03-30 8:07 ` Jacek Anaszewski
2 siblings, 0 replies; 46+ messages in thread
From: Jacek Anaszewski @ 2016-03-30 8:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Heiner Kallweit, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, khilman-DgEjT+Ai2ygdnm+yROfE0A,
aaro.koskinen-X3B1VOXEql0,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
patrikbachan-Re5JQEeQqe8AvxtiuMwx3w,
serge-A9i7LUbDfNHQT0dZR+AlfA, Greg KH,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Benjamin Tissoires,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
On 03/29/2016 11:43 PM, Pavel Machek wrote:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
>>>> Add generic support for RGB Color LED's.
>>>>
>>>> Basic idea is to use enum led_brightness also for the hue and saturation
>>>> color components.This allows to implement the color extension w/o
>>>> changes to struct led_classdev.
>>>>
>>>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>>>
>>>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>>>> should be overridden even if the provided values are zero.
>>>>
>>>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>>>> (now also hex notation can be used)
>>>>
>>>> 255 -> set full brightness and keep existing color if set
>>>> 0 -> switch LED off but keep existing color so that it can be restored
>>>> if the LED is switched on again later
>>>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>>>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>>>> (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
>
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
>
>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
>
> Well, it should be understandable for most people.
>
>> One driver for this extension was the idea of triggers using color
>> to visualize states etc.
>> Therefore it's not only about userspace controlling the color.
>> As a trigger is bound to a led_classdev we need a led_classdev
>> representing a RGB LED device.
>>
>> And ok: If required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
>
> Required.
>
> Ok, so:
>
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
>
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
>
> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
>
> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
Please note that HSV colour scheme allows to neatly project monochrome
brightness semantics on the RGB realm. I.e. you can have fixed
hue and saturation, and by changing the brightness component a perceived
colour intensity can be altered.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
@ 2016-03-30 8:07 ` Jacek Anaszewski
0 siblings, 0 replies; 46+ messages in thread
From: Jacek Anaszewski @ 2016-03-30 8:07 UTC (permalink / raw)
To: Pavel Machek
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, linux-kernel, linux-usb
On 03/29/2016 11:43 PM, Pavel Machek wrote:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
>>>> Add generic support for RGB Color LED's.
>>>>
>>>> Basic idea is to use enum led_brightness also for the hue and saturation
>>>> color components.This allows to implement the color extension w/o
>>>> changes to struct led_classdev.
>>>>
>>>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>>>
>>>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>>>> should be overridden even if the provided values are zero.
>>>>
>>>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>>>> (now also hex notation can be used)
>>>>
>>>> 255 -> set full brightness and keep existing color if set
>>>> 0 -> switch LED off but keep existing color so that it can be restored
>>>> if the LED is switched on again later
>>>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>>>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>>>> (red)
>>>
>>> Umm, that's rather strange interface -- and three values in single sysfs
>>> file is actually forbidden.
>>>
>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>> we already have supported in the tree. (At least nokia N900 and Sony
>>> motion controller already contain supported three-color LEDs).
>>>
>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>> they are treated as three different LEDs. (Which makes some sense, you
>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>> for green, for example). It would be good to have some kind of
>>> grouping, so that userspace can tell "these 3 leds are actually
>>> combined into one light".
>>>
>> At first thanks for the review comments.
>> Treating the three physical LEDs of a RGB LED as separate LED devices
>> might have been implemented due to the lack of alternatives.
>
> To be fair... they _are_ separate LED devices. In N900 case, you can
> even see light comming from slightly different places if you look closely.
>
>> With one trigger controlling the red LED and another controlling the green
>> LED we may end up with a yellow light. Not sure whether this is what
>> we want.
>
> Well, it should be understandable for most people.
>
>> One driver for this extension was the idea of triggers using color
>> to visualize states etc.
>> Therefore it's not only about userspace controlling the color.
>> As a trigger is bound to a led_classdev we need a led_classdev
>> representing a RGB LED device.
>>
>> And ok: If required the sysfs interface can be splitted into separate
>> attributes for hue, saturation, and (existing) brightness.
>
> Required.
>
> Ok, so:
>
> a) Do we want RGB leds to be handled by existing subsystem, or do we
> need separate layer on top of that?
>
> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> and it is what hardware implements. (But we'd need to do gamma
> correction).
>
> c) My hardware has "acceleration engine", LED is independend from
> CPU. That's rather big deal. Does yours? It seems to be quite common,
> at least in cellphones.
>
> Ideally, I'd like to have "triggers", but different ones. As in: if
> charging, do yellow " .xX" pattern. If fully charged, do green steady
> light. If message is waiting, do blue " x x" pattern. If none of
> above, do slow white blinking. (Plus priorities of events). But that's
> quite different from existing support...)
Please note that HSV colour scheme allows to neatly project monochrome
brightness semantics on the RGB realm. I.e. you can have fixed
hue and saturation, and by changing the brightness component a perceived
colour intensity can be altered.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 8:07 ` Jacek Anaszewski
(?)
@ 2016-03-30 13:03 ` Pavel Machek
2016-03-30 13:59 ` Heiner Kallweit
-1 siblings, 1 reply; 46+ messages in thread
From: Pavel Machek @ 2016-03-30 13:03 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, linux-kernel, linux-usb
Hi!
> >Ok, so:
> >
> >a) Do we want RGB leds to be handled by existing subsystem, or do we
> >need separate layer on top of that?
> >
> >b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
> >and it is what hardware implements. (But we'd need to do gamma
> >correction).
> >
> >c) My hardware has "acceleration engine", LED is independend from
> >CPU. That's rather big deal. Does yours? It seems to be quite common,
> >at least in cellphones.
> >
> >Ideally, I'd like to have "triggers", but different ones. As in: if
> >charging, do yellow " .xX" pattern. If fully charged, do green steady
> >light. If message is waiting, do blue " x x" pattern. If none of
> >above, do slow white blinking. (Plus priorities of events). But that's
> >quite different from existing support...)
>
> Please note that HSV colour scheme allows to neatly project monochrome
> brightness semantics on the RGB realm. I.e. you can have fixed
> hue and saturation, and by changing the brightness component a perceived
> colour intensity can be altered.
I see HSV has some advantages. But we already have LEDs with multiple
colors, and kernel already handles them:
pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
This is physically 2 leds but hidden under one indicator, so you got
"off", "green", "orange" and "green+orange".
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 13:03 ` Pavel Machek
@ 2016-03-30 13:59 ` Heiner Kallweit
2016-03-31 8:17 ` Jacek Anaszewski
2016-04-01 12:55 ` Pavel Machek
0 siblings, 2 replies; 46+ messages in thread
From: Heiner Kallweit @ 2016-03-30 13:59 UTC (permalink / raw)
To: Pavel Machek
Cc: Jacek Anaszewski, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >Ok, so:
>> >
>> >a) Do we want RGB leds to be handled by existing subsystem, or do we
>> >need separate layer on top of that?
>> >
>> >b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
>> >and it is what hardware implements. (But we'd need to do gamma
>> >correction).
>> >
>> >c) My hardware has "acceleration engine", LED is independend from
>> >CPU. That's rather big deal. Does yours? It seems to be quite common,
>> >at least in cellphones.
>> >
>> >Ideally, I'd like to have "triggers", but different ones. As in: if
>> >charging, do yellow " .xX" pattern. If fully charged, do green steady
>> >light. If message is waiting, do blue " x x" pattern. If none of
>> >above, do slow white blinking. (Plus priorities of events). But that's
>> >quite different from existing support...)
>>
>> Please note that HSV colour scheme allows to neatly project monochrome
>> brightness semantics on the RGB realm. I.e. you can have fixed
>> hue and saturation, and by changing the brightness component a perceived
>> colour intensity can be altered.
>
> I see HSV has some advantages. But we already have LEDs with multiple
> colors, and kernel already handles them:
>
> pavel@duo:~$ ls -1 /sys/class/leds/
> tpacpi:green:batt
> tpacpi:orange:batt
>
> This is physically 2 leds but hidden under one indicator, so you got
> "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as
separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
but "multiple
LED devices".
In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
And it's not only about using a handful of discrete colors but about
displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only
and I can't use
a trigger to e.g. set "magenta with 50% brightness".
Heiner
> 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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 13:59 ` Heiner Kallweit
@ 2016-03-31 8:17 ` Jacek Anaszewski
2016-04-01 12:55 ` Pavel Machek
1 sibling, 0 replies; 46+ messages in thread
From: Jacek Anaszewski @ 2016-03-31 8:17 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Pavel Machek, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
Hi Heiner,
On 03/30/2016 03:59 PM, Heiner Kallweit wrote:
> On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>>> Ok, so:
>>>>
>>>> a) Do we want RGB leds to be handled by existing subsystem, or do we
>>>> need separate layer on top of that?
>>>>
>>>> b) Does RGB make sense, or HSV? RGB is quite widely used in graphics,
>>>> and it is what hardware implements. (But we'd need to do gamma
>>>> correction).
>>>>
>>>> c) My hardware has "acceleration engine", LED is independend from
>>>> CPU. That's rather big deal. Does yours? It seems to be quite common,
>>>> at least in cellphones.
>>>>
>>>> Ideally, I'd like to have "triggers", but different ones. As in: if
>>>> charging, do yellow " .xX" pattern. If fully charged, do green steady
>>>> light. If message is waiting, do blue " x x" pattern. If none of
>>>> above, do slow white blinking. (Plus priorities of events). But that's
>>>> quite different from existing support...)
>>>
>>> Please note that HSV colour scheme allows to neatly project monochrome
>>> brightness semantics on the RGB realm. I.e. you can have fixed
>>> hue and saturation, and by changing the brightness component a perceived
>>> colour intensity can be altered.
>>
>> I see HSV has some advantages. But we already have LEDs with multiple
>> colors, and kernel already handles them:
>>
>> pavel@duo:~$ ls -1 /sys/class/leds/
>> tpacpi:green:batt
>> tpacpi:orange:batt
>>
>> This is physically 2 leds but hidden under one indicator, so you got
>> "off", "green", "orange" and "green+orange".
>
> That's a good example. As long as you can recognize green+orange as
> separate lights/colors
> (w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
> but "multiple
> LED devices".
>
> In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
> And it's not only about using a handful of discrete colors but about
> displaying any arbitrary
> color.
> So far the kernel exposes the physical RGB LEDs as separate LEDs only
> and I can't use
> a trigger to e.g. set "magenta with 50% brightness".
I think that we should consult more people before pushing the solution
upstream. Would you mind writing a message with an explanation of the
issue to linux-api list?
Please keep in mind also the information from the "Attributes" section
of Documentation/filesystems/sysfs.txt.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 13:59 ` Heiner Kallweit
2016-03-31 8:17 ` Jacek Anaszewski
@ 2016-04-01 12:55 ` Pavel Machek
2016-04-01 13:28 ` Jacek Anaszewski
1 sibling, 1 reply; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 12:55 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Jacek Anaszewski, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
Hi!
> > pavel@duo:~$ ls -1 /sys/class/leds/
> > tpacpi:green:batt
> > tpacpi:orange:batt
> >
> > This is physically 2 leds but hidden under one indicator, so you got
> > "off", "green", "orange" and "green+orange".
>
> That's a good example. As long as you can recognize green+orange as
> separate lights/colors
> (w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
> but "multiple
> LED devices".
Well, that's how it is currently handled. But for the user, it looks
as a LED with multiple colors.
> In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
> And it's not only about using a handful of discrete colors but about
> displaying any arbitrary
> color.
> So far the kernel exposes the physical RGB LEDs as separate LEDs only
> and I can't use
> a trigger to e.g. set "magenta with 50% brightness".
Why not?
What do you do if you want to display magenta on your LCD?
You compute RGB values, then display them.
What would you do for the LEDs? Same thing.
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-04-01 12:55 ` Pavel Machek
@ 2016-04-01 13:28 ` Jacek Anaszewski
2016-04-01 14:07 ` Pavel Machek
0 siblings, 1 reply; 46+ messages in thread
From: Jacek Anaszewski @ 2016-04-01 13:28 UTC (permalink / raw)
To: Pavel Machek
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
On 04/01/2016 02:55 PM, Pavel Machek wrote:
> Hi!
>
>>> pavel@duo:~$ ls -1 /sys/class/leds/
>>> tpacpi:green:batt
>>> tpacpi:orange:batt
>>>
>>> This is physically 2 leds but hidden under one indicator, so you got
>>> "off", "green", "orange" and "green+orange".
>>
>> That's a good example. As long as you can recognize green+orange as
>> separate lights/colors
>> (w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
>> but "multiple
>> LED devices".
>
> Well, that's how it is currently handled. But for the user, it looks
> as a LED with multiple colors.
>
>> In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
>> And it's not only about using a handful of discrete colors but about
>> displaying any arbitrary
>> color.
>> So far the kernel exposes the physical RGB LEDs as separate LEDs only
>> and I can't use
>> a trigger to e.g. set "magenta with 50% brightness".
>
> Why not?
>
> What do you do if you want to display magenta on your LCD?
>
> You compute RGB values, then display them.
The main drawback is that you can't set the colour at one go,
but have to set brightness of each LED class device (R,G,B)
separately. It incurs delays between setting each colour component.
It is also impossible to set arbitrary colour from a trigger.
Similarly blinking with arbitrarily chosen colour from RGB palette
is impossible if separate colour components are treated as
separate LEDs.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-04-01 13:28 ` Jacek Anaszewski
@ 2016-04-01 14:07 ` Pavel Machek
2016-04-01 14:27 ` Jacek Anaszewski
0 siblings, 1 reply; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 14:07 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
Hi!
> >>>pavel@duo:~$ ls -1 /sys/class/leds/
> >>>tpacpi:green:batt
> >>>tpacpi:orange:batt
> >>>
> >>>This is physically 2 leds but hidden under one indicator, so you got
> >>>"off", "green", "orange" and "green+orange".
> >>
> >>That's a good example. As long as you can recognize green+orange as
> >>separate lights/colors
> >>(w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
> >>but "multiple
> >>LED devices".
> >
> >Well, that's how it is currently handled. But for the user, it looks
> >as a LED with multiple colors.
> >
> >>In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
> >>And it's not only about using a handful of discrete colors but about
> >>displaying any arbitrary
> >>color.
> >>So far the kernel exposes the physical RGB LEDs as separate LEDs only
> >>and I can't use
> >>a trigger to e.g. set "magenta with 50% brightness".
> >
> >Why not?
> >
> >What do you do if you want to display magenta on your LCD?
> >
> >You compute RGB values, then display them.
>
> The main drawback is that you can't set the colour at one go,
> but have to set brightness of each LED class device (R,G,B)
> separately. It incurs delays between setting each colour component.
Yeah. Well, on some hardware, that's just the way it is. If the leds
are separate devices on i2c, you can't really set them in one go.
But some hardware has hardware pattern controls, and it can set them
atomically.
> It is also impossible to set arbitrary colour from a trigger.
> Similarly blinking with arbitrarily chosen colour from RGB palette
> is impossible if separate colour components are treated as
> separate LEDs.
Yes, see the proposal in the other mail. I believe we should have
separate R, G, B LED devices, and separate pattern controller.
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-04-01 14:07 ` Pavel Machek
@ 2016-04-01 14:27 ` Jacek Anaszewski
2016-04-01 15:03 ` Pavel Machek
0 siblings, 1 reply; 46+ messages in thread
From: Jacek Anaszewski @ 2016-04-01 14:27 UTC (permalink / raw)
To: Pavel Machek
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
On 04/01/2016 04:07 PM, Pavel Machek wrote:
> Hi!
>
>>>>> pavel@duo:~$ ls -1 /sys/class/leds/
>>>>> tpacpi:green:batt
>>>>> tpacpi:orange:batt
>>>>>
>>>>> This is physically 2 leds but hidden under one indicator, so you got
>>>>> "off", "green", "orange" and "green+orange".
>>>>
>>>> That's a good example. As long as you can recognize green+orange as
>>>> separate lights/colors
>>>> (w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
>>>> but "multiple
>>>> LED devices".
>>>
>>> Well, that's how it is currently handled. But for the user, it looks
>>> as a LED with multiple colors.
>>>
>>>> In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
>>>> And it's not only about using a handful of discrete colors but about
>>>> displaying any arbitrary
>>>> color.
>>>> So far the kernel exposes the physical RGB LEDs as separate LEDs only
>>>> and I can't use
>>>> a trigger to e.g. set "magenta with 50% brightness".
>>>
>>> Why not?
>>>
>>> What do you do if you want to display magenta on your LCD?
>>>
>>> You compute RGB values, then display them.
>>
>> The main drawback is that you can't set the colour at one go,
>> but have to set brightness of each LED class device (R,G,B)
>> separately. It incurs delays between setting each colour component.
>
> Yeah. Well, on some hardware, that's just the way it is. If the leds
> are separate devices on i2c, you can't really set them in one go.
Delays can occur even if the LEDs are controlled by the same device.
Brightness of each LED class device is set with separate system
call and there will be always some time shift between particular I2C
transmissions that set the brightness for each sub-LED.
If the three sub-LEDs were controlled by a single LED class device
then we could setup the brightness of each sub-LED with single I2C
transmission.
> But some hardware has hardware pattern controls, and it can set them
> atomically.
>
>> It is also impossible to set arbitrary colour from a trigger.
>> Similarly blinking with arbitrarily chosen colour from RGB palette
>> is impossible if separate colour components are treated as
>> separate LEDs.
>
> Yes, see the proposal in the other mail. I believe we should have
> separate R, G, B LED devices, and separate pattern controller.
>
> Best regards,
> Pavel
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-04-01 14:27 ` Jacek Anaszewski
@ 2016-04-01 15:03 ` Pavel Machek
0 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 15:03 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, Linux Kernel Mailing List,
Linux USB Mailing List
Hi!
> >>The main drawback is that you can't set the colour at one go,
> >>but have to set brightness of each LED class device (R,G,B)
> >>separately. It incurs delays between setting each colour component.
> >
> >Yeah. Well, on some hardware, that's just the way it is. If the leds
> >are separate devices on i2c, you can't really set them in one go.
>
> Delays can occur even if the LEDs are controlled by the same device.
> Brightness of each LED class device is set with separate system
> call and there will be always some time shift between particular I2C
> transmissions that set the brightness for each sub-LED.
>
> If the three sub-LEDs were controlled by a single LED class device
> then we could setup the brightness of each sub-LED with single I2C
> transmission.
Ok, well, yes, maybe you could.
You can still do that with the proposed interface, but yes, it will be
trickier.
OTOH proposed interface will also help with the hardware pattern
support, will work with existing leds, and matches the way hardware
works. So I believe it is worth it.
Best regards,
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] 46+ messages in thread
[parent not found: <56FB893C.60203-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>]
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 8:07 ` Jacek Anaszewski
@ 2016-04-01 12:53 ` Pavel Machek
-1 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 12:53 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
sre-DgEjT+Ai2ygdnm+yROfE0A, khilman-DgEjT+Ai2ygdnm+yROfE0A,
aaro.koskinen-X3B1VOXEql0,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
patrikbachan-Re5JQEeQqe8AvxtiuMwx3w,
serge-A9i7LUbDfNHQT0dZR+AlfA, Greg KH,
linux-leds-u79uwXL29TY76Z2rM5mHXA, Benjamin Tissoires,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
Hi!
> >Ideally, I'd like to have "triggers", but different ones. As in: if
> >charging, do yellow " .xX" pattern. If fully charged, do green steady
> >light. If message is waiting, do blue " x x" pattern. If none of
> >above, do slow white blinking. (Plus priorities of events). But that's
> >quite different from existing support...)
>
> Please note that HSV colour scheme allows to neatly project monochrome
> brightness semantics on the RGB realm. I.e. you can have fixed
> hue and saturation, and by changing the brightness component a perceived
> colour intensity can be altered.
Yes, that's nice, but it is incompatible with already existing RGB
support in kernel. Plus, echoing hue into file called brightness is
extremely ugly, and it violates sysfs rules.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
@ 2016-04-01 12:53 ` Pavel Machek
0 siblings, 0 replies; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 12:53 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, patrikbachan, serge, Greg KH, linux-leds,
Benjamin Tissoires, linux-kernel, linux-usb
Hi!
> >Ideally, I'd like to have "triggers", but different ones. As in: if
> >charging, do yellow " .xX" pattern. If fully charged, do green steady
> >light. If message is waiting, do blue " x x" pattern. If none of
> >above, do slow white blinking. (Plus priorities of events). But that's
> >quite different from existing support...)
>
> Please note that HSV colour scheme allows to neatly project monochrome
> brightness semantics on the RGB realm. I.e. you can have fixed
> hue and saturation, and by changing the brightness component a perceived
> colour intensity can be altered.
Yes, that's nice, but it is incompatible with already existing RGB
support in kernel. Plus, echoing hue into file called brightness is
extremely ugly, and it violates sysfs rules.
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-29 20:38 ` Heiner Kallweit
2016-03-29 21:43 ` Pavel Machek
@ 2016-03-30 7:57 ` Jacek Anaszewski
2016-04-01 13:57 ` Pavel Machek
1 sibling, 1 reply; 46+ messages in thread
From: Jacek Anaszewski @ 2016-03-30 7:57 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Pavel Machek, Greg KH, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb
Hi Heiner and Pavel,
On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
> Am 29.03.2016 um 12:02 schrieb Pavel Machek:
>> Hi!
>>
>> First, please Cc me on RGB color support.
>>
>>> Add generic support for RGB Color LED's.
>>>
>>> Basic idea is to use enum led_brightness also for the hue and saturation
>>> color components.This allows to implement the color extension w/o
>>> changes to struct led_classdev.
>>>
>>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>>
>>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>>> should be overridden even if the provided values are zero.
>>>
>>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>>> (now also hex notation can be used)
>>>
>>> 255 -> set full brightness and keep existing color if set
>>> 0 -> switch LED off but keep existing color so that it can be restored
>>> if the LED is switched on again later
>>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>>> (red)
>>
>> Umm, that's rather strange interface -- and three values in single sysfs
>> file is actually forbidden.
>>
>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>> we already have supported in the tree. (At least nokia N900 and Sony
>> motion controller already contain supported three-color LEDs).
>>
>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>> they are treated as three different LEDs. (Which makes some sense, you
>> can use "battery charging" trigger for LED, and CPU activity trigger
>> for green, for example). It would be good to have some kind of
>> grouping, so that userspace can tell "these 3 leds are actually
>> combined into one light".
>>
> At first thanks for the review comments.
> Treating the three physical LEDs of a RGB LED as separate LED devices
> might have been implemented due to the lack of alternatives.
> With one trigger controlling the red LED and another controlling the green
> LED we may end up with a yellow light. Not sure whether this is what we want.
>
> One driver for this extension was the idea of triggers using color
> to visualize states etc.
> Therefore it's not only about userspace controlling the color.
> As a trigger is bound to a led_classdev we need a led_classdev
> representing a RGB LED device.
>
> And ok: If required the sysfs interface can be splitted into separate
> attributes for hue, saturation, and (existing) brightness.
It would have the same downsides as in case of having r, g and b in
separate attributes, i.e. - problems with setting LED colour in
a consistent way. This way LED blinking in whatever colour couldn't
be supported reliably. It was one of your primary rationale standing
behind this design, if I remember correctly. Second - what about
triggers? We've had a long discussion about it and this design turned
out to be most fitting.
It's hard to address these requirements by having the settings in
separate attributes, due to synchronization issues, and LED trigger
mechanism specificity.
There is a question whether we can bend the sysfs "one value per sysfs
file" rule down to RGB LEDs needs.
Of course other brilliant ideas on how to approach the problem are
more than expected.
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-03-30 7:57 ` Jacek Anaszewski
@ 2016-04-01 13:57 ` Pavel Machek
2016-04-01 18:56 ` Jacek Anaszewski
0 siblings, 1 reply; 46+ messages in thread
From: Pavel Machek @ 2016-04-01 13:57 UTC (permalink / raw)
To: Jacek Anaszewski
Cc: Heiner Kallweit, Greg KH, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge
Hi!
On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote:
> Hi Heiner and Pavel,
>
> On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
> >Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> >>Hi!
> >>
> >>First, please Cc me on RGB color support.
> >>
> >>>Add generic support for RGB Color LED's.
> >>>
> >>>Basic idea is to use enum led_brightness also for the hue and saturation
> >>>color components.This allows to implement the color extension w/o
> >>>changes to struct led_classdev.
> >>>
> >>>Select LEDS_RGB to enable building drivers using the RGB extension.
> >>>
> >>>Flag LED_SET_HUE_SAT allows to specify that hue / saturation
> >>>should be overridden even if the provided values are zero.
> >>>
> >>>Some examples for writing values to /sys/class/leds/<xx>/brightness:
> >>>(now also hex notation can be used)
> >>>
> >>>255 -> set full brightness and keep existing color if set
> >>>0 -> switch LED off but keep existing color so that it can be restored
> >>> if the LED is switched on again later
> >>>0x1000000 -> switch LED off and set also hue and saturation to 0
> >>>0x00ffff -> set full brightness, full saturation and set hue to 0
> >>>(red)
> >>
> >>Umm, that's rather strange interface -- and three values in single sysfs
> >>file is actually forbidden.
> >>
> >>Plus, it is very much unlike existing interfaces for RGB LEDs, which
> >>we already have supported in the tree. (At least nokia N900 and Sony
> >>motion controller already contain supported three-color LEDs).
> >>
> >>Now... yes, there's work to be done for the 3-color LEDs. Currently,
> >>they are treated as three different LEDs. (Which makes some sense, you
> >>can use "battery charging" trigger for LED, and CPU activity trigger
> >>for green, for example). It would be good to have some kind of
> >>grouping, so that userspace can tell "these 3 leds are actually
> >>combined into one light".
Hi!
> >At first thanks for the review comments.
> >Treating the three physical LEDs of a RGB LED as separate LED devices
> >might have been implemented due to the lack of alternatives.
> >With one trigger controlling the red LED and another controlling the green
> >LED we may end up with a yellow light. Not sure whether this is what we want.
> >
> >One driver for this extension was the idea of triggers using color
> >to visualize states etc.
> >Therefore it's not only about userspace controlling the color.
> >As a trigger is bound to a led_classdev we need a led_classdev
> >representing a RGB LED device.
> >
> >And ok: If required the sysfs interface can be splitted into separate
> >attributes for hue, saturation, and (existing) brightness.
>
> It would have the same downsides as in case of having r, g and b in
> separate attributes, i.e. - problems with setting LED colour in
> a consistent way. This way LED blinking in whatever colour couldn't
> be supported reliably. It was one of your primary rationale standing
> behind this design, if I remember correctly. Second - what about
> triggers? We've had a long discussion about it and this design turned
> out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16
million colors?
I believe we should support patterns for RGB LEDs. Something like
[ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0"
/sys/class/led/n900::green ; default trigger "lp5533::0:1"
/sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Normally, pattern would correspond to one RGB LED. We could have
attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for
this pattern. Then we could have normal "trigger" mechanism, working
with the color used. Probably recognizing "none" for manual control,
and "pattern" for pattern control. (Pattern would be controlled as
described above).
> It's hard to address these requirements by having the settings in
> separate attributes, due to synchronization issues, and LED trigger
> mechanism specificity.
>
> There is a question whether we can bend the sysfs "one value per sysfs
> file" rule down to RGB LEDs needs.
>
> Of course other brilliant ideas on how to approach the problem are
> more than expected.
linux-api sounds like interesting idea, please cc me if you do that.
Best regards,
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] 46+ messages in thread
* Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
2016-04-01 13:57 ` Pavel Machek
@ 2016-04-01 18:56 ` Jacek Anaszewski
[not found] ` <56FEC444.4040106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Jacek Anaszewski @ 2016-04-01 18:56 UTC (permalink / raw)
To: Pavel Machek, Jacek Anaszewski
Cc: Heiner Kallweit, Greg KH, linux-leds, Benjamin Tissoires,
linux-kernel, linux-usb, pali.rohar, sre, khilman, aaro.koskinen,
ivo.g.dimitrov.75, Patrik Bachan, serge
On 04/01/2016 03:57 PM, Pavel Machek wrote:
> Hi!
> On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote:
>> Hi Heiner and Pavel,
>>
>> On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
>>> Am 29.03.2016 um 12:02 schrieb Pavel Machek:
>>>> Hi!
>>>>
>>>> First, please Cc me on RGB color support.
>>>>
>>>>> Add generic support for RGB Color LED's.
>>>>>
>>>>> Basic idea is to use enum led_brightness also for the hue and saturation
>>>>> color components.This allows to implement the color extension w/o
>>>>> changes to struct led_classdev.
>>>>>
>>>>> Select LEDS_RGB to enable building drivers using the RGB extension.
>>>>>
>>>>> Flag LED_SET_HUE_SAT allows to specify that hue / saturation
>>>>> should be overridden even if the provided values are zero.
>>>>>
>>>>> Some examples for writing values to /sys/class/leds/<xx>/brightness:
>>>>> (now also hex notation can be used)
>>>>>
>>>>> 255 -> set full brightness and keep existing color if set
>>>>> 0 -> switch LED off but keep existing color so that it can be restored
>>>>> if the LED is switched on again later
>>>>> 0x1000000 -> switch LED off and set also hue and saturation to 0
>>>>> 0x00ffff -> set full brightness, full saturation and set hue to 0
>>>>> (red)
>>>>
>>>> Umm, that's rather strange interface -- and three values in single sysfs
>>>> file is actually forbidden.
>>>>
>>>> Plus, it is very much unlike existing interfaces for RGB LEDs, which
>>>> we already have supported in the tree. (At least nokia N900 and Sony
>>>> motion controller already contain supported three-color LEDs).
>>>>
>>>> Now... yes, there's work to be done for the 3-color LEDs. Currently,
>>>> they are treated as three different LEDs. (Which makes some sense, you
>>>> can use "battery charging" trigger for LED, and CPU activity trigger
>>>> for green, for example). It would be good to have some kind of
>>>> grouping, so that userspace can tell "these 3 leds are actually
>>>> combined into one light".
> Hi!
>
>>> At first thanks for the review comments.
>>> Treating the three physical LEDs of a RGB LED as separate LED devices
>>> might have been implemented due to the lack of alternatives.
>>> With one trigger controlling the red LED and another controlling the green
>>> LED we may end up with a yellow light. Not sure whether this is what we want.
>>>
>>> One driver for this extension was the idea of triggers using color
>>> to visualize states etc.
>>> Therefore it's not only about userspace controlling the color.
>>> As a trigger is bound to a led_classdev we need a led_classdev
>>> representing a RGB LED device.
>>>
>>> And ok: If required the sysfs interface can be splitted into separate
>>> attributes for hue, saturation, and (existing) brightness.
>>
>> It would have the same downsides as in case of having r, g and b in
>> separate attributes, i.e. - problems with setting LED colour in
>> a consistent way. This way LED blinking in whatever colour couldn't
>> be supported reliably. It was one of your primary rationale standing
>> behind this design, if I remember correctly. Second - what about
>> triggers? We've had a long discussion about it and this design turned
>> out to be most fitting.
>
> Are on/off triggers really that useful for a LED that can produce 16
> million colors?
>
> I believe we should support patterns for RGB LEDs. Something like
> [ (time, r, g, b), ... ] . Ok, what about this one?
>
> Lets say we have
>
> /sys/class/pattern/lp5533::0
> /sys/class/pattern/software::0
>
> /sys/class/led/n900::red ; default trigger "lp5533::0:0"
> /sys/class/led/n900::green ; default trigger "lp5533::0:1"
> /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
>
> Normally, pattern would correspond to one RGB LED. We could have
> attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for
> this pattern.
This involves the same issue you were opposed to: three values per
sysfs attribute.
> Then we could have normal "trigger" mechanism, working
> with the color used. Probably recognizing "none" for manual control,
> and "pattern" for pattern control. (Pattern would be controlled as
> described above).
>
>> It's hard to address these requirements by having the settings in
>> separate attributes, due to synchronization issues, and LED trigger
>> mechanism specificity.
>>
>> There is a question whether we can bend the sysfs "one value per sysfs
>> file" rule down to RGB LEDs needs.
>>
>> Of course other brilliant ideas on how to approach the problem are
>> more than expected.
>
> linux-api sounds like interesting idea, please cc me if you do that.
>
> Best regards,
> Pavel
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2016-04-18 9:12 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-01 21:26 [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's Heiner Kallweit
2016-03-04 9:04 ` Jacek Anaszewski
2016-03-29 10:02 ` Pavel Machek
2016-03-29 20:38 ` Heiner Kallweit
2016-03-29 21:43 ` Pavel Machek
2016-03-29 22:03 ` Pavel Machek
2016-03-29 22:03 ` Pavel Machek
2016-03-30 5:58 ` Heiner Kallweit
2016-04-01 12:52 ` Pavel Machek
2016-03-30 8:07 ` Jacek Anaszewski
2016-03-30 8:07 ` Jacek Anaszewski
2016-03-30 13:03 ` Pavel Machek
2016-03-30 13:59 ` Heiner Kallweit
2016-03-31 8:17 ` Jacek Anaszewski
2016-04-01 12:55 ` Pavel Machek
2016-04-01 13:28 ` Jacek Anaszewski
2016-04-01 14:07 ` Pavel Machek
2016-04-01 14:27 ` Jacek Anaszewski
2016-04-01 15:03 ` Pavel Machek
[not found] ` <56FB893C.60203-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-04-01 12:53 ` Pavel Machek
2016-04-01 12:53 ` Pavel Machek
2016-03-30 7:57 ` Jacek Anaszewski
2016-04-01 13:57 ` Pavel Machek
2016-04-01 18:56 ` Jacek Anaszewski
[not found] ` <56FEC444.4040106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-01 21:18 ` Pavel Machek
2016-04-01 21:18 ` Pavel Machek
2016-04-04 21:34 ` Jacek Anaszewski
2016-04-05 9:01 ` Pavel Machek
2016-04-05 19:45 ` Jacek Anaszewski
2016-04-05 19:45 ` Jacek Anaszewski
2016-04-05 20:43 ` Heiner Kallweit
[not found] ` <5704236D.5080805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-05 22:15 ` Jacek Anaszewski
2016-04-05 22:15 ` Jacek Anaszewski
[not found] ` <570438EF.4080904-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-06 9:16 ` Pavel Machek
2016-04-06 9:16 ` Pavel Machek
2016-04-06 9:12 ` Pavel Machek
2016-04-06 8:52 ` Pavel Machek
2016-04-06 9:53 ` Jacek Anaszewski
2016-04-07 20:45 ` Pavel Machek
2016-04-08 18:47 ` Jacek Anaszewski
2016-04-09 16:01 ` Pavel Machek
[not found] ` <20160409160142.GD19362-5NIqAleC692hcjWhqY66xCZi+YwRKgec@public.gmane.org>
2016-04-12 7:13 ` Jacek Anaszewski
2016-04-12 7:13 ` Jacek Anaszewski
2016-04-15 11:53 ` Pavel Machek
2016-04-18 9:12 ` Jacek Anaszewski
2016-04-18 9:12 ` Jacek Anaszewski
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.