Bug 1177770 - Most available resolutions on laptop display don't work (black screen)
Most available resolutions on laptop display don't work (black screen)
Status: RESOLVED NORESPONSE
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Kernel
Leap 15.2
x86-64 openSUSE Leap 15.2
: P5 - None : Major (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-10-15 18:35 UTC by teo teo
Modified: 2022-01-07 14:05 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description teo teo 2020-10-15 18:35:46 UTC
- go to System Settings / Display and Monitor
- select the laptop's built-in display 
- unfold the dropdown of available resolutions
- select one
- apply

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
Comment 1 Stefan Dirsch 2020-10-15 18:51:38 UTC
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).
Comment 2 Takashi Iwai 2020-10-16 07:39:39 UTC
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.
Comment 3 teo teo 2020-10-16 15:08:54 UTC
> 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:
https://bugzilla.opensuse.org/show_bug.cgi?id=1177707
Comment 4 Takashi Iwai 2020-10-16 15:21:26 UTC
(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:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1177707

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.
Comment 5 Takashi Iwai 2020-10-16 15:49:31 UTC
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.
Comment 6 Miroslav Beneš 2022-01-07 14:05:55 UTC
Closing, no response.