Strange behavior of 5-monitor setup spread across 2.5 rooms

Linux Support
1

Has been cool to spend more time here, between the linux flavors rather than in the forum of any one flavor. So many of the issues faced are not with the distribution itself, and the insight here seems unique, and reminds me of the pre-2000s ‘hacker’ spirit, before that word was repurposed to mean something negative. I post this from that place, without imposing on anyone’s time, just sharing a problem that is frustrating me in the lab.

My system forgets its display configuration >80% of the time, when I power on my main station. I turn on and off three of the displays with a physical switch mounted on the wall.

I know that is a variable, since the system does not expect displays to be physically removed from power, rather than just turned off at the display ( which is still then powered and present ) but that is too much of a hassle and I just want to touch one button and have it no longer be headless. When the displays are turned off, it remains a headless server.

I am at a 5-display system spread across three stations.

TECHNICALLY it is a 3-display system, with three of the displays hardware mirrored using a ( J-Tech 4K 60Hz 4x1 ) HDMI Splitter. I have one more station I can put up on this system with a sixth display.

image
image191×113 1.37 KB

Right now it has:

  • Three ( Perixx PERIBOARD-335RD ) keyboards.
  • Three ( Logitech G502 HERO ) mice.
  • Four ( Anker PowerConf C200 ) cameras.
  • Three keypads to switch between 9 workspaces and control audio editing commands or window management commands ( like bring window to primary display, since at 2 of the stations I do not have all 3 the displays )
  • Three of the monitors are AOC and two are LG … 3x 27" and 2x 32"

It is based on AMD Ryzen 7 8845HS w/ Radeon 780M on a Beelink SER8

It is currently running Linux Mint 22 with 6.8.0-52-generic

It has been a war to get this far, previously using a different Beelink GTR6 ( based on Ryzen 9 6900HX )

When I reference Beelink model numbers those tend to mean nothing so be forewarned. They reuse the same model numbers with different specifications all the time. Their support team is pretty great, the machines are pretty awesome, but pretty much everything else is raw chaos… which is not so much off-putting as just to keep in mind. Rabbit holes within rabbit holes, when it comes to Beelink information, BIOS updates, etc..

But again, pre-2000s hacker spirit is all over that. It feels like a bunch of hardware guys on another continent, with massive labs I do not have, drop their best into my software guy lab.

I digress, but one thing that has not held up is that in the post-2000s world there is not as much as a hardware guy versus software guy split, I feel like we are now all 80/20 or so, and so I am a hardware-20 and a software-80. Like the Jedi and the Rebels. Both on the same side. One group with a lightsaber made by hand and using the force ( software ) and one group with a fleet of blaster-armed spacecraft ( hardware ) and often dropping Jedi into sure doom, unless he or she is able to come out of it alive. Sometimes come out not alive, but again, I digress.

It is extremely annoying that when I turn off the main station with all three displays, about 80% of the time it forgets the display configuration, and it does not even consistently forget how it forgets it… sometimes it thinks the left display is gone ( which is the one shared across all three stations, in landscape-right orientation ) or sometimes it thinks the right display is gone. Or, at least it deactivates it and I need to go into the display manager to:

  • Reactivate left or right display ( whichever got kicked out of being in the array )
  • Reorient all displays properly
  • Carefully position them correctly again

This causes my screencasting zone to move all the time so it is a huge pain to continually reconfigure OBS with specific X/Y offsets for where the zone being recorded is. I just stopped doing that and used a fixed point I can trust, which is at the bottom of the shared display which ( though forgotten all the time and reactivated ) at least has the same geometry when put back where it belongs.

The workaround that dug me this hole already is that AMD cannot be trusted to power-save displays without hard-locking or otherwise ruining the windows environment and causing need to reboot ( which is also a pre-2000s problem, reboots should not NEED to except somewhere around a solar year )

If I could trust the system to wake up and sleep displays, I would not have a hardware switch and I would just walk away and come back.

All this being said, it feels like the next workaround is to just set everything perfectly, then apply a key combination on the keypad to reset the display configuration…

But that, in my experience, disrupts the display manager stated object pretty hard and is the same kind of destabilizing event as the AMD wake/sleep problems.

… so I put this out there and thank hacker culture for still existing, even by other names.

Hope you all are doing great in here, out there //

P.S. I know I left a TON of diagnostic information out, especially dmesg / syslog errors and the like, but I am starting from just describing the issue not getting into the weeds straightaway. Also it is not something that I feel like can be trusted if fixed so the workaround is more the goal, totally avoiding actually solving the problem… just moving on… like with the hardware switch :upside_down_face:

1 Like
2

“If I could trust the system to wake up and sleep displays, I would not have a hardware switch and I would just walk away and come back.”

So, is it the system won’t suspend and stay suspended? Or, the system does but doesn’t wake up the displays?

If the former, have you tried the GPP0 fix for suspend? I have similar specs (AMD Ryzen 7 3700X w LinuxMint 22.1) and that fixed my issue with suspend.

Posted in LinuxMint forum about this here: B550 Aorus will not stay suspended.

Symptom
Immediately after suspend is invoked the system resumes. This happens regardless of the Linux distro.

Check if ACPI is the culprit
Enter:
sudo /bin/bash -c "echo GPP0 >> /proc/acpi/wakeup"

And then attempt a suspend. If it remains suspended this is the issue.

Fix
Create a service to enforce this fix (this is using the micro editor but use nano or whatever):
Enter:
sudo micro /etc/systemd/system/wakeup-disable_GPP0.service

And add the following:

Unit]
Description=Fix suspend by disabling GPP0 sleepstate thingie

[Service]
ExecStart=/bin/bash -c "echo GPP0 >> /proc/acpi/wakeup"

