several ADL bugs (area: timing overrides)

Discussion created by madshi on Aug 2, 2017
Latest reply on Aug 12, 2017 by madshi

Hi there,


Windows 10 x64, Radeon RX 560, driver 17.7.2, ADL 10.2.


I've run into the following 2 critical bugs:


1) With my 4K TV, the ADL refuses to accept any timing overrides that are over 327 MHz pixel clock (which is somewhere around 3840x2160 with 33fps). Which makes no sense because 3840x2160 with 60Hz is available and is working just fine. The EDID reports a max pixel clock of 300 MHz in the HDMI 1.4 info block, but a max pixel clock of 600 MHz in the HDMI 2.0 info block. Maybe the driver only looks at the HDMI 1.4 info block and ignores the HDMI 2.0 info block? I can provide the EDID data (base block + CEA extension block = 256 bytes) if needed.


2) Timing overrides for newly registered custom modes (e.g. using "weird" resolutions or refresh rates) work just fine. Also it works fine for 3840x2160p24. But for some reason I cannot manage to make the 3840x2160p23 timing override show any effect at all in my setup, even after multiple reboots. The API accepts the timing override, and it gets properly listed when I enumerate the timing overrides. So it's definitely there, but it simply doesn't become active. The refresh rate always sticks to 23.976Hz, even if my override asks for 23Hz or 25Hz. I've tested various modes, and so far only 3840x2160p23 seems to refuse to accept the timing override, for some reason. With all other modes it seems to work fine.


I've also found two minor bugs or inconveniences, which aren't critical, but would still be nice to have fixed:


3) If I add a timing override with the "ADL_DL_TIMINGFLAG_H_SYNC_POLARITY" flag set (same with V), and then enumerate the timing overrides, the flag enumerates as "not set". However, if I add a timing override with the flag cleared, and then enumerate the timing overrides, the flag enumerates as "set". So basically "ADL_Display_ModeTimingOverride_Set" and "ADL_Display_ModeTimingOverrideList_Get" seem to interpret the flag in exactly the opposite way. Which probably isn't surprising because the documentation doesn't say if the flag set equals positive or negative sync. It's open for everyone's interpretation, so seemingly the ADL devs themselves were confused, too...  ;-)  Would be nice if you could clarify the flag meaning in the documentation, and make ADL_Display_ModeTimingOverrideList_Get and Set interpret the flag in the same way!


4) Newly registered timing overrides don't seem to take effect until I reboot the OS (or disconnect the display, wait for the "disconnect sound", then reconnect). While this may be understandable, it makes it harder than necessary to test custom timing overrides properly. With Nvidia's and Intel's custom res APIs there's a way to test new timing overrides immediately. Nvidia has a "try" API which doesn't even require a custom resolution to be registered/saved before. With Intel setting a timing override takes immediate effect, but only if the mode (resolution + refresh rate) was already known to the OS. Maybe you can find some way to make this also possible with ADL?


If you need any more information, logs or whatever, I'm willing to provide.