Secondary monitor behaviour when configured to left of primary

louise-uk · 2024-04-23 15:39:27

Secondary monitor behaviour different when left and right of primary

Hello everyone,
Running Arch with 6.6.28-1-lts kernel.
Generally very happy with system stablity, but I have an issue with my monitors that I honestly cannot understand, much less solve. I'm stumped at this point and honestly a bit confused now

AMD RX7800XT with
Output: 1 DP-1 - primary monitor (Ultrawide)
Output: 2 DP-2 secondary monitor (1920x1080)
SDDM is my greeter, KDE6 desktop.

If I set DP-2 to the right of DP-1, then everything seems to work as expected - my screen power management works fine, my application dashboard displays on DP-1. However, the secondary monitor is physically to the left of DP-1. If I set display configuration to match this, then my application dashboard appears on the secondary monitor and my screens power off momentarily before switching back on again.

KSceen 2 is running, but I can't see that it makes any appreciable difference to this issue.

I've created a secondary account thinking this was perhaps some local config file related issue, but it is the same behaviour there too.

I'm utterly perplexed here. I don't understand why dual screen should completely break when I have my secondary screen sitting to the left of the primary screen.

I know that plasma 5 had issues with dual screens and I thought that had been resolved with 6, but seemingly not

Is anyone able to offer any suggestions as to what I might be missing here?

Here are the outputs of kscreen-doctor:

**kscreen-doctor output.DP-1.primary**
kscreen.doctor: setop exec returned KScreen::Config(
KScreen::Output(1, "DP-1", connected enabled priority 1, pos: QPoint(1920,0), res: QSize(3440, 1440), modeId: "7", scale: 1, clone: no, rotation: KScreen::Output::None, followPreferredMode: false)
KScreen::Output(2, "DP-2", connected enabled priority 2, pos: QPoint(0,0), res: QSize(1920, 1080), modeId: "0", scale: 1, clone: no, rotation: KScreen::Output::None, followPreferredMode: false) )

**kscreen-doctor output.DP-2.position.0,0 output.DP-1.position.1920,0**
kscreen.doctor: Output position QPoint(0,0)
kscreen.doctor: Set output position QPoint(0,0)
kscreen.doctor: Output position QPoint(1920,0)
kscreen.doctor: Set output position QPoint(1920,0)
kscreen.doctor: setop exec returned KScreen::Config(
KScreen::Output(1, "DP-1", connected enabled priority 1, pos: QPoint(1920,0), res: QSize(3440, 1440), modeId: "7", scale: 1, clone: no, rotation: KScreen::Output::None, followPreferredMode: false)
KScreen::Output(2, "DP-2", connected enabled priority 2, pos: QPoint(0,0), res: QSize(1920, 1080), modeId: "0", scale: 1, clone: no, rotation: KScreen::Output::None, followPreferredMode: false) )

Thank you for any thoughts or help

Last edited by louise-uk (2024-04-23 15:39:53)

V1del · 2024-04-23 15:48:58

What happens if you physically swap the outputs/cables connected to the GPU? Also to have it in better context, what does

kscreen-doctor -o

give you (and post that wrapped in [ code ] [ /code ] tags (without the spaces))? What are the models and cables involved? It sounds like this might also have some kernel issue depending on which port is logically activated again on sleep/switch.

FWIW I have no issues on Plasma 6 in a three monitor setup, with a 6900XT

Last edited by V1del (2024-04-23 15:49:38)

louise-uk · 2024-04-23 20:20:57

Hello, thanks for responding.

