Summary: | [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank | ||
---|---|---|---|
Product: | DRI | Reporter: | Chris Wilson <chris> |
Component: | IGT | Assignee: | Default DRI bug account <dri-devel> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | blocker | ||
Priority: | medium | CC: | intel-gfx-bugs |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Chris Wilson
2016-10-20 09:13:34 UTC
Reference to Chris' patch: https://patchwork.freedesktop.org/series/14114/ The problem on this machine seems to be that the clock is about .6% off, whereas the test will accept a deviation up to .5%. I also have a VLV machine with DSI that suffers from a similar problem. I think for internal panels the best solution might be for the kernel to fix up the reported clock for the fixed mode. Not sure what we'd do about the EDID though, assuming the the panel has one and the difference in the clocks would be large enough to be visible in the EDID timings. And of course not all modes coming from the EDID even have actual detailed timing descriptors. Yeah, I'm just sending a patch to detect the "clock error" and teach BAT to skip this test (adding another test to kms_setmode to actually complain about the mismatch). Since userspace is using the dotclock to calculate the MscRate (oh, the merriment with dynamic refresh) we should think of someway to remove the discrepancy between the modeline and actual hardware value. At the very basic level, could we fixup the mode as reported via GetCrtc? The modeline is inconsistent. Closing for BAT as we skip over this inconsistency, will address in a separate non-BAT test with kms_setmode. |
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.