White Overlay on Primary display with 6900HX

Initially discovered in the course of #2666 (closed) and #2668 (closed)

Moving comments from #2666 (closed) over, and then giving photo and video:

One of my whitened screens does have a cursor, but it is as if the layer order is this:

• Cursor at top layer
• White screen
• Windows

There is a white screen being drawn over the windows, under the cursor, for one of my displays.

As I move the cursor over the screen, it changes from text-select to window-resize to default cursor, as if the white-screen is not actually there, and the cursor is moving over the actual environment.

Issue happens with or without power-management or screensaver vs. #2666 (closed) and #2668 (closed). This time it happened while taking a screenshot. Still trying to catch any log activity coinciding with this.

As I move the cursor over the screen, it changes from text-select to window-resize to default cursor, as if the white-screen is not actually there, and the cursor is moving over the actual environment.

---

Experiencing this one under Mint 21.1 Cinnamon with 6.1.0-1015-oem kernel after applying #2666 (closed) firmware reversion. Hardware is Ryzen 9 6900HX onboard a Beelink GTR6.

added DC label

changed the description

The only thing more than the photo that the video shows, is that if I reboot from a terminal, for a moment before reboot the white screen goes away. And same if I restart cinnamon from the CLI. It goes away for a moment, then puts the white screen back over the window environment.

Trying to find something to get back to work faster each time it crashes, and best thing so far is just restarting lightdm ... even just suggesting a faster way to reset the system without losing open windows would be cool if that's possible, since this seems like it is a very superficial error compared to #2668 (closed)

added Raphael label

Please attach your dmesg output. How much ram is in your system?

64gb RAM on the system.

Here is dmesg

dmesg-ESg3.txt

Does reducing the amount of RAM in the system fix it?

I do have 32gb laying around as a backup that I could try if you are pretty confident that would work around the issue for a while?

I think it may help. Can you try?

So far @agd5f I can reproduce this by taking a screenshot! It's the white flash from screenshotting something, that stays!

And: if I remote-desktop into the station, I do not have the white screen.

And for some reason, I was able to remove the white screen with a Cinnamon reset this time, after connecting to the GUI remotely via RustDesk

added Rembrandt label

removed Raphael label

So it just occurred to me looking at your dmesg; you're using a Rembrandt based machine not Raphael like that other bug. So the downgrading the firmware shouldn't have done anything for your hardware.

I've personally never seen an OEM Rembrandt "desktop" machine. Does your vendor offer an option in the BIOS to change how much of your RAM is allocated to VRAM?

[ 2.377776] [drm] Loading DMUB firmware via PSP: version=0x0400003C

For the DMUB F/W you're running the latest one at linux-firmware.git as well.

Does setting amdgpu.sg_display=0 on the kernel command line in grub fix it?

After noticing I could take a screenshot with gnome-screenshot successfully, I checked again and noticed I had used Flameshot and that leaves the white screen. It seems there is an incompatibility with that approach to a screenshot specifically. Since this is leading-edge they probably don't care to address it, but I will watch this until it works....... but use gnome-screenshot if I plan to actually use my system afterward.

Per @superm1 it seems like I went like a hot-knife through butter on issues not directly mine, but very much like mine, on another type of machine. And no, I have not yet found a way to change the VRAM allocation.

@agd5f I can still give that a try to see; does that negatively impact anything else, or is it pretty innocuous a change?

@agd5f I can still give that a try to see; does that negatively impact anything else, or is it pretty innocuous a change?

Actually it won't work in in your kernel. That module parameter was introduced in 6.2 kernel or later.

How about this - can you please try the latest 6.4.y kernel: https://kernel.ubuntu.com/~kernel-ppa/mainline/v6.4.3/

If you can reproduce the error again, let's see if the module parameter improves it.

Alright @superm1 I will give that a try tomorrow. SMG over at Mint suggested the same.

I did notice just now that this is not limited to flameshot but is "fatal" in that scenario. Another thing that triggers it is turning off the displays ( since I am not using screensaver or power-saving automatically ) ... when I lock the terminal, turn off the displays, walk away, come back some time later -- not sure how long -- when I turn the displays on, I have a white screen again.

Except this time, when I login, the white screen goes away, as if the canvas were cleared.

