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 > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
