Thanks for your answer. It helps, and at the same time it doesn’t !
Had another look to the datasheets. The 7920 LCD has a character table, the 1306 OLED does not (I didn’t remember).
At the time I coded these things, I was unable to understand the datasheets. (and still am !) I hooked a scope and a logic analyzer, watched the packets, and reverse engineered the packets with some help from the datasheets. You can see videos : Marlin Mode for OctoPrint TouchUI (work in progress) - YouTube (and a couple more), and hardware + software on my Git : GitHub - yet-another-average-joe/MarlinOctoHat_PCBs ; all this crap is integrated and properly wired in a 3D printed (of course…) enclosure. My explanations are most likely unclear, hope the videos will be !
Reading again the SSD1306 datasheet (previously was a few years back…), I see no included character table (unlike the ST7920). Meaning Klipper (or the motherboard firmware) generates characters and sends rasters to the OLED. At least, it is a guess…
If Klipper writes rasters/bitmaps to the OLED, it is easy to decode/reencode.
This is what I did, and been using on my printer for some time : OLED, SPI (only had the SPI OLED). No SPI slave support on the Pi. Used a STM32 as a slave, emulating the SSD1306. It receives the packets (vertical pixel blocks), rearanges these pixels as a more conventional bitmap (easy, it is just some matrix mirroring), then sends a signal to the Pi when a bitmap is completed (i.e. when the OLED is refreshed). The Pi receives this “ready to send” signal, and launches the “SPI conveyor belt”, in order to get the data and then display them in the framebuffer using dispmanx. I later emulated the ST7920 graphics mode because of the lack of support for the OLED with the SKR 1.4 (this was fixed a couple days ago with a bugfix release)
This is low level, but not as low level as what does u8glib or Klipper (this is beyond my understanding).
Definitely worth experimenting with the SSD1306 ; now pretty sure Klipper does send bitmaps to the OLED. Easy to see on the LA : should be 8x pages, that can be seen.
The hardware is there, and after all, it is just a matter of running the Pi software as a service instead of a regular software (have to re-learn how to do it !), after declaring the OLED in printer.cfg… Just in case, I had broken out the OLED pins on my custom Pi Hat : easy to wire.
Will keep you informed (don’t remember how to run my crap as a service, but this is what I did before I decide to launch it through Octoprint…). Going the Klipper route, will not look back. Trying to keep some features I had a hard time to create…
(was about to print, but the controller is now back in the lab…)
Now imagine the Klipper MCU with its encoder replacing the Marlin UI…
[EDIT] had a look to the data Klipper sends to the SSD1306 ; it does not refresh the whole display, and uses a different addressing mode. Would have to redo everything from start, not worth the effort. Klipper Screen does nearly everything that I was missing with OctoPrint, and doing with the Marlin UI.
Will build another printer instead !