[fritsch]

Yes. It's a shortterm solution. The idea was: Don't run 36 bit if the framebuffer is 24 bit only. We will see. I would be happy to get a working version of this patch into kernel 4.7 stable - so that LE has that fixed. Perhaps some background: Currently the following happens: The 8 bit input is interpolated to 12 bpc and then later down dithered to the display - which I find quite suboptimal, especially in combination with kodi where we only output RGB 8 bit.

Agreed, the patch is the right thing to do when using 8-bit FB. It's also more bandwidth efficient. In Windows, Intel doesn't output 12-bit over HDMI unless the frame buffer format is 16-bit floating point so no sense doing anything different in Linux.

I'm still trying to work on the original bug and need some accurate timings of the screen refresh rate. Is that displayed somewhere inside the Kodi UI or from shell? I need something measured with a timer. Not the theoretical refresh that's computed from the modeline parameters. I need the real-time delta between v-syncs or true FPS.

If there's a similar measured audio rate that would be helpful too. When you tell the hardware to play at 48,000 samples per second, there is usually some drift in the clock due to temperature variation so it ends up playing at like 48.050 for example. Is that measured and reported somewhere?

You can "misuse" ActiveAE for measuring it. Basically turn off Sync Playback to Display and see how often the clock gets corrected. Btw. chris pushed the original hdmi-audio tree, which is now building fine.