|
And yep, Koreader ignores X11 completely. The reason is mainly historically: There wasn't X11 in the Kindle models up to and including Kindle 4.
In fact, I wouldn't be surprised if there wasn't any X11 protocol based API at all. I think Amazon's tech staff just introduced X11 for convenience (GTK, webkit, window management all readily there). But adding e-ink to the game - I wouldn't be surprised if they'd chosen the dirty way.
On a theoretical level, looking from the application's perspective, it's probably a race condition. But when you look at it from the framebuffer driver's perspective, it isn't. You can refresh, you can repaint pixel-wise - both things will be done atomically. There's no order guaranteed, so there's no "right point in time" specification-wise. In a practical sense, however, there is. We're talking single CPU, so a single threaded application will paint, then sync. X11 is special, and probably a game-changer in this regard.
I think analysis hasn't been done yet for this. If I were to start it, I think I would make the framework use TCP as transport protocol, then dump the traffic using tcpdump and use wireshark to look at it (it has a X11 protocol dissector). Maybe there isn't anything to see, though. So alternatively, I'd attach strace to a client and look for refresh ioctl()s.
|