Mmm.. I still think VNC is not a good choice for doing this in kernel space on the Player. Yes, it's got viewers for most platforms, but how many systems have actually installed those viewers? Many systems use the VNC Java viewer, which most VNC servers automatically provide on request from the client. I suppose we could also do that, but it just adds more bloat in support of an inappropriate protocol.

If we use a custom Java app and messaging, we still have incredibly wide cross-platform support, and we still also have to send down the applet, but it will be a much smaller applet than the generic VNC case.

Sending VNC 8bpp quadruples the amount of data that must be transferred, instead of 1KB we then must send 8KB per screen refresh. This effectively rules out any attempt now or in the future to obtain any semblence to a real-time display.

But.. we could then apply the VNC compression to this, for which VNC is famous. Yes, but then the code just gets way more complex, and chews up way too much CPU. This again limits our refresh rate, and could possibly interfere with the fundamental application of smooth music playback.

Speaking of which, doesn't DisplayServer also do music streaming? I don't think VNC does.

VNC is just not as appropriate in this case as the alternatives.

But that's okay, the best proof is code, against which all Linux kernel mods are tested. So go for it anyway, and beat the odds!

To intercept the display, the best place, guaranteed to give the current data, is the "source_buffer" parameter of "display_blat()" in arch/arm/special/empeg_display.c. This buffer is organised as a sequence of thirty-two 64-byte rows. Each byte represents a pair of horizontally adjacent pixels (flipped order), using only the lower 2 bits of each nibble. Thus, "source_buffer" is 4KB, of which we only use half the bits.

I have never actually measured the rate at which display_blat() is invoked, but it is VERY frequent, so you would not want to capture a copy of the buffer on EVERY invocation. For better synchronisation with remote playback, it might be better to grab buffers earlier, from the internal display queues.. but you'd miss the Hijack data that way (it is never queued).

Taking a look at the system LoadAvg values from the "Hijack Vitals" screen can be very instructive, especially when music is playing and visuals are active.. the system is often around or above 100% load, contrary to early claims of light loading from the makers.

Have fun!

-ml