All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: "Marek Behún" <marek.behun@nic.cz>
Cc: jacek.anaszewski@gmail.com, dmurphy@ti.com, linux-leds@vger.kernel.org
Subject: Re: We have multicolor, but should we turn it into RGB?
Date: Mon, 27 Jul 2020 12:20:58 +0200	[thread overview]
Message-ID: <20200727102058.GA16553@amd> (raw)
In-Reply-To: <20200727114048.32f36c59@dellmb.labs.office.nic.cz>

[-- Attachment #1: Type: text/plain, Size: 2201 bytes --]

Hi!

> > Multicolor is a bit too abstract. Yes, we can have
> > Green-Magenta-Ultraviolet LED, but so far all the LEDs we support are
> > RGB, and not even RGB-White or RGB-Yellow variants emerged.
> > 
> > Multicolor is not a good fit for RGB LED. It does not really know
> > about LED color.  In particular, there's no way to make LED "white".
> > 
> > Userspace is interested in knowing "this LED can produce arbitrary
> > color", which not all multicolor LEDs can.
> > 
> > 	Proposal: let's add "rgb" to led_colors in
> > 	drivers/leds/led-core.c, add corresponding device tree
> > 	defines, and use that, instead of multicolor for RGB LEDs.
> > 
> > 	We really need to do that now; "white" stuff can wait.
> > 
> > RGB LEDs are quite common, and it would be good to be able to turn LED
> > white and to turn it into any arbitrary color. It is essential that
> > userspace is able to set arbitrary colors, and it might be good to
> > have that ability from kernel, too... to allow full-color triggers.
> 
> I am not against adding RGB if you want to somehow teach the subsystem
> to mix arbitrary color (either by teaching it color curves or some
> other way). But I think we shouldn't remove multicolor, and here's the
> reason why:

I'd not remove multicolor. It would be still there for non-RGB
uses. (Sorry if I was unclear).

But I may want to disable it for now, not to have ABI incompatibility
in future.

> Most of the time I have seen 2 LEDs per ethernet port, green and yellow,
> but some ports have 2 Bi-Color LEDs, each consisting of green and
> yellow. I think most of the time these are 2-terminal LEDs.
> 
> So basically here we have, instead of a RGB LED, a GY LED (GY for
> green/yellow).
...
> So if we want to reasonably add support for this configuration of LEDs
> and to offer the user to configure these DUAL modes via the trigger
> API, I think these LEDs should be shown in the system as multicolor
> LEDs.

Yes, I guess multicolor may make sense there.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2020-07-27 10:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27  8:45 We have multicolor, but should we turn it into RGB? Pavel Machek
2020-07-27  9:40 ` Marek Behún
2020-07-27 10:20   ` Pavel Machek [this message]
2020-07-27 10:52   ` Pavel Machek
2020-07-27 11:21     ` Marek Behún
2020-08-03 12:04       ` turris-omnia: fixes needed was " Pavel Machek
2020-08-03 12:01 ` [PATCH] Add multicolor to the list Pavel Machek
2020-08-03 12:02 ` [PATCH] leds: disallow /sys/class/leds/*:multi:* for now 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=20200727102058.GA16553@amd \
    --to=pavel@ucw.cz \
    --cc=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=marek.behun@nic.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 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.