Decoding in bidirectional mode: 4bpp?

Has anyone else out there worked on decoding images from the camera in
bidirectional mode? I've rewritten the support for 6bpp images in
xfqcam to work on my machine, and have a first stab at 4bpp decoding.

Could someone with the official Quickcam software confirm that 4bpp bi
mode is faster than 6bpp bi mode? (I blew away Windows by accident
three months ago, never have installed it again.)

If you want to look at what I've done, you can get a copy at
I can't recommend this to anyone unless you want to hack the lowlevel
support code. I did put in comments, though, so it's not hopeless.

I made a minor change to xfqcam's waiting for the status flag on the
bidirectional port (used the more permissive quickcam kernel driver
version). I also wrote a new algorithm for decoding 6bpp bi. On my
machine, the old one was dropping lots of pixels.

I haven't quite figured out the 4bpp support yet. I think I basically
understand it: 3 pixels are packed into each 2 bytes you read out of
the port, the grey coding is the same as the strange 4bpp coding used
in the unidirectional mode.

But I'm getting weird results. Scan line 0 is just fine, the top row.
Scan line 1 is (almost*) entirely useless, though, and scan line 2 is
also useless. Then scan line 3 is picture data again, and represents
what'd you'd expect to see on scan line 1. Ie: only every third row is
valid. To see the effect, compare

In order to make the camera not hang, I had to read three times as
many words out of the camera as you'd expect. I imagine if I chose to
just use every 3rd line, I'd get a coherent picture. But throwing away
2/3 of the camera's output can't be right.

This makes no sense to me at all. Data comes out of the camera in
a raster scan form: scan line 0, then scan line 1, then... Nowhere
else in the reading code can I see any awareness of the length of a
scan line: the camera doesn't seem to expect some sort of indication
that it should start sending the next line. So how could I be seeing
horizontal effects now?

* I said that scan line 1 is almost entirely useless. In fact, the
  first pixel (leftmost one) seems to be the value from somewhere on
  the opposite side of the image (right side). I might be reading
  things one pixel off, maybe that's significant.