Bugzilla – Bug 1177770
Most available resolutions on laptop display don't work (black screen)
Last modified: 2022-01-07 14:05:55 UTC
- go to System Settings / Display and Monitor
- select the laptop's built-in display
- unfold the dropdown of available resolutions
- select one
Expected: should work. If a resolution is not supported then it shouldn't have been available in the dropdown in the first place. If something goes wrong I should get an error message
Observed: only a very small subset of resolutions work. If you select any of the others, the screen goes black (but it doesn't turn off). Also there's no timeout after which setting changes are reverted if not confirmed (that's a separate issue), so you cannot switch it back, unless you act blindly without seeing what you're doing.
That's actually what I do to go back: I hit the switch-screens hardware key on the laptop keyboard, then use the arrow and Enter keys to select some option from the selection menu that I know pops up even though I can't see it, and that somehow causes the screen to go back to the previous resolution (which by the way is unexpected but saves me in this situation) and hence the screen goes back to functioning.
I have also tried the same on Tumbleweed, and everything works as expected. I think the list of resolutions is exactly the same; what I can tell for sure is that all the listed resolutions work, and they actually correspond to what is advertized, and many of them were present in Leap's list and didn't work.
So, the issue is fixed in Tumbleweed. It's a critical enough issue that the fix has to be "backported" (if that is even the word) to Leap.
Operating System: openSUSE Tumbleweed 20201012
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.75.0
Qt Version: 5.15.1
Kernel Version: 5.8.14-1-default
OS Type: 64-bit
Processors: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Memory: 5.7 GiB of RAM
Graphics Processor: AMD RAVEN
Yeah. It's a rather new GPU and the support in newer Kernels (5.8 on TW) is much better than with Leap 15.2 Kernel (5.3).
Let us know which commits to be backported. We have no hardware to test, so it's hard to judge in our side, unfortunately.
Other than that, using the kernel in Kernel:stable would be the best option, so far, for a case like this to support a new hardware.
> Let us know which commits to be backported
You are being sarcastic, right?
> Other than that, using the kernel in Kernel:stable would be the best option
"stable", that's a funny name:
(In reply to teo teo from comment #3)
> > Let us know which commits to be backported
> You are being sarcastic, right?
You'll become so if you're asked to find a possible cause without actual hardware from (literally) thousands patches, too :)
> > Other than that, using the kernel in Kernel:stable would be the best option
> "stable", that's a funny name:
It's a total FUD.
The fact is that it was *NO* kernel problem. Even it wasn't a bug in kernel-firmware package. The culprit was in the rpm that handled files incorrectly.
Hence the bug has nothing to do with Kernel:stable things at all.
Back from side-step: the basic strategy to find the already existing fix is "divide-and-conquer". That is, we want to narrow down the possible ranges at first.
For example, trying different kernel version and check whether the problem is fixed -- that would be already a great help. There are some old kernels available in my OBS repos, e.g. OBS home:tiwai:kernel:5.4, home:tiwai:kernel:5.5, etc. Leap 15.2 is 5.3, and suppose you've tested 5.8.y in Kernel:stable, then identify which version between them (5.4, 5.5, 5.6, 5.7) starts working.
Once after you figure out the first working kernel, we want to see the kernel debug messages from DRM stack. Boot the kernel with drm.debug=0x0e option and give the dmesg outputs from both working and non-working cases. It allows us to compare which modes are wrongly configured.
Ideally, after this, we may perform git bisection or such, but this would require the manual kernel build, so it's not always a feasible option.
Closing, no response.