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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
