TL;DR: An ASUS desktop with an AMD A10-7800 (Kaveri/Radeon R7) running Zorin OS 18.1 (X11) intermittently loses local display output while the operating system continues running normally. The machine remains fully accessible through RustDesk, and the local user's mouse movements are visible remotely. Running xrandr --output VGA-0 --off followed by --auto restores the display every single time. Windows 10 on the same hardware does not exhibit this issue.
Hello!
I'm new here. I'm somewhere in that stage where I'm not an expert but no longer a complete Linux noob either and capable of borking my system gloriously. I've become comfortable enough to poke around, experiment with kernel parameters (on my machines!), occasionally break things, and hopefully learn something in the process.
I'm hoping someone can either point me in the right troubleshooting direction or recognize what's going on, because I've reached the point where I'm no longer sure what subsystem I'm actually chasing.
The computer belongs to a family member. She wanted to move away from Windows, so I installed Zorin on a second hard drive as a dual boot. Windows 10 is still there as a safety net while she gets comfortable with Linux, and the long term plan is (hopefully!) to retire Windows altogether. GRUB is the primary bootloader, with Windows currently set as the default.
Caveats
- I do not have physical access to the machine anymore, so all troubleshooting is remote only through RustDesk.
Hardware
- ASUS desktop motherboard
- AMD A10-7800 APU
- Integrated Radeon R7 Graphics (Kaveri, PCI ID 1002:130f)
- LG Flatron L1751S-BN monitor (VGA)
Also worth mentioning:
This also happened on a newer Dell monitor using HDMI while I still had physical access to the machine. At the time I didn't realize it was an actual issue—I assumed it was just a random hiccup.
Software
- Zorin OS 18.1 Core
- X11 (originally Wayland, but I switched to X11 hoping it was simply a Wayland bug)
- Kernel 6.17.0-35-generic
- X.Org 21.1.11
- Mesa 25.2.8
- Kernel graphics driver:
radeon
Graphics summary:
Graphics:
Driver: radeon
Renderer: KAVERI (radeonsi)
X11
GNOME Shell 46
Kernel 6.17.0-35
System Setup
The machine dual-boots in UEFI mode:
- Windows 10 on one HDD
- Zorin OS 18.1 Core on a separate HDD
Each operating system lives on its own physical spinning hard drive.
A little extra background (this may be completely irrelevant, but I'll mention it just in case): Windows originally used an MBR partition scheme, so I converted it to GPT using Microsoft's MBR2GPT utility in order to boot both operating systems in UEFI mode without reinstalling Windows. I also used Ventoy to install Zorin.
I have no idea whether either of those details matters, but I've learned that sometimes the weirdest detail ends up being relevant.
The Problem
The monitor itself displays its own "Power Save Mode" message (not simply a blank Linux screen) which tells me it appears to be losing video signal.
The important part is:
The computer itself does not freeze.
I can connect remotely using RustDesk and:
- View the desktop normally
- Open applications
- Launch programs
- Move windows
- Open terminals
- Continue using the computer as though nothing happened
Meanwhile, the local user can still move the mouse.
What really convinced me the operating system isn't crashing is that I can literally watch the user's mouse moving around the desktop through RustDesk while they're telling me over the phone,
"The monitor just says Power Save Mode."
So, as far as I can tell:
- Linux is still running
- GNOME is still running
- X11 is still running
- Graphics are still being rendered
- Only the physical display output disappears
Current Symptoms
The issue has happened in several different situations.
1. Returning to the computer after inactivity
The user leaves the computer for a while.
When they return:
- Monitor is in Power Save Mode.
- Mouse movement does not restore video.
- Keyboard input does not restore video.
2. Booting from a powered-down state
User selects Zorin from GRUB.
Sometimes:
- Login screen appears.
- Within a few seconds the monitor immediately enters Power Save Mode.
Oddly, this is intermittent.
Sometimes it boots all the way to the desktop without any problem.
3. After rebooting
Most recently:
- User returned to the computer.
- Monitor was in Power Save Mode.
- Mouse and keyboard would not wake it.
- User held the power button to reboot.
After reboot:
- BIOS/POST appears normally.
- Linux starts loading.
- Monitor immediately returns to Power Save Mode.
The machine still appears to finish booting and remains fully accessible through RustDesk.
4. Maximizing windows/applications
This is the part that really throws me.
While connected through RustDesk I noticed that simply maximizing certain applications could trigger the problem.
One example:
- A slideshow/presentation was running (I unfortunately don't remember which application).
- The window was maximized.
- Every few seconds the monitor would enter Power Save Mode.
Meanwhile:
- RustDesk continued displaying the desktop normally.
- The slideshow continued.
- The system remained fully responsive.
- Only the local user lost video output.
Diagnostic Information
This command restores the display every single time:
xrandr --output VGA-0 --off
sleep 2
xrandr --output VGA-0 --auto
After discovering it worked every single time, I eventually turned it into a little recovery script because I was using it so often.
When I run it remotely:
- RustDesk briefly loses the display while
--offexecutes. - The local monitor comes back.
- RustDesk regains the display.
- Both local and remote displays recover simultaneously.
This recovery has been 100% reliable.
That makes me think the machine doesn't need a reboot. It simply needs the display output to be reinitialized.
xrandr
When functioning normally:
Screen 0: minimum 320 x 200, current 1280x1024
HDMI-0 disconnected
VGA-0 connected primary 1280x1024
The monitor is detected correctly.
What I've Tried
Disabled DPMS
xset -dpms
Verified:
DPMS is Disabled
Unfortunately the problem still returned later.
Checked GNOME power settings
idle-delay = 900
sleep-inactive-ac-type = 'suspend'
sleep-inactive-ac-timeout = 1800
Verified session type
echo $XDG_SESSION_TYPE
Returns:
x11
Verified graphics driver
lspci -k
Shows:
Kernel driver in use: radeon
What's Confusing
Windows 10 on the exact same hardware does not appear to have this issue.
Windows:
- Boots normally
- Sleeps normally
- Wakes normally
- Maintains video output
The Linux issue has occurred on:
- The LG VGA monitor
- A newer Dell monitor using HDMI
which makes me think the monitor itself probably isn't the culprit.
Current Theories
At this point these aren't conclusions, just the squirrels my brain keeps chasing after reading forums and experimenting.
- Radeon/Kaveri display engine or display-output bug
- Kernel DRM/KMS regression affecting older AMD hardware
- X11 modesetting issue
- GNOME compositor interaction with the Radeon driver
- Display power management triggering a Radeon bug
The fact that
xrandr --output VGA-0 --off
followed by
xrandr --output VGA-0 --auto
always, faithfully, like the lunar cycle, restores both the local monitor and the RustDesk session simultaneously makes me wonder whether the Radeon driver continues rendering the desktop correctly, but the display output itself gets into a bad state until the connector is reinitialized.
Does that theory fit the symptoms, or am I overlooking another subsystem entirely?
Questions
Has anyone seen this behaviour before on Kaveri era AMD hardware?
Has anyone actually found a solution to something like this?
Is there a known GNOME/X11 + Radeon issue where the desktop continues rendering but the physical display output disappears?
Are there any known DRM/KMS regressions in recent kernels that might explain this?
Would it be worth testing an older LTS kernel or Mesa version before I start experimenting with kernel parameters?
The next time I get remote access to the machine, are there specific journalctl, DRM, X.Org, or other logs that would be especially useful to collect immediately after the monitor loses signal?
If you've made it this far, thank you.
I know this turned into a novel, but I figured I'd rather include too much information than too little; especially when consulting the oracle. The I've spent quite a while searching reddit, the zorin forums and elsewhere but I haven't found a solid solution to my similar-but-not-quite-the-same issue. If I've overlooked something obvious or if there are commands or logs that would be more useful than what I've collected so far, I'm more than happy to run them the next time I have remote access.
Thanks in advance for any ideas, points, comments or suggestions!

