From: "Andreas Färber" <firstname.lastname@example.org> To: Miguel Ojeda <email@example.com> Cc: Dan Murphy <firstname.lastname@example.org>, Geert Uytterhoeven <email@example.com>, Jacek Anaszewski <firstname.lastname@example.org>, Pavel Machek <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com Subject: Re: [RFC 22/25] leds: tm1826: Add combined glyph support Date: Sun, 22 Dec 2019 04:14:12 +0100 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com> Hi Miguel, Am 22.12.19 um 00:12 schrieb Miguel Ojeda: > On Sat, 21 Dec 2019 at 22:49 Andreas Färber <email@example.com > <mailto:firstname.lastname@example.org>> wrote: > > Hi, > > Am 21.12.19 um 22:04 schrieb Pavel Machek: > >>>> Allow to squeeze the text "HEllO" into a 4-digit display, > >>>> as seen on MeLE V9 TV box. > >>>> > >>>> Enable this combining mode only if the text would overflow. > >>> > >>> "HEll,nO"! > >>> > >>> :-) > >>> > >>> Ok, it is kind of cool, but... Can you take a look at > >>> drivers/auxdisplay/charlcd.c ? It seems to support some kind of > text > >>> displays... > >> > >> Why don't you look at it before making such a suggestion? ;) It > is in no way > >> useful, as I pointed out in my cover letter. The only thing > related today, > >> as Geert pointed out, is in the input subsystem. > > > > Okay, so maybe we should get > > > > AUXILIARY DISPLAY DRIVERS > > M: Miguel Ojeda Sandonis <email@example.com > <mailto:firstname.lastname@example.org>> > > > > on the Cc: list? > > Let's see if that email still exists - the code looked ancient, full of > platform_data and driver-specific exported functions... > > (the Yealink input driver was from 2005, too) > > > The code may look ancient, but the email surely exists ;) > > > > > What you really have is a display, not a bunch of LEDs. > > We have an LED Controller connected to zero, one or more displays. > They are most certainly _not_ the same thing. > > >> If you don't want this in leds, you'll have to help make leds > subsystem more > >> useful to external users - the latest function refactoring has > been anything > >> but helpful here, as you've seen with the indicators, and we're > completely > >> lacking any indexing or bulk operations on the LED controller > level, since > >> you treat each LED as a standalone device. That's precisely why > this code is > >> here in leds although - as I pointed out - it shouldn't belong here. > > > > Well, your introduction mail was kind of long :-). > > > > If someone wants to do heartbeat on > > > > -- > > | | <- this segment > > -- > > | | > > -- > > > > they are probably crazy. We may not want to support that. What about > > doing it as auxdisplay driver, and then exporting the indicators > > around that as LEDs? > > You're really just discussing which directory to put this file into - > moving it around is the easiest thing... > > > > > Having USB activity trigger on 'USB' icon makes sense, on the other > > hand. That would still be supported. > > Actually I disagree about those indicators - that was the reason > they're > indicators and not, e.g., "usb". IMO people would go crazy if large > text > like that blinked during USB transfers. I assumed the meaning of those > LEDs were to indicate whether a USB/SD medium is connected, which I did > not see any better function for, and I'm not aware of us having such > triggers today. > > Maybe you also overread that with trigger I was referring to using RTC > as trigger for a) the colon blinking every half-second and b) the text > getting updated based on avsilable RTC interrupts? > > You could also think of GPIO-connected LEDs that you may want to > animate > without two different heartbeats/timers getting out of sync. Or > think of > an RGB LED that today we sadly need to model as multiple GPIO LEDs > instead of as one with a color property we can change (and hardcoding a > color in DT/name is not helping that use case either). > > auxdisplay offers no API that I could register with to drive output, > nor > any triggers to automate such output - that's unique to LEDs. Like I > said, we can place this spi_driver file into auxdisplay/, but that > doesn't solve the driver design. > > > I think it would be alright to put it in auxdisplay. Please find the full series on, e.g., LAKML: https://patchwork.kernel.org/cover/11286939/ > So I really think we need to decouple > the two and keep the LED Controller driver in leds and the display > logic > elsewhere, with suitable new APIs to connect them. We're lacking > suggestions for the how, on DT and API levels - see my response on > [...]the > cover letter. As explained in the cover letter, the problem here is that I don't know the model or manufacturer of these unmarked white-plastic-frame LED displays. So we have neither a filename to use in auxdisplay/ nor a DT compatible string to use for those displays. Cheers, Andreas -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
next prev parent reply other threads:[~2019-12-22 3:14 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-12 3:39 [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Andreas Färber 2019-12-12 3:39 ` [RFC 01/25] dt-bindings: vendor-prefixes: Add Xnano Andreas Färber 2019-12-19 22:26 ` Rob Herring 2019-12-12 3:39 ` [RFC 02/25] dt-bindings: arm: realtek: Add Xnano X5 Andreas Färber 2019-12-19 22:27 ` Rob Herring 2019-12-12 3:39 ` [RFC 03/25] arm64: dts: realtek: rtd1295: " Andreas Färber 2019-12-12 3:39 ` [RFC 04/25] spi: gpio: Implement LSB First bitbang support Andreas Färber 2019-12-12 8:40 ` Geert Uytterhoeven 2019-12-12 15:14 ` Andreas Färber 2019-12-12 17:19 ` Mark Brown 2019-12-12 21:08 ` Andreas Färber 2019-12-13 11:42 ` Mark Brown 2019-12-12 3:39 ` [RFC 05/25] dt-bindings: vendor-prefixes: Add Titan Micro Electronics Andreas Färber 2019-12-19 22:31 ` Rob Herring 2019-12-12 3:39 ` [RFC 06/25] dt-bindings: leds: Add Titan Micro Electronics TM1628 Andreas Färber 2019-12-19 23:04 ` Rob Herring 2019-12-12 3:39 ` [RFC 07/25] " Andreas Färber 2019-12-14 9:48 ` Andreas Färber 2019-12-12 3:39 ` [RFC 08/25] arm64: dts: realtek: rtd129x-zidoo-x9s: Add TM1628 LED controller Andreas Färber 2019-12-12 3:39 ` [RFC 09/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add regular LEDs to TM1628 Andreas Färber 2019-12-12 3:39 ` [RFC 10/25] dt-bindings: vendor-prefixes: Add Fuda Hisi Microelectronics Andreas Färber 2019-12-19 23:04 ` Rob Herring 2019-12-12 3:39 ` [RFC 11/25] dt-bindings: leds: tm1628: Add Fuda Hisi Microelectronics FD628 Andreas Färber 2019-12-19 23:05 ` Rob Herring 2019-12-12 3:39 ` [RFC 12/25] " Andreas Färber 2019-12-12 3:39 ` [RFC 13/25] arm64: dts: realtek: rtd1295-xnano-x5: Add FD628 LED controller Andreas Färber 2019-12-12 3:39 ` [RFC 14/25] arm64: dts: realtek: rtd1295-xnano-x5: Add regular LEDs to FD628 Andreas Färber 2019-12-21 20:21 ` Pavel Machek 2019-12-12 3:39 ` [RFC 15/25] dt-bindings: vendor-prefixes: Add Fude Microelectronics Andreas Färber 2019-12-19 23:05 ` Rob Herring 2019-12-12 3:39 ` [RFC 16/25] dt-bindings: leds: tm1628: Add Fude Microelectronics AiP1618 Andreas Färber 2019-12-19 23:06 ` Rob Herring 2019-12-12 3:39 ` [RFC 17/25] leds: tm1628: Prepare " Andreas Färber 2019-12-21 19:55 ` Andreas Färber 2019-12-12 3:39 ` [RFC 18/25] dt-bindings: leds: tm1628: Define display child nodes Andreas Färber 2019-12-12 3:39 ` [RFC 19/25] leds: tm1628: Add 7-segment display support Andreas Färber 2019-12-12 8:33 ` Geert Uytterhoeven 2019-12-12 14:10 ` Andreas Färber 2019-12-21 20:23 ` Pavel Machek 2019-12-12 3:39 ` [RFC 20/25] arm64: dts: realtek: rtd1295-zidoo-x9s: Add display to TM1628 Andreas Färber 2019-12-12 3:39 ` [RFC 21/25] arm64: dts: realtek: rtd1295-xnano-x5: Add display to FD628 Andreas Färber 2019-12-12 3:39 ` [RFC 22/25] leds: tm1826: Add combined glyph support Andreas Färber 2019-12-21 20:27 ` Pavel Machek 2019-12-21 20:41 ` Andreas Färber 2019-12-21 21:04 ` Pavel Machek 2019-12-21 21:49 ` Andreas Färber [not found] ` <CANiq72nA9OLa0SjY8W055J_2A32tcp7S98SruKSdWH2dm25VKw@mail.gmail.com> 2019-12-22 3:14 ` Andreas Färber [this message] 2020-01-15 14:31 ` Miguel Ojeda 2019-12-12 3:39 ` [RFC 23/25] WIP: leds: tm1628: Prepare TM1628 keys Andreas Färber 2019-12-12 3:39 ` [RFC 24/25] WIP: leds: tm1628: Prepare FD628 keys Andreas Färber 2019-12-12 3:39 ` [RFC 25/25] WIP: leds: tm1628: Prepare AiP1618 keys Andreas Färber 2019-12-12 13:14 ` [RFC 00/25] arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers Robin Murphy 2019-12-12 20:55 ` Andreas Färber 2019-12-13 14:07 ` Robin Murphy 2019-12-13 14:36 ` Geert Uytterhoeven 2020-02-25 21:42 ` Ezra Buehler 2020-02-26 13:03 ` Pavel Machek 2019-12-21 18:20 ` Pavel Machek 2019-12-21 21:07 ` Andreas Färber 2020-01-15 13:34 ` Andreas Färber
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC 22/25] leds: tm1826: Add combined glyph support' \ /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
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).