https://bugzilla.kernel.org/show_bug.cgi?id=208947
--- Comment #16 from Coleman Kane (ck...@colemankane.org) --- Pulling the call / reassignment of "status" added in that commit seems to revert the undesirable behavior, including in the latest "staging-testing" code that I've tested on. My hardware situation seems to be that the "native" resolution of my DP display (3840x2160@60Hz) is also advertised as "supported" by the RX 580m on my laptop, but for whatever reason the GPU is unable to actually drive that resolution. I don't know enough about the hardware to speculate as to why this is, though. Using the "video=" option to the kernel, I can force a functioning video mode, which seems to be consistent with the intent of that variable, when this call is commented out. However, if the call to check_link_loss_status happens, then the inconsistent behavior occurs that I described above where it randomly might work, might only give me 1024x768, or might never display on my DP-connected monitor regardless of the resolution chosen. That said, I wonder if it makes sense to wrap this call with another kernel command-line boolean variable, so the behavior can be disabled in the event someone has a misbehaving GPU or monitor like I do - unless you think there might be a graceful way to auto-identify this type of defect. Not sure how the auto-selection works for KMS console resolutions, but it would be helpful too if it detected that an attempt at a high refresh rate didn't work, it automatically tried lower refresh rates. -- You are receiving this mail because: You are watching the assignee of the bug. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
