Add textual LCD display driver support

[thedjnK]

Is your feature request related to a problem? Please describe. At present, zephyr has a display driver which is very much suited to graphical LCDs whereby e.g. images can be displayed, however it is lacking for support of textual-based displays, e.g. HD44780-based displays, or those with an SPI/I2C interface that support limited commands, essentially for moving a cursor, writing text or clearing the whole display. It would be beneficial to have a display class that supports the functionality of these basic textual displays, either as a new dedicated interface or by expanding the existing display interface to support the required functionality

Describe the solution you'd like The driver would need to have the following functionality:

• Display init
• Display de-init
• Display on/off
• Display cursor on/off
• Display blinking position on/off
• Display write text
• Display set cursor position (row, column)
• Display get details (width and height in characters, character set)
• Display clear

Optional nice to have functionality:

• Display set brightness
• Display set backlight on/off (this may be a command or might be toggling a GPIO/transistor)
• Display custom character set
• Display custom command (some displays have a bit more functionality e.g. setting font size, enabling automatic text scroll, etc., this could allow sending those commands without needing new functions for each of them)

The display configuration would be set via device tree, the type of driver and interface would be needed alongside the number of characters for width, height and likely the character set that the display supports. For HD44780-based displays it would also need the mode to operate in, 4-bit or 8-bit mode.

Describe alternatives you've considered Use the existing display driver, but the required functionality is just not present

[nuertey]

@thedjnK FYI, see my implementation for an LCD16x2 here: https://github.com/nuertey/ZephyrOS-LCD16x2

I tested it on the component and it is working. Pictures here (scroll down): https://github.com/nuertey/ZephyrOS-WeatherStation Regards Nuertey

[nuertey]

And I forgot to mention--and this is most relevant to your feature request--that I based my implementation on the official sample:

https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/drivers/lcd_hd44780

[thedjnK]

It's not really what I'm asking for, I'm asking for a driver class to support implementing these types of displays, the HD44780 is a generic one but the one I'm interested in is UART-based for a noritake VFD. The idea behind this freature request is to get the driver and function pointers created so that a driver for any type of textual display can be implemented, and with drop-in replacement support for any other textual display just by changing the module, DTS and a Kconfig.

[nuertey]

Understood.

[gmarull]

One misc driver that could likely be converted to such class: https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/misc/grove_lcd_rgb

[carlescufi]

Architecture WG

• This is a driver API for text-only displays, not a high-level layer like cfb
• @henrikbrixandersen mentions that this is a use-case that is already being covered downstream
• @bjarki-trackunit mentions that display_power_set() could be instead handled by the PM framework
• @gmarull mentions that it is good to have the display_power_set() but use the pm calls inside
• text_display_details_get() is aligned with other APIs, probably rename to caps
• text_display_is_busy probably debatable
• @henrikbrixandersen mentions that some of the devices are RAM-based, so we would probably extend with functionality to load the RAM
• @henrikbrixandersen suggest we have support for custom commands, similar to the UART API
• @bjarki-trackunit mentions that we might not need the capabilities API, the app can look it up with DT_GET()
• Linux bindings for aux displays: https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/auxdisplay
• Alternative names:
  • LCD char displays
  • aux display
  • char display

[lawrencek52]

I think what @thedjnK is really looking for is a package like ncurses above the character display. ncurses has been around a longtime and a subset of the basic ncurses APIs are probably reasonable for this project.

The list of functions @thedjnK suggested did not include:

• query functions:
  • the size of the display in rows and columns.
  • the display capabilities, can it draw in colour? invert the character? flash the cursor, underline or block cursor, etc.

I don't think the ncurses underlying termcap database is required. The Zephyr equivalent is probably a set of macros and defines that describe each display's capabilities and allow unusable features to be compiled out making the code as small as possible. Possibly the terminal capabilities could be embedded in the device tree entry for the device.

ncurses also includes a whole set of input functions, but these are probably not necessary for a character display. ncurses is also capable of handling multiple windows this would be useful on a system with multiple character displays.

I am not suggesting that we port ncurses, that would be crazy, just use some of the basic ncurses APIs and do our own simplified implementations.

Update - I took a look at the ncurses APIs, and I have a suggested subset attached. zcurses.txt

[thedjnK]

I think what @thedjnK is really looking for is a package like ncurses above the character display

I'm not.

[lawrencek52]

I think what @thedjnK is really looking for is a package like ncurses above the character display

I'm not.

Every function you asked for is covered by the ncurses API.

[henrikbrixandersen]

Every function you asked for is covered by the ncurses API.

This has nothing to do with ncurses.

It's a driver API for a specific class of display hardware: text based displays (as opposed to graphical/frame buffer displays, which are already supported by Zephyr).

ncurses is a library for creating text-based user interfaces (TUIs). Now, one might want something along the lines of ncurses in Zephyr, but that would still need to operate on top of a low-level hardware driver API like the one suggested here - and it is out of scope for this PR.