public inbox for linux-leds@vger.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: RGB support prototype
Date: Sun, 13 Aug 2017 12:31:34 +0200	[thread overview]
Message-ID: <87ddf9f2-40b8-fd3a-f106-35b202697391@gmail.com> (raw)
In-Reply-To: <20170812224818.GA5960@amd>

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

  reply	other threads:[~2017-08-13 10:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-12 22:48 RGB support prototype Pavel Machek
2017-08-13 10:31 ` Jacek Anaszewski [this message]
2017-08-13 11:41   ` Pavel Machek
2017-08-14 18:26     ` Jacek Anaszewski
2017-08-30 14:51       ` Pavel Machek
2017-08-31  9:33         ` Pavel Machek
2017-09-02 14:36           ` Jacek Anaszewski
2017-08-13 20:19   ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ddf9f2-40b8-fd3a-f106-35b202697391@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox