Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1710398 > unrolled thread

RGB support prototype

Back to article view | Back to linux.kernel

Contents

  RGB support prototype Pavel Machek <pavel@ucw.cz> - 2017-08-13 00:50 +0200
    Re: RGB support prototype Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-08-13 12:40 +0200
      Re: RGB support prototype Pavel Machek <pavel@ucw.cz> - 2017-08-13 13:50 +0200
        Re: RGB support prototype Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2017-08-14 20:30 +0200
      Re: RGB support prototype Pavel Machek <pavel@ucw.cz> - 2017-08-13 22:20 +0200

#1710398 — RGB support prototype

[Multipart message — attachments visible in raw view] — view raw

Hi!

You mentioned you was working on RGB support prototype. Could you post
copy of the patches (even if unfinished)?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [next] | [standalone]

#1710477

Hi,

On 08/13/2017 12:48 AM, Pavel Machek wrote:
> 
> Hi!
> 
> You mentioned you was working on RGB support prototype. Could you post
> copy of the patches (even if unfinished)?

Unfortunately it is at the stage of unfinished proof of concept and
I haven't managed yet to try how it fits to all API use cases we have.
Nor is it in a shape ready to post to the lists.

I think we could try to discuss the design here. I'll list all the
issues I encountered during the implementation:

Currently we set LED brightness with following API:

void led_set_brightness(struct led_classdev *led_cdev,
                        enum led_brightness brightness);

In case of RGB LED we could have something like this:

struct led_color_triplet {
        enum led_brightness red;
        enum led_brightness green;
        enum led_brightness blue;
};

void led_rgb_set_brightness(struct led_rgb_classdev *led_rgb_cdev,
                        struct led_color_triplet *color);

We've agreed that LED RGB class device color could be set by writing
space separated list of "r g b" color values to a sysfs "color" file.

While the above itself shouldn't raise too many doubts, they
arise quickly while trying to adapt it to the internal LED core
facilities:

- led_base_timer_function()
- set_brightness_delayed()
- led_blink_* API family

All these introduce problems especially with brightness/color type.
I tried to add a new abstraction layer by introducing
struct led_base_cdev with a set of generic ops that could be initialized
by particular type of LED but still the problem with brightness type
generalization remains. One solution could be an union with fields
mapping to either single or three brightness components.

Other option could be void *brightness type which could be then
cast to the required brightness type basing on the LED flag.

Generally it seems that all existing LED class API should get its
generic counterparts.

Other ideas are welcome.

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1710491

Hi!

> > You mentioned you was working on RGB support prototype. Could you post
> > copy of the patches (even if unfinished)?
> 
> Unfortunately it is at the stage of unfinished proof of concept and
> I haven't managed yet to try how it fits to all API use cases we have.
> Nor is it in a shape ready to post to the lists.
> 
> I think we could try to discuss the design here. I'll list all the
> issues I encountered during the implementation:
> 
> Currently we set LED brightness with following API:
> 
> void led_set_brightness(struct led_classdev *led_cdev,
>                         enum led_brightness brightness);
> 
> In case of RGB LED we could have something like this:
> 
> struct led_color_triplet {
>         enum led_brightness red;
>         enum led_brightness green;
>         enum led_brightness blue;
> };
> 
> void led_rgb_set_brightness(struct led_rgb_classdev *led_rgb_cdev,
>                         struct led_color_triplet *color);
> 
> We've agreed that LED RGB class device color could be set by writing
> space separated list of "r g b" color values to a sysfs "color" file.
> 
> While the above itself shouldn't raise too many doubts, they
> arise quickly while trying to adapt it to the internal LED core
> facilities:
> 
> - led_base_timer_function()
> - set_brightness_delayed()
> - led_blink_* API family
> 
> All these introduce problems especially with brightness/color type.
> I tried to add a new abstraction layer by introducing
> struct led_base_cdev with a set of generic ops that could be initialized
> by particular type of LED but still the problem with brightness type
> generalization remains. One solution could be an union with fields
> mapping to either single or three brightness components.
> 
> Other option could be void *brightness type which could be then
> cast to the required brightness type basing on the LED flag.

Void *brightness is not really a good option.

We could pass triplet even in case of single-color LEDs, and then use
just one component.

Another option would be to store color in HSV colorspace (not RGB). Then existing
functions would get brightness (== value in HSV), and RGB-aware functions would
operate on all 3 components. Triggers/blinking/etc. would then continue operating,
without modifications.

We could even export (read-only) hue/saturation for single-color LEDs...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1711330

Hi,

On 08/13/2017 01:41 PM, Pavel Machek wrote:
> Hi!
> 
>>> You mentioned you was working on RGB support prototype. Could you post
>>> copy of the patches (even if unfinished)?
>>
>> Unfortunately it is at the stage of unfinished proof of concept and
>> I haven't managed yet to try how it fits to all API use cases we have.
>> Nor is it in a shape ready to post to the lists.
>>
>> I think we could try to discuss the design here. I'll list all the
>> issues I encountered during the implementation:
>>
>> Currently we set LED brightness with following API:
>>
>> void led_set_brightness(struct led_classdev *led_cdev,
>>                         enum led_brightness brightness);
>>
>> In case of RGB LED we could have something like this:
>>
>> struct led_color_triplet {
>>         enum led_brightness red;
>>         enum led_brightness green;
>>         enum led_brightness blue;
>> };
>>
>> void led_rgb_set_brightness(struct led_rgb_classdev *led_rgb_cdev,
>>                         struct led_color_triplet *color);
>>
>> We've agreed that LED RGB class device color could be set by writing
>> space separated list of "r g b" color values to a sysfs "color" file.
>>
>> While the above itself shouldn't raise too many doubts, they
>> arise quickly while trying to adapt it to the internal LED core
>> facilities:
>>
>> - led_base_timer_function()
>> - set_brightness_delayed()
>> - led_blink_* API family
>>
>> All these introduce problems especially with brightness/color type.
>> I tried to add a new abstraction layer by introducing
>> struct led_base_cdev with a set of generic ops that could be initialized
>> by particular type of LED but still the problem with brightness type
>> generalization remains. One solution could be an union with fields
>> mapping to either single or three brightness components.
>>
>> Other option could be void *brightness type which could be then
>> cast to the required brightness type basing on the LED flag.
> 
> Void *brightness is not really a good option.
> 
> We could pass triplet even in case of single-color LEDs, and then use
> just one component.
> 
> Another option would be to store color in HSV colorspace (not RGB). Then existing
> functions would get brightness (== value in HSV), and RGB-aware functions would
> operate on all 3 components. Triggers/blinking/etc. would then continue operating,
> without modifications.
> 
> We could even export (read-only) hue/saturation for single-color LEDs...

Related patches from Heiner Kallweit are still sitting on devel branch
of linux-leds.git:

https://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git/log/?h=devel

Possibly it can serve as a basis for further development.

I liked that approach because it was compatible with monochrome
LEDs and triggers.

-- 
Best regards,
Jacek Anaszewski

[toc] | [prev] | [next] | [standalone]

#1710578

[Multipart message — attachments visible in raw view] — view raw

Hi!

> > You mentioned you was working on RGB support prototype. Could you post
> > copy of the patches (even if unfinished)?
> 
> Unfortunately it is at the stage of unfinished proof of concept and
> I haven't managed yet to try how it fits to all API use cases we have.
> Nor is it in a shape ready to post to the lists.

Well, if it compiles, it is in shape. If it does not compile, it is in
shape, too :-).
									Pavel
									
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web