Screen resolution resets to 640x480 when waking monitor
After roughly 10 months of using Bazzite with no monitor issues, I've twice today returned from being afk to find my monitor is suddenly at what appears to be 640x480. I ran journalctl to try and figure out what the problem is and found the following:
The second time, I received a Discord DM in the same timeframe as the error, which makes me wonder if it has to do with receiving notifs while the monitor sleeps.
While rebooting seems to alleviate the issue, I'd rather not have to run the chance of having to reboot every time I walk away from the keyboard.
Hardware:
CPU: Ryzen 7 7800X3D
RAM: 32GB
GPU: Radeon RX 7900XT
Monitor: MSI G273, connected over DP
Bazzite:
Version: 42.20250916.1
DE: KDE
38 Replies
Thinking back, this isn't the first time I've had weird things happen re: monitor sleep - Ghidra sometimes complains about 0x0 display if my monitor slept with it open - but this is the first one that's this destructive
Found this github issue which describes the same issue on 42.20250915. I rebased down to 42.20250911 as a potential workaround and the repro I mentioned in the initial post no longer seems to cause the error. Will update this thread if it happens again.
GitHub
Graphics driver crash · Issue #3226 · ublue-os/bazzite
Describe the bug A couple of times in the last week, the graphics driver has seemingly crashed when the user session was idle and turned off the screen. Upon moving my mouse and the screen turning ...
this might not be a driver crash
the error just mentions that EDID couldn't be read
EDID is a technology for identifying displays
I'm not completely sure if it's a driver crash either, but the symptoms between what I was seeing and the github issue are too similar to be coincidence imo. 42.20250911 seems to be working so far, though
EDID is usually provided by the monitor itself i think
though there are some cases where it isn't provided correctly
like on the Steam Deck
so there's a way to force specific EDID information
Another person reported the same symptoms on the github thread, also on 42.20250916.1, but didn't supply logs. Given I've been on 42.20250911 for over a week now with no problems, I'm starting to suspect it was a regression in 42.20250915
We have a possible idea of issue, but no resolution if anyone wants to chime up.
@nagito || Knight of Emilia since you were here earlier.
Looking at the issue and how apps also see 0x0 as invalid and no edid and based on the monitor's physical behavior it looks like the monitor is using a deep sleep mode which completely cuts power off until awoken. This is probably leading to linux seeing nothing from it on power up as it may be turning on too slow.
No idea if this can be solved on that side as the monitor has no deep sleep options in the menus so it may just be in-built.
Some form of delay or a way to re-check the monitor after a moment or two MAY solve it. But I have no knowledge on doing that script or otherwise.
My monitor has a slightly similar behavior, but in my case it loses track of the sound device, not edid, on wake from deep sleep.
(thankfully mine lets me turn deep sleep off which solves the issue)
I can only guess the MSI monitor has a rather aggressive sleep mode by comparison.
Dumping edid to somewhere it can be read regardless of monitor power state is probably the simplest workaround, but judging by some convos I've overheard that's not completely trivial. What puzzles me more is why this is a regression on 42.20250915 when all versions I've used since roughly mid-december 2024 haven't had this issue, unless Bazzite is just slightly faster to the point that this is a race condition now
My guess is a performance increase somewhere that means its now checking too fast.
you can force an EDID for a specific display
That's likely the solution is to use the existing edid for the monitor.
That way it doesn't have to find nothing when it's off.
& it's pretty simple to dump the EDID while you have it
A boot and not letting the monitor go to sleep until you have it is probably the best way. I've never done an EDID dump, though.
I haven't had this issue after downgrading so I could do it now and then re-upgrade
This is why deep sleep needs to be toggleable. It's so annoying if the OS doesn't constantly poll the monitor.
Would be nice for this process to be automatable since I'm not the only one encountering it, if github is any indication
...gonna guess that monitor wakes edid last or just doesn't transmit it after it sleeps and just assumes the machine already has it.
Now that you say that, retaining edid as long as a given display is connected could also work, since other symptoms I've had imply that the display is seen as connected but improperly sized when it deep sleeps, but I can't speak for the practicality of implementing such
Would be best to just force it for that monitor. Just don't forget to replace it if you replace the monitor.
The 640x480 is probably because it sees a monitor, but doesn't see an edid or capabilities listing being reported back so it defaults to VESA standard which is 640x480. Basically the universal default supported resolution since the 90s.
Yeah that's probably what I'll do. Just thinking of a longer-term and more global fix
Temp fix first!
Glad I'm familiar with deep sleep being a butt. Even gives windows trouble on rare occasion.
So now my short-term question becomes "how dump edid"
I've had a few monitors with it. One that it's toggleable on, one where it's not.
Ha yes you should ask that of nagito or someone because I ain't got a clue.
the EDID is just in a file
/sys/class/drm/card0-DP-1/edid for example
DP being display portHow do I see which of
card#-DP-# the monitor is connected to?well there's an info center app in KDE
that has a wayland section
which has a lot of info
aha
including the display names
Where do I need to put the edid now that I know which slot to look in
& connectors & stuff
i think you can put the file in
/usr/local/firmwareCreate
firmware if it doesn't already exist, I take it?
And what subfolder(s) within that should I put the edid in, since I doubt it goes in that folder itself/usr/lib/firmware/edid is the standard place but on bazzite you can't normally touch thatSo
/usr/local/firmware/edid? Or is there more to itnot sure if that location works though
the most sure bet is to make an RPM package & install it
so the file could actually go into
/lib/firmwareYou're talking way over my head
i'm gonna need to learn how to do that
Actually I could probably ask in #🎮bazzite since this is a more straightforward question than "thing broke how fix"
Now it's "Monitor asshole. How edid it"