All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	pali.rohar@gmail.com, sre@kernel.org, khilman@kernel.org,
	aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com,
	Patrik Bachan <patrikbachan@gmail.com>,
	serge@hallyn.com, Greg KH <greg@kroah.com>,
	linux-leds@vger.kernel.org,
	Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux USB Mailing List <linux-usb@vger.kernel.org>
Subject: Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's
Date: Thu, 31 Mar 2016 10:17:36 +0200	[thread overview]
Message-ID: <56FCDD20.6060406@samsung.com> (raw)
In-Reply-To: <CAFSsGVuzToswt6bh9w3L2LqC6SiVyPw1-wSgUa3i=O14io85kg@mail.gmail.com>

Hi Heiner,

On 03/30/2016 03:59 PM, Heiner Kallweit wrote:
> On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek <pavel@ucw.cz> wrote:
>> Hi!
>>
>>>> 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).
>>>>
>>>> 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.
>>>>
>>>> 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...)
>>>
>>> Please note that HSV colour scheme allows to neatly project monochrome
>>> brightness semantics on the RGB realm. I.e. you can have fixed
>>> hue and saturation, and by changing the brightness component a perceived
>>> colour intensity can be altered.
>>
>> I see HSV has some advantages. But we already have LEDs with multiple
>> colors, and kernel already handles them:
>>
>> pavel@duo:~$ ls -1 /sys/class/leds/
>> tpacpi:green:batt
>> tpacpi:orange:batt
>>
>> This is physically 2 leds but hidden under one indicator, so you got
>> "off", "green", "orange" and "green+orange".
>
> That's a good example. As long as you can recognize green+orange as
> separate lights/colors
> (w/o magnifying glass) I wouldn't call it "a LED with multiple colors"
> but "multiple
> LED devices".
>
> In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs.
> And it's not only about using a handful of discrete colors but about
> displaying any arbitrary
> color.
> So far the kernel exposes the physical RGB LEDs as separate LEDs only
> and I can't use
> a trigger to e.g. set "magenta with 50% brightness".

I think that we should consult more people before pushing the solution
upstream. Would you mind writing a message with an explanation of the
issue to linux-api list?

Please keep in mind also the information from the "Attributes" section
of Documentation/filesystems/sysfs.txt.

-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-03-31  8:17 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01 21:26 [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's Heiner Kallweit
2016-03-04  9:04 ` Jacek Anaszewski
2016-03-29 10:02 ` Pavel Machek
2016-03-29 20:38   ` Heiner Kallweit
2016-03-29 21:43     ` Pavel Machek
2016-03-29 22:03       ` Pavel Machek
2016-03-29 22:03         ` Pavel Machek
2016-03-30  5:58       ` Heiner Kallweit
2016-04-01 12:52         ` Pavel Machek
2016-03-30  8:07       ` Jacek Anaszewski
2016-03-30  8:07         ` Jacek Anaszewski
2016-03-30 13:03         ` Pavel Machek
2016-03-30 13:59           ` Heiner Kallweit
2016-03-31  8:17             ` Jacek Anaszewski [this message]
2016-04-01 12:55             ` Pavel Machek
2016-04-01 13:28               ` Jacek Anaszewski
2016-04-01 14:07                 ` Pavel Machek
2016-04-01 14:27                   ` Jacek Anaszewski
2016-04-01 15:03                     ` Pavel Machek
     [not found]         ` <56FB893C.60203-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-04-01 12:53           ` Pavel Machek
2016-04-01 12:53             ` Pavel Machek
2016-03-30  7:57     ` Jacek Anaszewski
2016-04-01 13:57       ` Pavel Machek
2016-04-01 18:56         ` Jacek Anaszewski
     [not found]           ` <56FEC444.4040106-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-01 21:18             ` Pavel Machek
2016-04-01 21:18               ` Pavel Machek
2016-04-04 21:34               ` Jacek Anaszewski
2016-04-05  9:01                 ` Pavel Machek
2016-04-05 19:45                   ` Jacek Anaszewski
2016-04-05 19:45                     ` Jacek Anaszewski
2016-04-05 20:43                     ` Heiner Kallweit
     [not found]                       ` <5704236D.5080805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-05 22:15                         ` Jacek Anaszewski
2016-04-05 22:15                           ` Jacek Anaszewski
     [not found]                           ` <570438EF.4080904-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-04-06  9:16                             ` Pavel Machek
2016-04-06  9:16                               ` Pavel Machek
2016-04-06  9:12                       ` Pavel Machek
2016-04-06  8:52                     ` Pavel Machek
2016-04-06  9:53                       ` Jacek Anaszewski
2016-04-07 20:45                         ` Pavel Machek
2016-04-08 18:47                           ` Jacek Anaszewski
2016-04-09 16:01                             ` Pavel Machek
     [not found]                               ` <20160409160142.GD19362-5NIqAleC692hcjWhqY66xCZi+YwRKgec@public.gmane.org>
2016-04-12  7:13                                 ` Jacek Anaszewski
2016-04-12  7:13                                   ` Jacek Anaszewski
2016-04-15 11:53                                   ` Pavel Machek
2016-04-18  9:12                                     ` Jacek Anaszewski
2016-04-18  9:12                                       ` Jacek Anaszewski

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=56FCDD20.6060406@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=aaro.koskinen@iki.fi \
    --cc=benjamin.tissoires@redhat.com \
    --cc=greg@kroah.com \
    --cc=hkallweit1@gmail.com \
    --cc=ivo.g.dimitrov.75@gmail.com \
    --cc=khilman@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=patrikbachan@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=serge@hallyn.com \
    --cc=sre@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.