[Bug 109141] New: 12bpc hdmi causes wrong real refresh rate (swapbuffers return time)

bugzilla-daemon at bugzilla.kernel.org bugzilla-daemon at bugzilla.kernel.org
Wed Dec 9 03:46:37 PST 2015


https://bugzilla.kernel.org/show_bug.cgi?id=109141

            Bug ID: 109141
           Summary: 12bpc hdmi causes wrong real refresh rate (swapbuffers
                    return time)
           Product: Drivers
           Version: 2.5
    Kernel Version: 4.3
          Hardware: Intel
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - Intel)
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: kevmitch at gmail.com
                CC: intel-gfx-bugs at lists.freedesktop.org
        Regression: No

Created attachment 196911
  --> https://bugzilla.kernel.org/attachment.cgi?id=196911&action=edit
Samsung un40eh5000 edid reported by xrandr --prop

I have a Samsung un40eh5000 tv that I connect to my Ivy Bridge Lenovo T530
laptop via mini display-port to hdmi. I have attached the raw and decoded EDID. 

As of 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67, it seems 12bpc gets enabled on
this setup (though I can't imagine that my machine or my TV actually support
that in real life). Unfortunately, this seems to change the effective refresh
rate as measured between returns from opengl swapbuffers calls for example in
glxgears.

       | glxgears fps   |
       +----------------+
xrandr | before | after |
-------+--------+-------+
23.98  | 24.00  | 23.85 |
24.00  | 24.00  | 24.13 |
29.97  | 30.00  | 29.81 |
30.00  | 30.00  | 30.17 |
59.94  | 60.00  | 60.12 |
60.00  | 60.00  | 60.12 |

This is problematic for displaying video at native frame rates. For example
when the actual refresh rate of 24.00 hz could be achieved, 23.98fps video
would only have to repeat a frame every 50 seconds. Now it must either drop or
repeat one every 7 seconds which is much more noticeable.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.


More information about the intel-gfx-bugs mailing list