[Install]
WantedBy=multi-user.target

Then enable and start the service:

systemctl enable wakeup-disable_GPP0.service
systemctl start wakeup-disable_GPP0.service
2 Likes
3

Did you had a look at the tool xrandr?
You can create an sh script with correct display configurations, you might put yourself a bit for creating the correct sh file, but after that it’s no necessary edit it again.

When your have it ready you can save it in a nice folder for you, then when system resume from suspend, and it’s having wrong display settings, you can open terminal and launch that script. Displays should fix by itself and no manual operation needed.

2 Likes
5

Thanks @ricky89: I am aware of xrandr but have not tried that in the current X11 landscape, because I suspected Wayland is in play in some way now, and had not had time to rtfm on whether it is or not, in Linux Mint 22 forward, and if so, how that affects xrandr … in the past if I externally modified the display configuration with xrandr it seemed to confuse Display Manager from then on. Either way, I hesitated to mess with xrandr since around 5 years ago :slight_smile:

I do see XWayland mentioned here, but, did not go further to see what is impacted:

Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
    loaded: amdgpu unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu
    resolution: 1: 3840x2160~60Hz 2: 2160x3840~60Hz 3: 2160x3840~60Hz

One stand-out item about that is that Display Manager does not always seem to always show all the refresh-rate options for one of my displays, and I wondered if I might force the right behavior with xrandr and will come back to that. I think there might be a hardware issue somehow preventing 60hz only at certain times and not others, since I think this display did a bit too much time in the mobile lab, in temperatures over 120 and under -20 degrees Fahrenheit in the past. Might need to just replace that display and solve the real issue, if it is a hardware problem.

I appreciate the nudge toward xrandr and I would definitely wire-up a keyboard shortcut to run a script if that does fix it. Will follow up if so!

@IronRod, I need to verify this after a reboot, but out-of-nowhere I think your solution might have fixed the root issue, for the first time ever with an AMD based Beelink machine, in my experience :exploding_head:

I started from the solution without making it persistent yet:

And that finally allows the displays to shift into power-saving mode, and not turn themselves back on right away. It seems slightly different than your issue ( somewhat the opposite possibly ) because my displays would go to sleep, then as soon as they completely powered down, they would turn right back on again. It would loop through: inactive timeout, initiate sleep, fully reached sleep and powered off displays ( see “no display” come up ), then see the power light switch to standby… then as soon as it switched to standby, the system itself seemed to receive the powered off signal, it would switch them right back on. Would loop forever, and then sometimes interact with another issue and brick the session.

Not sure yet if there was a kernel or firmware change since I last tried this and risked bricking my session ( and losing all application state, with usually 3x9 displays full of programs running, and headless agents and services ) … so will make time to reboot and try again, and report back. For now, after applying the solution proposed, for the first time ever, I have a fully functional station without using the hardware switch!

In the meantime, whether that was it or you pushed me to try again, thank you! Still pinching myself!

EDIT: Pardon, former yes, so the same issue it sounds like, pardon the enumeration of what you already know then.

2 Likes
6

I hope it clears this up for you. This has become an item in my build notes for AMD systems as I’ve seen it with multiple AMD boards.

2 Likes
9

Just had to come back and say WOW before that reboot as soon as I can …

Feels like a whole new lease on life over here. I keep walking back to my station ( that has not had displays burning power and spending their service lives ) and just hitting <shift> and logging back in, like a NORMAL SU… with a surreal feeling of disbelief.

Such a major help, thanks again for the trailtip! I will be watching out for the chance to return the favor in kind.

Solving the root problem within a couple hours?!?!?! Was not in my array of believable outcomes. I feel a LinuxCommunity.io testimonials reel coming on.

( Be advised @hydn, I unmarked SOLUTION until I reboot, as mentioned which should be in a couple days. During maintenance. Right now I believe the solution but need to reproduce the failure and solution. The advice might still have been something that nudged me to try again, and a firmware or other update resolved it. I have every reason to suspect the fix proposed by @IronRod, but until I verify that, I saved marking the post SOLUTION )

Still pinching myself to have a functioning station for the first time in literally years, without need of workarounds!

Update on this… Finally got to that reboot!

The solution persists between reboots. I am not sure whether it is the GPP0 fix, or if it was a firmware/driver update. It seemed like there was a systemctl service required to get it to persist though?

But even further confusing thing is that there seems to be no difference between this output before and after applying the patch.

$ cat  /proc/acpi/wakeup | grep GPP
GPP1	  S4	*disabled
GPP2	  S4	*disabled
GPP0	  S4	*disabled
GPP3	  S4	*enabled   pci:0000:00:01.4
GPP5	  S4	*disabled
GPP6	  S4	*enabled   pci:0000:00:02.2
GPP7	  S4	*disabled

Still just happy to be nudged to fix the root issue rather than subsist on hardware hacks like power switches. And now I’m even more curious what happened!

After kernel update before reboot I am now at 6.8.0-53-generic as well.

Will observe this further but the jury is still out on the root fix, other than the courage to try again sparked by @IronRod getting me to stop procrastinating and retry what previously stopped working. Was it already fixed and I did not try again though? Is it the solution, but it is persisting without a systemctl service?

Unclear… hmmmm. We may never know! :upside_down_face:

10

Yes, the systemctl commands are required to establish this fix as a service that is fired up at boot. Without that, it is his only for the session and would have to be executed manually in each session.

Odd, that you see the same results from cat /proc/acpi/wakeup. I wouldn’t have expected that given your results. Certainly, in my own experience, the GPP0 value changed from “enabled” to “disabled”.

In any case, glad your issue seems resolved. Though, I always dislike when things get “fixed” and I’m unsure why.

1 Like