Add GDEM133T91 13.3" 960x680 panel (SSD1677)

[LordMike]

Summary

• Adds support for the GDEM133T91 13.3" 960×680 e-paper panel (Waveshare 13.3inch-e-Paper-HAT-K)
• Controller: SSD1677 (SSD16xx family)
• Adds gdem133_init_full and gdem133_init_partial init sequences, translated from the Waveshare reference implementation
• Registers GDEM133T91_960x680 in the pixel-based X address window path in setAddrWindow (same tx <<= 3 handling as EP7_960x640, since SSD1677 uses pixel-based X RAM addressing)

The initialization logic has been acquired from the ESPHome project, which already supports this panel (or a very similar one) as 13.3in-k in its waveshare_epaper component.

When doing partial updates, I found that when I only write the dirty regions to the panel, all uninitialized regions become garbled - so memory has to be cleared first. I've used bbepFill to do that. Whilst reading the SSD1677 datasheet, I saw that a special command is in place which is able to fill memory for us, which in my tests was about a lot faster than sequentially writing bytes to memory row by row, so I've added that command in for this panel specifically. To make space for future fast-fill implementations, I've added it to the BBEPDISP struct as a BB_FILL_PANEL delegate. If this is set, bbepFill will use it if it should.

Test plan

• Verify full refresh clears previous image cleanly on GDEM133T91 hardware
• Verify partial update works

🤖 Generated with Claude Code

[LordMike]

I am able to test partial rendering now, and it revealed an issue or two.

[bitbank2]

What problem with partial update? How about fast update? If it's a normal SSD16xx, then you can use custom LUTs from other SSD16xx configurations.

Please change the panel name to be consistent with the other names in the enum. This panel should be: EP133_960x680.

[LordMike]

I experienced that the panel did nothing, submitting the partial refresh after initializing all had no effect. I also experienced that the panel produced artifacts over the entire panel (white noise / static), except for my partially set regions. I'm unsure which of these two experiences came first, it was late last night, there have been many changes & experiments.

What seems to have fixed it is submit an 0x22 with 0xf4 (inspired by GxEPD2), and to submit options to the panel (0x37) which configure the two bitmap banks for diffing. I have not used GxEPD2 on this panel, I'm working out of OpenDisplay.

To be honest, I'm not entirely sure which parts are truly relevant, as epapers are still very new to me (hardware development less so, but its been a while since I last did anything there). I've submitted my changes which allow me to do partial updates consistently. There are a few artifacts, I am unsure if its to be expected - they appear as lines of pixels that turn white, I've spotted two, and they're consistently in the same location. On each partial refresh, they turn more white, so I assume its "ghosting", but I'm not entirely sure.

[bitbank2]

These kludged panels with 2 controllers on one piece of glass have all sorts of incompatibilities with the rest. I gave up trying to fully support the 5.79" 792x272 panels because they just work too differently. Supporting only full updates is not a problem. I am willing to merge your code, but I actively avoid using these panels because they waste my time.

[LordMike]

I've completed my work and think its ready. I've tested and worked with the partial update feature and it seems great.

I also needed a fill method, which you already had (yay) - but I found it could be faster on this IC specifically. Let me know if this is something you want, or if it should be done in a different way.