Messages in this thread | | | Subject | Re: [PATCH v3 1/2] leds: core: Introduce generic pattern interface | From | Jacek Anaszewski <> | Date | Sun, 15 Jul 2018 14:22:03 +0200 |
| |
On 07/15/2018 12:39 AM, Pavel Machek wrote: > On Sun 2018-07-15 00:29:25, Pavel Machek wrote: >> On Sun 2018-07-15 00:02:57, Jacek Anaszewski wrote: >>> Hi Pavel, >>> >>> On 07/14/2018 11:20 PM, Pavel Machek wrote: >>>> Hi! >>>> >>>>>> It also drew my attention to the issue of desired pattern sysfs >>>>>> interface semantics on uninitialized pattern. In your implementation >>>>>> user seems to be unable to determine if the pattern is activated >>>>>> or not. We should define the semantics for this use case and >>>>>> describe it in the documentation. Possibly pattern could >>>>>> return alone new line character then. >>>> >>>> Let me take a step back: we have triggers.. like LED blinking. >>>> >>>> How is that going to interact with patterns? We probably want the >>>> patterns to be ignored in that case...? >>>> >>>> Which suggest to me that we should treat patterns as a trigger. I >>>> believe we do something similar with blinking already. >>>> >>>> Then it is easy to determine if pattern is active, and pattern >>>> vs. trigger issue is solved automatically. >>> >>> I'm all for it. I proposed this approach during the previous >>> discussions related to possible pattern interface implementations, >>> but you seemed not to be so enthusiastic in [0]. >>> >>> [0] https://lkml.org/lkml/2017/4/7/350 >> >> Hmm. Reading my own email now, I can't decipher it. >> >> 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.
-- Best regards, Jacek Anaszewski
| |