Comparison to embedded-graphics

[chrysn]

I've used embedded-graphics occasionally, and now saw your project here. Are there any points of comparison (eg. in features, approach or scope) between those?

[JuliDi]

The main difference is that embedded-dal is far from usable at this point and exists more as an idea in our head.

embedded-graphics is neat for small SPI/I2C displays with not a lot of displays. You can't really use it with bigger displays that are controlled via, e.g., DSI (which is a real pain to use, see here and there is only very basic support for DSI and LTDC that we initially contributed to Embassy).

In terms of approach and scope, embedded-dal is supposed to be more something like embedded-hal is for "regular" drivers (displays are a bit more special, so no idea if our approach can ever work). So we would like to end up with clearly defined interfaces (traits) that define how the GUI (embedded-graphics, slint, ...) interacts with the framebuffer and and how that framebuffer is communicated to the display.

For example if we take the STM32F469 Disco board with its 800x480 pixel RGB LCD, we would have a framebuffer with 800x480 ARGB8888 pixels.
And then we have a display type for this specific LCD that implements several other traits like "Dimmable" or so.

A simple I2C two color OLED display might instead have only a very simple framebuffer that is an array of 200x100 BinaryColor pixels.

--
The ultimate goal is making it much easier to use displays with embedded rust, almost as easy as using embedded linux. With clearly defined interfaces and compatible drivers for all sorts of display driver modules.

Happy to discuss that at some point if you're interested.