diff mbox series

[RFC,22/25] leds: tm1826: Add combined glyph support

Message ID 20191212033952.5967-23-afaerber@suse.de (mailing list archive)
State New, archived
Headers show
Series arm64: realtek: Add Xnano X5 and implement TM1628/FD628/AiP1618 LED controllers | expand

Commit Message

Andreas Färber Dec. 12, 2019, 3:39 a.m. UTC
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.

Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 drivers/leds/leds-tm1628.c | 31 ++++++++++++++++++++++++++++++-
 1 file changed, 30 insertions(+), 1 deletion(-)

Comments

Pavel Machek Dec. 21, 2019, 8:27 p.m. UTC | #1
On Thu 2019-12-12 04:39:49, Andreas Färber wrote:
> 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...

Best regards,
								Pavel
Andreas Färber Dec. 21, 2019, 8:41 p.m. UTC | #2
Pavel,

Am 21.12.19 um 21:27 schrieb Pavel Machek:
> On Thu 2019-12-12 04:39:49, Andreas Färber wrote:
>> 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.

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.

Regards,
Andreas
Pavel Machek Dec. 21, 2019, 9:04 p.m. UTC | #3
Hi!

> >>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 <miguel.ojeda.sandonis@gmail.com>

on the Cc: list? What you really have is a display, not a bunch of LEDs.

> 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?

Having USB activity trigger on 'USB' icon makes sense, on the other
hand. That would still be supported.

Hmm?
									Pavel
Andreas Färber Dec. 21, 2019, 9:49 p.m. UTC | #4
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 <miguel.ojeda.sandonis@gmail.com>
> 
> 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)

> 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. 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.

Regards,
Andreas
Andreas Färber Dec. 22, 2019, 3:14 a.m. UTC | #5
Hi Miguel,

Am 22.12.19 um 00:12 schrieb Miguel Ojeda:
> On Sat, 21 Dec 2019 at 22:49 Andreas Färber <afaerber@suse.de 
> <mailto:afaerber@suse.de>> 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 <miguel.ojeda.sandonis@gmail.com
>     <mailto:miguel.ojeda.sandonis@gmail.com>>
>      >
>      > 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
Miguel Ojeda Jan. 15, 2020, 2:31 p.m. UTC | #6
Hi Andreas,

On Sun, Dec 22, 2019 at 4:14 AM Andreas Färber <afaerber@suse.de> wrote:
>
> Please find the full series on, e.g., LAKML:
>
> https://patchwork.kernel.org/cover/11286939/

Sorry for the late reply. Thanks for the pointer!

> 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.

For the filename, I don't think it is a big deal. Just use whatever
you think would fit best, even if it is a generic name. The most
important bit is having a clear Kconfig (and being disabled by
default).

Cheers,
Miguel
diff mbox series

Patch

diff --git a/drivers/leds/leds-tm1628.c b/drivers/leds/leds-tm1628.c
index e2c2a5d91596..0c0d099de8b0 100644
--- a/drivers/leds/leds-tm1628.c
+++ b/drivers/leds/leds-tm1628.c
@@ -347,6 +347,28 @@  static u8 tm1628_get_char_ssd_map(char ch)
 	return 0x0;
 }
 
+struct tm1628_ssd_glyph {
+	char *str;
+	u8 segs;
+};
+
+static const struct tm1628_ssd_glyph tm1628_glyph_ssd_map[] = {
+	{ "ll", SSD_TOP_LEFT | SSD_BOTTOM_LEFT |
+		SSD_TOP_RIGHT | SSD_BOTTOM_RIGHT },
+};
+
+static u8 tm1628_get_glyph_ssd_map(const char *str)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(tm1628_glyph_ssd_map); i++) {
+		if (!strncmp(tm1628_glyph_ssd_map[i].str, str, 2))
+			return tm1628_glyph_ssd_map[i].segs;
+	}
+
+	return 0x0;
+}
+
 static int tm1628_display_apply_map(struct tm1628 *s,
 	struct tm1628_display *display, u8 map)
 {
@@ -366,7 +388,7 @@  static ssize_t text_store(struct device *dev,
 {
 	struct tm1628 *s = dev_get_drvdata(dev);
 	size_t offset, len = count;
-	u8 map;
+	u8 map, glyph_map;
 	int i, ret;
 
 	if (len > 0 && buf[len - 1] == '\n')
@@ -375,6 +397,13 @@  static ssize_t text_store(struct device *dev,
 	for (i = 0, offset = 0; i < s->num_displays; i++) {
 		if (offset < len) {
 			map = tm1628_get_char_ssd_map(buf[offset]);
+			if (offset + 1 < len && len > s->num_displays) {
+				glyph_map = tm1628_get_glyph_ssd_map(buf + offset);
+				if (glyph_map) {
+					map = glyph_map;
+					offset++;
+				}
+			}
 			offset++;
 		} else
 			map = 0x0;