[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <913151e4-c19f-9a22-697c-52a9fb48cb32@gmail.com>
Date: Wed, 18 Jul 2018 20:54:28 +0200
From: Jacek Anaszewski <jacek.anaszewski@...il.com>
To: Pavel Machek <pavel@....cz>
Cc: David Lechner <david@...hnology.com>,
Baolin Wang <baolin.wang@...aro.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Mark Brown <broonie@...nel.org>,
Linux LED Subsystem <linux-leds@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface
On 07/18/2018 09:56 AM, Pavel Machek wrote:
> Hi!
>
>>>>>> I believe I meant "changing patterns from kernel in response to events
>>>>>> is probably overkill"... or something like that.
>>>>>
>>>>> Anyway -- to clean up the confusion -- I'd like to see
>>>>>
>>>>> echo pattern > trigger
>>>>> echo "1 2 3 4 5 6 7 8" > somewhere
>>>>
>>>> s/somewhere/pattern/
>>>>
>>>> pattern trigger should create "pattern" file similarly how ledtrig-timer
>>>> creates delay_{on|off} files.
>
> Yes, that sounds reasonable. v5 still says
>
> + Writing non-empty string to this file will activate the pattern,
> + and empty string will disable the pattern.
>
> I'd deactivate the pattern by simply writing something else to the
> trigger file.
Please keep in mind that this is ABI documentation for the pattern file
to be exposed by LED core, and not by the pattern trigger, that, as we
agreed, will be implemented later. In this case, I'd go for
"echo 0 > brightness" as a command disabling pattern. The same operation
disables triggers, so later transition to using pattern trigger will be
seamless for userspace.
--
Best regards,
Jacek Anaszewski
Powered by blists - more mailing lists