Created attachment 101055 [details] Dmesg I'm getting mode not supported on my TV which is connected to a kabini system It bisects back to: d0c94692e0a360828745a469bcf90b5c4f9273d0 is the first bad commit commit d0c94692e0a360828745a469bcf90b5c4f9273d0 Author: Mario Kleiner <mario.kleiner.de@gmail.com> Date: Thu Mar 27 19:59:39 2014 +0100 drm/edid: Parse and handle HDMI deep color modes. Check the HDMI cea block for deep color mode bits. If available, assign the highest supported bpc for a hdmi display, corresponding to the given deep color modes. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> :040000 040000 42cc03b8d280ed165276b9be1c337d52773c4c35 674f7984e5278ae8dc7080344304093020274839 M drivers :040000 040000 cfec2deeddc3827f444ed391efa9c06d8dedb846 50f255ca6a41a02eb039c9eb9a469f762c34df39 M include I'm attaching my dmesg of the errors I see - the EDID ones only appear once I switch the TV / AV receiver off and on
Should probably make clear this works fine on 3.15
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
Hi Mario I'm not sure about other video modes - I always use the native 1080p @ 60Hz I'm not sure how to change it either when I can't see the screen I've attached the verbose xrandr output for you from a working kernel Would you like the debugging put on a working or broken kernel? I don't remember ever seeing any EDID issues except when the receiver was on but the TV was off
Created attachment 101060 [details] Xrandr --verbose
(In reply to comment #3) > Hi Mario > > I'm not sure about other video modes - I always use the native 1080p @ 60Hz > I'm not sure how to change it either when I can't see the screen > > I've attached the verbose xrandr output for you from a working kernel > Thanks. The edid looks ok and spec conformant. If the edid doesn't lie about your device, we should be able to drive your tv with a 12 bit deep color mode at full resolution without problems. > Would you like the debugging put on a working or broken kernel? On the 3.16 kernel. > > I don't remember ever seeing any EDID issues except when the receiver was on > but the TV was off Hm. Can you explain your setup? The TV isn't connected directly to the graphics card, but there's some 3rd party receiver inbetween? Can you give me the name/model of the receiver and TV? The hdmi deep color code has been successfully tested on different panels with dce-4 and dce-6 graphics cards, but not with the latest dce-8 kabini's. This could be something missing in the driver specific to dce-8, or your tv misrepresenting its capabilities.
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-theater-package/yht-199_w/?mode=model) That then connects to the TV - I'm pretty sure that's a fairly standard setup I'll try the debugging for you now
Created attachment 101105 [details] DRM logging
Created attachment 101106 [details] Full Dmesg Full dmesg. I switched the receiver off and on then then TV off and on - just incase it highlights anything strange
Can you try a reboot? Most of the interesting action seems to happen before your syslog starts. If you look at the onscreen display of your tv or receiver, the sections about input signal or output signal, does it say anything about hdmi or deep color etc.? Another good thing to try would be directly connecting the tv to the computer's hdmi out, to see what syslog and xrandr --verbose output then have to say.
Created attachment 101108 [details] Full Dmesg Using journalctl -b this time
Created attachment 101109 [details] DRM debug Grepping drm from journalctl -b
Created attachment 101110 [details] 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
Created attachment 101115 [details] [review] Use dce5/6 hdmi deep color clock setup also on dce8+
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.
That indeed seems to have done the trick Is there a way to check that it's now using 36bit colour?
(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.
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 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
(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
I've added the fix to my drm-fixes tree. It is correct.
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5c868229da7014fc988a8d506264c43c1fcf7f21
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.