The legacy einkfb controller has a thing where when the framebuffer content doesn't change, it basically discards the second eInk refresh.
That *this* chain of event would trip that is somewhat strange (given that the fb content does change), but that's the only explanation I can find
.
I'll see if I can replicate it and find out more
.
My gut feeling is that the pattern is generated by the driver itself and not eips, and that bypasses/messes with that "feature" somehow.
EDIT: Yep,
Code:
eink_fb: W einkfb_print_buffers_equal_message:def:full_screen(non-flashing)
Why eips -c does work is a mystery, though...
EDIT²: Ah, no, not anymore: it's using a dedicated ioctl ;D
Code:
04:25:04 [400e151c] ioctl(3, FBIO_EINK_CLEAR_SCREEN, 0) = 0
EDIT³: Well, while the dedicated ioctl is nice, turns out it's just that the controller doesn't detect the bit of trickery memset() might be doing to the memory behind its back. Explicitly drawing a rectangle works.
So I guess I'll do that, with a shortcut to only the ioctl if the bg color is white.