<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [bisected] HDMI Errors on drm-next & Linus's tree" href="https://bugs.freedesktop.org/show_bug.cgi?id=80029#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [bisected] HDMI Errors on drm-next & Linus's tree" href="https://bugs.freedesktop.org/show_bug.cgi?id=80029">bug 80029</a> from <a class="email" href="mailto:mario.kleiner@tuebingen.mpg.de" title="Mario Kleiner <mario.kleiner@tuebingen.mpg.de>"> Mario Kleiner</a> <pre>(In reply to <a href="show_bug.cgi?id=80029#c15">comment #15</a>) > That indeed seems to have done the trick Good. Can you test some sound output to your tv, to check if sound sounds properly and not somehow distorted? > > Is there a way to check that it's now using 36bit colour? The fact that you get a functional display means it is using it. Before this patch the gpu was signalling to your tv that it sends a dc36 signal, but it wasn't sending a valid signal, so your tv couldn't decode properly. Now it does. Maybe there's also some deep color or 12 bpc indication in the onscreen display somewhere? A different question would be if the tv does something useful with the extra bits, or just throws them away. At the moment the patches would only affect the precision of the hardware gamma tables, allowing to use their full output precision of 10 bits to get 2 extra bits for gamma correction, so maybe color/gamma correction would produce a bit less banding in some smooth color gradients. Our patches to enable a full 10 bit framebuffer didn't make it into drm-next or Linus tree so far, the pull request is still pending, so i guess they won't make it into 3.16. And userspace also needs work to enable full 10 bits, we have working patches but they are not yet upstreamed.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>