Pyboards (PYB, WiPy, ESP8266, etc) should be able to drive displays like LCDs and OLEDs. It's currently possible to write such a driver in pure Python, and even get decent performance for small screens. But large displays (even 320x240) have a lot of pixels and doing even simple operations like filling a rectange can take a lot of time written in pure Python.

So, on the one hand, one wants display drivers written in C.

On the other hand, we want to make it easy for people to write a driver to support any display, and hence should keep writing in Python.

One idea to get the best of both worlds is to have a frame buffer module (framebuf?) which does the intensive memory copy operations, and then leave the actual interfacing to a small Python driver (eg I2C, SPI interface). This is similar in philosophy to the filesystem and the block driver protocol.

framebuf would support different colour formats (eg black and white of different bit layouts, greyscale, and RGB) so that it stores data in a way that is native to the display. It would support primitive drawing operations, region copying and font blitting.

The underlying hardware driver just needs to init the display and send the frame buffer data out on the wire.

I already implemented a proof-of-concept of this idea for the ESP8266, using an SSD1306 OLED display, and it works well.

Comments welcome! In particular, @peterhinch I'm interested if/how this could help with your epaper driver.