Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759245AbcDAO14 (ORCPT ); Fri, 1 Apr 2016 10:27:56 -0400 Received: from mailout2.w1.samsung.com ([210.118.77.12]:22716 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759193AbcDAO1x (ORCPT ); Fri, 1 Apr 2016 10:27:53 -0400 X-AuditID: cbfec7f4-f796c6d000001486-e5-56fe8564b0a0 Message-id: <56FE8563.9090609@samsung.com> Date: Fri, 01 Apr 2016 16:27:47 +0200 From: Jacek Anaszewski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-version: 1.0 To: Pavel Machek Cc: Heiner Kallweit , pali.rohar@gmail.com, sre@kernel.org, khilman@kernel.org, aaro.koskinen@iki.fi, ivo.g.dimitrov.75@gmail.com, Patrik Bachan , serge@hallyn.com, Greg KH , linux-leds@vger.kernel.org, Benjamin Tissoires , Linux Kernel Mailing List , Linux USB Mailing List Subject: Re: [PATCH v5 1/4] leds: core: add generic support for RGB Color LED's References: <56D608ED.2090406@gmail.com> <20160329100258.GA24964@amd> <56FAE7A8.2070302@gmail.com> <20160329214323.GA10455@amd> <56FB893C.60203@samsung.com> <20160330130319.GB19994@amd> <20160401125540.GC11860@amd> <56FE779B.9020602@samsung.com> <20160401140731.GE11860@amd> In-reply-to: <20160401140731.GE11860@amd> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42I5/e/4Vd2U1n9hBnvmWluseeFgcX3KZlaL cwtmMFosej+D1WLJlUPsFk83P2ayuLxrDpvF1jfrgBLLWpktJp7+zWSx8GYTs8XdU0fZLM5f OMducXp3iQOfx85Zd9k9ru2O9Dj8dSGLx6ZVnWwebx8GeLzfd5XNY8Xq7+wenzfJBXBEcdmk pOZklqUW6dslcGXcPP+HraBBuOLxlQ0sDYxd/F2MnBwSAiYSW+7+YYGwxSQu3FvP1sXIxSEk sJRR4nPTJlYI5xmjxP85q9hBqngFtCQmLL7FBGKzCKhKXJ/4hA3EZhMwlPj54jVYXFQgQuLP 6X2sEPWCEj8m3wPbICIgL7G1bwUzyFBmga3MEjufzGYGSQgL+Euc/9jIDLHtIZPE//c7wLZx CmhKzP/9jhHEZhawllg5aRuULS+xec1b5gmMArOQLJmFpGwWkrIFjMyrGEVTS5MLipPScw31 ihNzi0vz0vWS83M3MULi6MsOxsXHrA4xCnAwKvHw3pj2N0yINbGsuDL3EKMEB7OSCO+Z8n9h QrwpiZVVqUX58UWlOanFhxilOViUxHnn7nofIiSQnliSmp2aWpBaBJNl4uCUamDUVgnYXbql q3ZSUnlXfeSVEP+Xh7++dGUO8wjL9fJNb77AKZ5jGXvos36w7+Xf9xt+WdvzBM6M2d0499xv T6E6J81ddxqrok327jeqL9fiqF50OOVB4vrOdWmHsl8ZWBcHVk+esidzSUJ1VrWzmeq8r3ml gmwvbTsnBB05USW/U0DMYPkBaSWW4oxEQy3mouJEAEP7zkWfAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2364 Lines: 68 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