https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #2 from Mario Kleiner mario.kleiner@tuebingen.mpg.de --- Hi,

does it work with some video modes, or none of them?

Can you give me the edid of your hdmi display? Either "xrandr --verbose" output or the Xorg log?

And the syslog when booting with drm.debug=1 at the kernel command line. I think "cat /var/log/syslog | grep drm" for the lines which contain "drm" would be enough.

These EDID errors also happened before, right?

thanks, -mario

https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #4 from Mike Lothian mike@fireburn.co.uk --- Created attachment 101060 --> https://bugs.freedesktop.org/attachment.cgi?id=101060&action=edit Xrandr --verbose

https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #6 from Mike Lothian mike@fireburn.co.uk --- All my devices - PS3, PC, Sky box and OUYA all connect ito the AV Receiver (YAMAHA YHT-199 http://uk.yamaha.com/en/products/audio-visual/hometheater-systems/home-theat...)

That then connects to the TV - I'm pretty sure that's a fairly standard setup

I'll try the debugging for you now

https://bugs.freedesktop.org/show_bug.cgi?id=80029

Mike Lothian mike@fireburn.co.uk changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #101055|0 |1 is obsolete| |

--- Comment #8 from Mike Lothian mike@fireburn.co.uk --- Created attachment 101106 --> https://bugs.freedesktop.org/attachment.cgi?id=101106&action=edit Full Dmesg

Full dmesg. I switched the receiver off and on then then TV off and on - just incase it highlights anything strange

https://bugs.freedesktop.org/show_bug.cgi?id=80029

Mike Lothian mike@fireburn.co.uk changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #101106|0 |1 is obsolete| |

--- Comment #10 from Mike Lothian mike@fireburn.co.uk --- Created attachment 101108 --> https://bugs.freedesktop.org/attachment.cgi?id=101108&action=edit Full Dmesg

Using journalctl -b this time

https://bugs.freedesktop.org/show_bug.cgi?id=80029

Mike Lothian mike@fireburn.co.uk changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #101060|0 |1 is obsolete| |

--- Comment #12 from Mike Lothian mike@fireburn.co.uk --- Created attachment 101110 --> https://bugs.freedesktop.org/attachment.cgi?id=101110&action=edit Xrandr --verbose

This is the xrandr --verbose output

All the logs are with the TV directly connected to the computer now

The TV is a Samsung LE40M87BD and accoring to http://www.trustedreviews.com/Samsung-LE40M87BD-40in-LCD-TV_TV_review it does support Deep Colour

https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #14 from Mario Kleiner mario.kleiner@tuebingen.mpg.de --- Ok, there's nothing suspicious in your edid's or syslog output, everything seems to work according to plan.

Assuming your equipment is working correctly, this leaves dce8 specific setup as suspect. Alex used some special case code for dce5 and dce6, but excluded dce8 from that special case. However we haven't ever tested dce8 + deep color, so maybe it needs that special case as well.

Can you apply and try the patch i just attached? This is a pure guess, but maybe it helps.

https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #16 from Mario Kleiner mario.kleiner@tuebingen.mpg.de --- (In reply to comment #15)

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.

https://bugs.freedesktop.org/show_bug.cgi?id=80029

--- Comment #18 from Mario Kleiner mario.kleiner@tuebingen.mpg.de --- (In reply to comment #17)

After remembering to copy hdmi-extra.conf to default.conf in /usr/share/pulseaudio/alsa-mixer/profile-sets/ (I think that's a known bug) my 5.1 surround worked just fine

Pheew! I'm relieved :). We'll have to check if this patch is the proper fix for all dce-8 or only a special case for kabini's dce-8.3. Maybe we should leave the bug open until the final patch is decided upon and tested.

Thanks for the testing so far!

I noticed this in the logs after playing Big Buck Bunny (big_buck_bunny_1080p_surround.avi)

[ 1043.140] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 62525 < target_msc 62526 [ 1153.407] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 69140 < target_msc 69141 [ 1162.907] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 69709 < target_msc 69710 [ 1237.257] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 74170 < target_msc 74171 [ 1241.357] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 74415 < target_msc 74416 [ 1241.407] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 74418 < target_msc 74419 [ 1241.941] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 74450 < target_msc 74451 [ 1253.324] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 75131 < target_msc 75132 [ 1261.408] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 75615 < target_msc 75616 [ 1261.595] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 75625 < target_msc 75626 [ 1266.474] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 75918 < target_msc 75919 [ 1286.541] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 77121 < target_msc 77122 [ 1287.691] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 77190 < target_msc 77191 [ 1288.441] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 77235 < target_msc 77236 [ 1292.691] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 77490 < target_msc 77491 [ 2152.825] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip completion event has impossible msc 129098 < target_msc 129099

I'm guessing this is unrelated though

Yep, unrelated. This is another new bug introduced into kms-pageflip handling for 3.16. I'll look into this tomorrow, as i have suitable test hardware.

-mario

https://bugs.freedesktop.org/show_bug.cgi?id=80029

Alex Deucher agd5f@yahoo.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED

--- Comment #20 from Alex Deucher agd5f@yahoo.com --- http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c...