Ooo.. and then as I just locked my screen right now, now the lock-screen is white on the primary display. So evidently the lock-screen canvas was not cleared, or whatever the proper terms.

Seems like mainline 6.4.3 resolves these issues so far. Have not needed to use the kernel command-line piece. The issue and its weird nuanced and inconsistent behaviors seemed to be most inflamed by:

• Taking screenshots, at first at all, then only with flameshot
• Using the screensaver, at first only until unlocked ( blind, no visibility of password prompt, just typing password ) and then even after unlocking: white screen went away in one case, then persisted later in same situation
• Power-saving ( which I am scared to try right now and don't want to have to reboot at the moment )

But I figured I would update this to mention: so far the mainline kernel has something the others do not, which somehow appeased whatever beast is running around in there. Too soon to call it solved, but I see it nearly gone.

changed the description

Removed the photo in description since it is not needed now.

Hmmm.. After turning off the displays overnight, both #2697 and #2668 (closed) are going on, and I got a video.

mentioned in issue #2668 (closed)

Alright. So the primary issue, and only lasting issue, is this one.

#2668 (closed) seems to be an outlier, and I have not seen it for a while.

But now, every morning, I turn on my displays, and have a white overlay.

There is a live cursor, and the cursor responds to windows and states of windows underneath the overlay.

My only measure to reboot without losing application states is to login via remote desktop to interact with the GUI, which is not subject to the white overlay.

It is as if the white overlay is an artifact. It is possible that it is screensaver oriented, but it persists after the screen is unlocked, and I blind-login by entering my password without being able to see the prompt.

Seems like the same issue logged with Manjaro

https://forum.manjaro.org/t/kde-update-made-the-desktop-blink-white-video-inside-epilepsy-warning/132804

That was resolved with 6.1.9 so am curious if this is a regression somewhere, or if it's firmware.

And now the disco/rave/seizure version resurfaced. It seems #2668 (closed) is this issue, but that sometimes the screen "stays still" while blinking, which I called a "white overlay" but which is a flicker, that stopped.

It seems to respond to i/o and underlying system activity in some way. Like right now as I type this, I am basically driving a white-flickering seizure-inducing light show in the primary display.

And per title: it does not seem limited to the primary display, but it always involves primary, and sometimes involves others. Very intense effect that causes actual visual disturbance.

For the moment, in a way that means nothing since nothing remains consistent, reverting back to 6.1.0-1016-oem allows locking and unlocking screen ( so far, without turning off display and back on ) without white flashing or white overlay.

So far heading back to 6.1.0-1016-oem made it one night and morning, of "power off displays" and "power on displays" with manual lock, versus power-saving on and power-saving off, with automatic lock.

No white screen, whether flicker or overlay, but this issue has shown me that can change at any moment.

As mentioned on inconsistency: back to white overlay, morning two of powering off and powering on, after locking and unlocking manually.

This issue inexplicably gets worse suddenly, and makes the machine unusable.

Right now I am suppressing physical reaction to need to puke due to screen flashing per #2668 (closed) which came back.

Starting to wish I only had my original problems, and might go back to the displays turning each other off.

Went all the way back to 5.19.0-46-generic but with current firmware.

Wow I had no idea how many screenshots I took until every one meant I needed to reboot.

So far 5.19.0-46-generic with the latest firmware is most stable.

About to have the courage to try power-saving and screensaver!

As you have 64GB of RAM I believe it's likely that this is a duplicate of #2354 (closed)

Can you try either reducing RAM to 32GB, or using this workaround? https://patchwork.freedesktop.org/patch/549748/

If either of those help the problem, then I think we should mark this as a duplicate.

I think you might be correct @superm1, those seem related/duplicate. I will check the workaround to remove scatter-gather support, and get back to you on if this can be closed as duplicate.

Although I do have 32gb hanging around, I see that as a last last last resort and I would be redlining RAM usage right away. If it comes to downsizing RAM, I might switch computers entirely!

Yeah I don't mean for it to be a solution, it's for a means of confirmation it's the same root cause.

I feel like a bingo ball right now, turning any number of results out randomly. Will start with the workaround ( since this is supposed to be a HA workstation and I am starting to fall behind ) then go from there. Linux Mint just made a lot of changes moving to 21.2 which I ran to, like a moth to flame with all this weirdness going on. Somewhere some way some thing will click here.

mentioned in issue #2718