Coffee is amazing, isn't it. Not good to let your blood caffeine levels drop too low (well, at least not while debugging code, that is).
Anyway, I found the problem in
gmplay bit packing. When I duplicated a block of code from 4-bit pixel packing, and modified the copies suitably, I did not logically OR them together, so only the second code block was having any effect on the display. Adding in that missing logic OR made it all work properly.
When the video playback competes,
gmplay reports (to standard output, which is redirected to /mnt/us/documents/RUNME.txt, where it can be viewed on the Kindle):
"1153 frames in 620.6 secs = 1.9 FPS"
That is about 27% faster than when running on a kindle DX, but I think we can do better than this (by reducing the eink update area, though we can provide a nice static dithered grayscale border surrounding the smaller video window, and even though full grayscale, it only does a full-flash update once when it is first drawn).
The next step is to port my 2-bit eink changes back into my gmplay-2.0 (with sound). But I have yet to test sound support on the K1...