All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Karl Palsson <karlp@tweak.net.au>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>,
	Linux USB Mailing List <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v7 1/5] leds: core: add generic support for RGB LED's
Date: Mon, 07 Mar 2016 09:43:01 +0100	[thread overview]
Message-ID: <56DD3F15.20907@samsung.com> (raw)
In-Reply-To: <20160306205158-549-87411-mailpile@palmtree-beeroclock-net>

Hi Karl,

On 03/06/2016 09:55 PM, Karl Palsson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Heiner Kallweit <hkallweit1@gmail.com> wrote:
>> Add generic support for RGB 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)
>>
>
>
> I admit I hadn't seen this earlier, and I didn't spend all day
> looking at previous attempts, but what's the motivation for
> putting all this overloaded syntax into the "brightness" file? I
> thought the point was to have a single value in each file, one of
> the references I did find was

With single value per file there would be problems with colour
components setting synchronization.

> http://www.spinics.net/lists/linux-leds/msg02995.html Is there
> some thread where this was decided as advantageous? Surely 0-255
> for _brightness_ is what the brightness entry should do?

You can find a reference to the related discussion in [1].

> I'd like to set the rgb colour of a led (or hsv, that can be it's
> own file too) and separately ramp the brightness up and down. I
> also think it's substantially simpler and easier to use from the
> user's point of view, which is surely the place you want easy
> right?

I'm also not very keen on overloading the brightness attribute
semantics. Nonetheless it seems impossible to add support for
setting three colour components otherwise than through a single
syscall, if we want to make it synchronous and compatible with
LED triggers.

HSV color scheme is also very convenient for adapting monochrome
brightness semantics to the RGB realm.


[1] http://www.spinics.net/lists/linux-leds/msg05477.html

-- 
Best regards,
Jacek Anaszewski

  parent reply	other threads:[~2016-03-07  8:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-04 21:09 [PATCH v7 1/5] leds: core: add generic support for RGB LED's Heiner Kallweit
     [not found] ` <56D9F973.8090207-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-03-06 20:55   ` Karl Palsson
2016-03-06 20:55     ` Karl Palsson
2016-03-06 22:24     ` Heiner Kallweit
2016-03-06 22:57       ` Karl Palsson
2016-03-06 22:57         ` Karl Palsson
2016-03-07  8:43     ` Jacek Anaszewski [this message]
2016-03-11  8:38 ` Jacek Anaszewski
2016-03-11 17:59   ` Heiner Kallweit

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=56DD3F15.20907@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=benjamin.tissoires@redhat.com \
    --cc=hkallweit1@gmail.com \
    --cc=karlp@tweak.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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 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.