The primary is an Asus VG34V and the secondary is an Asus VS247. Probably should have mentioned that DP-1 is connected DP to DP, whereas the secondary monitor (the one with the issues) is DP to HDMI - however, the behaviour also occurs with an HDMI to HDMI cable. I'm not completely sure where I got the cables from - they've been kicking around for a bit, but weren't cheap Amazon basics type cables.
I tried swapping the ports over (and used the previously unused 3rd display port on the GPU, and it's the same behaviour - with the monitor set to the left, standby refuses to work - but on the right of the primary display, it works as expected. I also tried this on the latest zen kernel and the behaviour is exactly the same.

Output: 1 DP-1
        enabled
        connected
        priority 1
        DisplayPort
        Modes:  0:3440x1440@165!  1:3440x1440@60  2:3840x2160@60  3:3840x2160@60  4:3840x2160@50  5:3440x1440@144  6:3440x1440@120  7:3440x1440@120  8:3440x1440@100*  9:3440x1440@96  10:3440x1440@72  11:3440x1440@60  12:3440x1440@50  13:3440x1440@48  14:2560x1440@144  15:1720x1440@60  16:1920x1200@165  17:1920x1080@120  18:1920x1080@120  19:1920x1080@60  20:1920x1080@60  21:1920x1080@60  22:1920x1080@50  23:1600x1200@165  24:1680x1050@60  25:1280x1024@75  26:1280x1024@60  27:1440x900@60  28:1280x960@60  29:1280x800@165  30:1152x864@75  31:1280x720@60  32:1280x720@60  33:1280x720@60  34:1280x720@50  35:1024x768@75  36:1024x768@70  37:1024x768@60  38:800x600@75  39:800x600@72  40:800x600@60  41:800x600@56  42:720x576@50  43:720x480@60  44:720x480@60  45:720x480@60  46:720x480@60  47:640x480@75  48:640x480@73  49:640x480@67  50:640x480@60  51:640x480@60  52:640x480@60  53:720x400@70  54:1600x1200@60  55:1280x1024@60  56:1024x768@60  57:1920x1200@60  58:1280x800@60  59:2560x1440@60  60:1920x1080@60  61:1600x900@60  62:1368x768@60  63:1280x720@60 
        Geometry: 1920,0 3440x1440
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: Automatic
        RgbRange: unknown
        HDR: enabled
                SDR brightness: 200 nits
                SDR gamut wideness: 0%
                Peak brightness: 604 nits
                Max average brightness: 604 nits
                Min brightness: 0.0728 nits
        Wide Color Gamut: enabled
        ICC profile: none
Output: 2 DP-2
        enabled
        connected
        priority 2
        DisplayPort
        Modes:  0:1920x1080@60*!  1:1920x1080@60  2:1920x1080@60  3:1920x1080@50  4:1680x1050@60  5:1280x1024@75  6:1280x1024@60  7:1440x900@60  8:1280x960@60  9:1280x800@60  10:1152x864@75  11:1280x720@60  12:1280x720@60  13:1280x720@60  14:1280x720@50  15:1280x720@50  16:1440x576@50  17:1440x576@50  18:1024x768@75  19:1024x768@70  20:1024x768@60  21:1440x480@60  22:1440x480@60  23:1440x480@60  24:1440x480@60  25:832x624@75  26:800x600@75  27:800x600@72  28:800x600@60  29:800x600@56  30:720x576@50  31:720x576@50  32:720x576@50  33:720x480@60  34:720x480@60  35:720x480@60  36:720x480@60  37:720x480@60  38:640x480@75  39:640x480@67  40:640x480@60  41:640x480@60  42:640x480@60  43:720x400@70  44:1280x1024@60  45:1024x768@60  46:1280x800@60  47:1920x1080@60  48:1600x900@60  49:1368x768@60  50:1280x720@60 
        Geometry: 0,0 1920x1080
        Scale: 1
        Rotation: 1
        Overscan: 0
        Vrr: incapable
        RgbRange: unknown
        HDR: incapable
        Wide Color Gamut: incapable
        ICC profile: none

louise-uk · 2024-04-23 20:36:12

I've also just tried setting the VS247 as primary and the VG34V as secondary. It's the same outcome - if the VS247 is placed to the left of the VG34V, sleep fails to kick in. If it is to the right of the 34V and set as primary, it goes to sleep.

seth · 2024-04-24 07:47:05

Problem #1:

my application dashboard appears on the secondary monitor

Problem #2:

my screens power off momentarily before switching back on again.

The output in post #3 reflects the bogus situation?

DP-1 is HiDPI (probably, kscreen-doctor could add the physical dimension) but (likely) more importantly VRR capable.
DP-2 is neither.
Try to disable VRR or in doubt just run the output at 60Hz
You'd hope this to take care of problem #2

As for problem #1, https://bugs.kde.org/show_bug.cgi?id=411308 (but that's old and on X11 - I suspect the "priority" key might be relevant here)
"kscreen-doctor output.1.vrrpolicy.never" might or not achieve the former (I googled that up and have no idea about the function, there's probably also some GUI)

Edit: lines are hard…

Last edited by seth (2024-04-24 07:48:07)

louise-uk · 2024-04-24 16:45:49

Thanks again for your help -
I suppose the good news is that Problem 1 seems to have fixed itself after a reboot. I'm keeping an eye on this, but fingers crossed.

Problem two:
Correct, post 3 was my kscreen-doctor -o with the monitor sleep issue as it is.
The monitor isn't HiDPI, but yes, it is VRR.
Even weirder is I've just tried setting the primary monitor to 60Hz as you suggested, and standby kicks in, the secondary flickers off then on again, but the primary stays in standby. I have to power cycle the primary monitor to bring it online.

I downloaded some various ISO's and tried livebooting - KDE Neon & Gnome Garuda in an attempt to eliminate either KDE or Arch as the issue here.
Unfortunately, the same problem happens on both those distros, so it looks like this is probably a hardware compatibility issue, given that the hardware works as expected in Windows, so at least I know it's not broken hardware.
Sigh. Thank you for your help though, it's been really appreciated. I'll monitor this going forward and perhaps get some decent branded cables on the offchance that might help.

V1del · 2024-04-24 18:23:07

And maybe try to get the adapters out of the picture, they can often react in weird ways.

seth · 2024-04-24 20:59:45

the behaviour also occurs with an HDMI to HDMI cable

---

the secondary monitor is physically to the left of DP-1. If I set display configuration to match this, then […] my screens power off momentarily before switching back on again.

with the monitor set to the left, standby refuses to work - but on the right of the primary display, it works as expected

setting the primary monitor to 60Hz […] standby kicks in, the secondary flickers off then on again, but the primary stays in standby. I have to power cycle the primary monitor to bring it online.

For clarification, the issue is and has always been waking up from DPMS, not entering DPMS?
This issue only manifests if you change the logical layout (putting the FullHD output at 0x0 and the 4k one at 1920x0, not if the 4k one is at 0x0)?
What is actually the difference after switching to 60Hz compared to the line quoted before?
Are you currently running plasma on wayland or on X11? And does it make a difference?
If the issue manifests on X11, after causing it (ie. the 4k output doesn't wake up), what is the output of "xrandr -q"?

V1del · 2024-04-24 21:26:59

Whoops I'm blind

Arch Linux

#1 2024-04-23 15:39:27

Secondary monitor behaviour when configured to left of primary

#2 2024-04-23 15:48:58

Re: Secondary monitor behaviour when configured to left of primary

#3 2024-04-23 20:20:57

Re: Secondary monitor behaviour when configured to left of primary

#4 2024-04-23 20:36:12

Re: Secondary monitor behaviour when configured to left of primary

#5 2024-04-24 07:47:05

Re: Secondary monitor behaviour when configured to left of primary

#6 2024-04-24 16:45:49

Re: Secondary monitor behaviour when configured to left of primary

#7 2024-04-24 18:23:07

Re: Secondary monitor behaviour when configured to left of primary

#8 2024-04-24 20:59:45

Re: Secondary monitor behaviour when configured to left of primary

#9 2024-04-24 21:26:59

Re: Secondary monitor behaviour when configured to left of primary

Board footer