LVGL 'driver' ideas

Developers
1

Hi all,
I’ve got a Tronxy X5SA, which comes standard with a TFT LCD panel, I’m sure there are a few other printers out there in a similar situation. Even vendors are recently shipping custom TFT LCDs with their Klipper default devices (like Qidi).

I’m current writing up something for my Tronxy to use the LCD (with Klipper).
My current plan is that there would be two parts to this:

  1. ‘Parallel port’ bus driver, which would allow for use of the FSMC interface on STM32 devices, potentially PIO on RPI type devices, and similar ‘hardware’ parallel interfaces on other devices.
  2. Creation of an LGVL ‘driver’ which would leverage this parallel interface (or SPI… although I mostly care about parallel). And this is the part where I’m looking for some ideas on implementation / design shape…

LVGL has an imperative API, so there’s a lot of function calls involved. Which becomes a bit tiresome if pushing them all through Klipper commands… lots of Klipper commands also seems ‘bad’ from a resource utilisation sense.

There’s a possible compromise by multiplexing several methods into a single multi-purpose Klipper command (having a command_name param, and then a generic command_params param to be unpacked based on the value of the command_name param)… but this still feels a little unpleasant.

It’d ideally be nice to have a more declarative format. But I’m unsure of a nice way to do the over-the-wire between Klippy and Klipper for this to make it easy on the Klipper side to pass these to LVGL constructs.
With the LVGL functions in mind, the kind of objects that a Klipper direct GUI would utilise, and the way exchanges between Klipper / Klippy are done… any good ideas for how to have them speak?

For the Klippy configuration file interface;
I think ideally I’d like the screen config to stay very closely aligned to the current system. Ideally just with some additional clarification on styling (i.e. options for colours, sizes, positions etc)

My thought is that a copy-paste of the existing serial LCD stuff should ‘just work’ with LVGL defaults, but people could customise it for different colours/styles as they wanted also.

Is there any work that people have already done towards this in Klipper? (using LVGL or a similar LCD library… not just throwing pixels onto an LCD)

2

So far the overarching philosophy of Klipper has been for the last years:

  • Keep the LCD / TFT stuff at an absolute minimum in Klipper’s core
  • Let the “ecosystem”, e.g. Moonraker / fluidd / Mainsail / KlipperScreen etc. handle the user interfaces
2 Likes