Comment 9 for bug 1665802

That's correct, and not a bug in itself. The timestamps are meant to be in the past if the client has fallen behind (its render time jumped from almost zero to 33ms). That's a feature and it has test cases :)

It's possible what's triggering this is bug 1666372 so try the workaround listed for that, or just give your server --composite-delay=0.

However the trigger is one thing, high CPU usage during "27.91 FPS" is still unexplained. I would hazard a guess that this device might have a broken kernel which fails to implement sleep-until-the past correctly [1].

I intentionally did not check if the target time was in the past because it would be an unnecessary extra dip into the kernel. But if this device proves to have a broken timer implementation then it would be a simple workaround.

Can you please try modifying the code to just skip the call to sleep_until for timestamps in the past?

[1] See TIMER_ABSTIME in http://pubs.opengroup.org/onlinepubs/009695399/functions/clock_nanosleep.html