linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Heiner Kallweit <hkallweit1@gmail.com>,
	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: Fri, 01 Apr 2016 16:27:47 +0200	[thread overview]
Message-ID: <56FE8563.9090609@samsung.com> (raw)
In-Reply-To: <20160401140731.GE11860@amd>

On 04/01/2016 04:07 PM, Pavel Machek wrote:
> Hi!
>
>>>>> 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".
>>>
>>> Well, that's how it is currently handled. But for the user, it looks
>>> as a LED with multiple colors.
>>>
>>>> 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".
>>>
>>> Why not?
>>>
>>> What do you do if you want to display magenta on your LCD?
>>>
>>> You compute RGB values, then display them.
>>
>> The main drawback is that you can't set the colour at one go,
>> but have to set brightness of each LED class device (R,G,B)
>> separately. It incurs delays between setting each colour component.
>
> Yeah. Well, on some hardware, that's just the way it is. If the leds
> are separate devices on i2c, you can't really set them in one go.

Delays can occur even if the LEDs are controlled by the same device.
Brightness of each LED class device is set with separate system
call and there will be always some time shift between particular I2C
transmissions that set the brightness for each sub-LED.

If the three sub-LEDs were controlled by a single LED class device
then we could setup the brightness of each sub-LED with single I2C
transmission.

> But some hardware has hardware pattern controls, and it can set them
> atomically.
>
>> It is also impossible to set arbitrary colour from a trigger.
>> Similarly blinking with arbitrarily chosen colour from RGB palette
>> is impossible if separate colour components are treated as
>> separate LEDs.
>
> Yes, see the proposal in the other mail. I believe we should have
> separate R, G, B LED devices, and separate pattern controller.
>
> Best regards,
> 									Pavel
>


-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-04-01 14:27 UTC|newest]

Thread overview: 37+ 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-30  5:58       ` Heiner Kallweit
2016-04-01 12:52         ` Pavel Machek
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
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 [this message]
2016-04-01 15:03                     ` 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
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 20:43                   ` Heiner Kallweit
2016-04-05 22:15                     ` Jacek Anaszewski
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
2016-04-12  7:13                             ` Jacek Anaszewski
2016-04-15 11:53                               ` Pavel Machek
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=56FE8563.9090609@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).