| What | Removed | Added |
|---|---|---|
| Assignee | intel-gfx-bugs@lists.freedesktop.org | dri-devel@lists.freedesktop.org |
| QA Contact | intel-gfx-bugs@lists.freedesktop.org | |
| Component | DRM/Intel | IGT |
Reference to Chris' patch: https://patchwork.freedesktop.org/series/14114/
The problem on this machine seems to be that the clock is abou= t .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 t= hink 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 tho= ugh, assuming the the panel has one and the difference in the clocks would be la= rge 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 abo= ut the mismatch). Since userspace is using the dotclock to calculate the MscRa= te (oh, the merriment with dynamic refresh) we should think of someway to remo= ve the discrepancy between the modeline and actual hardware value. At the very basic level, could we fixup the mode as reported via GetCrtc?
| What | Removed | Added |
|---|---|---|
| Resolution | --- | NOTABUG |
| Status | NEW | RESOLVED |
The modeline is inconsistent. Closing for BAT as we skip over =
this
inconsistency, will address in a separate non-BAT test with kms_setmode.
| What | Removed | Added |
|---|---|---|
| Status | RESOLVED | CLOSED |