>Right, doesn't happen in my car either.

Now that's odd, really odd.

Maybe it's just another name colour thing.

I don't really know what's going on, but I have a theory.

Attached to my next posting is the actual Hijack changes that were new in version 280 -- the problem presumably goes away when using Hijack versions older than v280.

Pretty much the ONLY change that could affect any of this is the new code in v280+ that prevents scrambling of the display controller by having two threads trying to talk to it simultaneously. As of v280, there is a locking mechanism around that code, forcing new writers to wait until the current writer finishes up, and then some.

Perhaps the new player software issues a whole bunch of display controller commands in a row after returning from standby, such that the locking code forces it to wait slightly on each command, adding up to 3-4 seconds or so.

Note that the AUDIO starts immediately, but the display controller -- brightness and buttons -- doesn't become fully functional for a few seconds.

Harmless, but somewhat distracting.

We could fix it by keeping a queue of display controller commands in the kernel, and having a hijack thread to service them over time or something, so that the original caller need not wait for conflict-free access.

Personally, I'm going to ignore it and hope it goes away.

-ml