There have been some PRs for additional modes for modframebuf (XRGB, RGB, VMSB), as well as clarifying the way the framebuf interacts with the host and target-display endianness (which means adding additional BE/LE modes).

#3536 -- Endianness handling for RGB565 framebuf mode.
#3551 -- extmod/modframebuf: add 24bit RGB support (RGB888)
#4880 -- extmod/modframebuf: add XRGB8888 format
#4887 -- Add support for MSB vertical mode

It's worth noting that although most MicroPython boards are unlikely to have enough RAM for an XRGB/RGB framebuffer for all but the smallest LCD/OLED displays, they are potentially very useful for things like APA102 and WS2812 LED strips,

Each new mode adds code size, and this code size affects all ports/boards that include modframebuf (most of them!). Rather than splitting this across four PRs, it would be good to consolidate (and possibly consider alternative approaches).

Some ideas for areas to investigate:

• Implement modes more (code-size) efficiently (possibly at a speed tradeoff)
• Making modes dynamic (i.e. via the dynamic native module mechanism) or even make framebuf not part of the core firmware and always used as a dynamic module (need a way to run .mpy files out of flash though).
• Other colour-related improvements to framebuf (i.e. blit to a framebuf with a different colour mode, possibly supplying a palette - see RFC extmod/modframebuf.c Support for blitting from 1-bit to n-bit colour maps #2973).