Dual Monitor after wake up mirrored

amjafuso · 2016-06-30 13:31:27

Hi

As reported in this thread kernel after 4.3.0-1 does not properly handle dual monitor on my plattform (cpu j1900). In the meantime I tried 4 newer kernels, today 4.6.3 but still no success. My extented desktop on two screens will be mirrored after a wake up. Where should I report this bug? Is there anything I could test to narrow down the cause for faster bug fixing?

Thanks

ToZ · 2016-06-30 17:16:58

I'm running kernel 4.6.3-1:

Linux archer 4.6.3-1-ARCH #1 SMP PREEMPT Fri Jun 24 21:19:13 CEST 2016 x86_64 GNU/Linux

...and I don't see this issue. On resume from suspend, I get the same screen layout back (however, I do have the patch from comment #53 from this bug report installed but this was to fix the issue of external displays not turning back on after a disconnect and reconnect - which isn't your issue).

A few follow-up questions:
1. What version of xfce4-settings are you running:

xfsettingsd

2. Is it possible that you have some configuration or udev rule that sets the monitor configuration to mirrored on resume?
3. Which distro and distro version are you using?

Have a read through this list of bug reports to see if any are related to your problem. I think that this one might be.

amjafuso · 2016-07-01 07:56:40

Good to know it works on your side. Then it seems to be a graphic driver issue. As far as I know graphic driver is a part of kernel, right? The only thing I change is the kernel:

- 4.3 no issues with dual display after resume (expanded screen)
- 4.4 one blank screen after resume (sometimes mirrored)
- 4.6 mirrored after resume, apply/reapply mirrored in screen manager fixes the problem but cairo-dock moved to the other display.

ToZ wrote:

1. What version of xfce4-settings are you running

xfsettingd
============
xfsettingsd 4.12.0 (Xfce 4.12)

Kernel
============
No problem: Linux silent6 4.3.0-1-amd64 #1 SMP Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux
Makes problem: Linux silent6 4.6.3-sparky-amd64 #1 SMP Fri Jun 24 20:43:51 CEST 2016 x86_64 GNU/Linux

CPU
============
model name	: Intel(R) Celeron(R) CPU  J1900  @ 1.99GHz

ToZ wrote:

2. Is it possible that you have some configuration or udev rule that sets the monitor configuration to mirrored on resume?

Shouldn't this apply independant of chosen kernel? Where can I check this rules?

ToZ wrote:

3. Which distro and distro version are you using?

Sparky Linux 4

ToZ wrote:

Have a read through this list of bug reports to see if any are related to your problem. I think that this one might be.

Thanks, had a look now, sounds similar but no solutions so far.

Either graphical driver has changed or kernel has other compiling options. What happens if you deactivate one screen and activate it again (screen manager)? On my side with kernel 4.6 following happens:

- dual screen in expanded mode [vga][hdmi]
- deactivate hdmi screen -> turns black, good.
- activate hdmi -> turns on but in mirrored mode
- BUT: mirrored is not selected in screen manager
- to fix: apply/reapply mirrored

This behaviour seems to be independant of suspend/resume. What is setting mirrored mode even though it's not set in screen manager?

ToZ · 2016-07-01 13:36:16

amjafuso wrote:

ToZ wrote:
2. Is it possible that you have some configuration or udev rule that sets the monitor configuration to mirrored on resume?
Shouldn't this apply independant of chosen kernel? Where can I check this rules?

Probably, yes. They would be stored in /etc/udev/rules.d.

Either graphical driver has changed or kernel has other compiling options. What happens if you deactivate one screen and activate it again (screen manager)? On my side with kernel 4.6 following happens:
- dual screen in expanded mode [vga][hdmi]
- deactivate hdmi screen -> turns black, good.
- activate hdmi -> turns on but in mirrored mode
- BUT: mirrored is not selected in screen manager
- to fix: apply/reapply mirrored

For my Xubuntu 16.04 system, laptop with external hdmi connection:
- dual screen in expanded mode
- deactivate hdmi screen -> turns black, good.
- activate hdmi -> turns on and restores expanded view

So I had a closer look at sparky linux. What I found is that its based on debian sid and that it uses xfce4-settings from the debian sid packages. This package includes the patch from bug #11107. This patch fixes the issue where on disconnect, the screen isn't turned back on. However, if you look at the bug report, there are reports that people are also seeing the same as you - re-connects end up in mirrored mode. It appears that the patch being used isn't complete. Perhaps there is an interaction with different kernel versions as you are seeing.

One other thing, in Settings Manager > Display, make sure that "Configure new displays when connected" to see if it makes a difference.

amjafuso · 2016-07-05 08:13:21

Thank you very much for your time spending in this case.

Downloaded the package with patches but have no idea how to apply this package. I'm used to compile (configure / make / make install) but don't know how to proceed with this package.

I did some further testings last friday and found the following:

- setting "Configure new displays when connected" doesn't help
- replaced hdmi monitor with another one ( samsung S23A550H -> samsung syncmaster px2370 ) and display expands. it seems to be a timing issue?
- still there is an odd behaviour even with kernel 4.3:
- A) display manager -> deactivate hdmi monitor, activate hdmi monitor -> mirror mode. always.
- B) display manager -> deactivate hdmi monitor -> mouseclick on active monitor followed by a click on deactive monitor -> activate hdmi monitor -> expanded mode!

With kernel 4.3 and hdmi monitor samsung S23A550H B) behaves the same
With kernel 4.6 and hdmi monitor samsung S23A550H B) behaves at first the same but soon after switches to mirror mode

Next things I'll do:
- apply the patch once I know how to do it
- install xubuntu to make clear if it's a hardware or a software issue

ToZ · 2016-07-05 12:24:13

The patch is already applied in the sparkylinux (debian sid) package - you don't need to do anything. However, I don't think the patch is complete as there are appear to be some side effects. The best thing to do is follow the bug report and wait for a more complete fix.

You might also want to post to that bug report about your findings related to different kernel versions - it might be helpful info.

amjafuso · 2016-07-07 07:47:49

Thanks for your help.

I did test xubuntu 16.04 and it's the same behaviour. It's a hardware issue (monitor or graphic driver).

Conclusion
==============
- kernel 4.3 expanded mode after wake up works
- kernel > 4.3 expanded mode after wake up is broken (blank or mirror)
- it seems to be a hardware issue (shuttle xs35v4 -> cpu j1900)
- odd behaviour for kernel 4.3 and above (maybe older kernel as well):

start: dual display expanded [vga][hdmi]
A) display manager -> deactivate hdmi monitor, activate hdmi monitor -> mirror mode. always.
B) display manager -> deactivate hdmi monitor -> mouseclick on active monitor followed by a click on deactive monitor -> activate hdmi monitor -> expanded mode!
With kernel 4.3 and hdmi monitor samsung S23A550H B) behaves the same
With kernel 4.6 and hdmi monitor samsung S23A550H B) behaves at first the same but soon after switches to mirror mode

I did report this issue to bugzilla.

Last edited by amjafuso (2016-07-07 07:57:47)

zenaan · 2019-09-16 01:50:28

After many cycles over many weeks, today I solved the two external monitors being reconfigured incorrectly after screen unlock problem with xfce and other desktops:

Different monitors have different "start up" or "monitor boot" latency - in the order of a second, perhaps more with monitors I don't have.

This latency means that even using a keyboard combo to run own xrandr config (perhaps embedded in a script file), has often failed.

Tried using xrandr to first disable all outputs, then wait say 3 seconds. This did not work - it's the monitors "turning on" where this problem lies and my old (~7 years?) Intel i7-2640M with inbuilt "Intel HD Graphics 3000", presumably fails to maintain the desired display port output config for long enough for at least one of my (4K) external monitors to start up.

SOLUTION: run xrandr in 2 steps - first enable one external monitor only, then sleep 1s (I've tried 0.6s, but that was insufficient), then enable both monitors, e.g. like so (vary to suit your monitors of course):

xrandr --output LVDS1 --off --output DP1 --mode "3840x1080" --pos "0x580" --rate 60 --output DP2 --off
sleep 1s
xrandr --output LVDS1 --off --output DP1 --mode "3840x1080" --pos "0x580" --rate 60 --output DP2 --mode "3840x2160" --pos "3840x0"

Attach such a sequence (in a script) to your chosen keyboard shortcut, then after unlocking the screen (XFCE, KDE, whatever), use the shortcut to run this script.

Aravisian · 2019-09-16 02:40:25

zenaan wrote:

After many cycles over many weeks, today I solved the two external monitors being reconfigured incorrectly after screen unlock problem with xfce and other desktops:
Different monitors have different "start up" or "monitor boot" latency - in the order of a second, perhaps more with monitors I don't have.
This latency means that even using a keyboard combo to run own xrandr config (perhaps embedded in a script file), has often failed.
Tried using xrandr to first disable all outputs, then wait say 3 seconds. This did not work - it's the monitors "turning on" where this problem lies and my old (~7 years?) Intel i7-2640M with inbuilt "Intel HD Graphics 3000", presumably fails to maintain the desired display port output config for long enough for at least one of my (4K) external monitors to start up.
SOLUTION: run xrandr in 2 steps - first enable one external monitor only, then sleep 1s (I've tried 0.6s, but that was insufficient), then enable both monitors, e.g. like so (vary to suit your monitors of course):
xrandr --output LVDS1 --off --output DP1 --mode "3840x1080" --pos "0x580" --rate 60 --output DP2 --off
sleep 1s
xrandr --output LVDS1 --off --output DP1 --mode "3840x1080" --pos "0x580" --rate 60 --output DP2 --mode "3840x2160" --pos "3840x0"
Attach such a sequence (in a script) to your chosen keyboard shortcut, then after unlocking the screen (XFCE, KDE, whatever), use the shortcut to run this script.

The best thing about internet forums is the free exchange of helpful ideas,
Thanks for registering to provide this solution that I am sure others (not just myself) will find useful. smile

Last edited by Aravisian (2019-09-16 02:40:55)

deefster · 2020-05-24 20:46:51

for me, the workaround was killing xfsettingsd on login

I created an autostart script that does a pkill on xfsettingsd

It's not ideal, because certain other functionality relies on it, so it may be necessary to run xfsettingsd --replace if you're doing something like changing one of the GUI settings. But killing it will make it so the monitors come back from idle/dpms, so it's worthwhile until a permanent solution is found.

A better workaround would be to detect idle and wake events and write scripts for those, but I haven't gotten that working.

sput_nik · 2021-02-24 19:45:37

I see that this post is very old but I came across this because I had the same issue and this lead me to the solution. Thought I'd share:

I'm running the latest LTS NVIDIA proprietary drivers on my Arch Linux machine.

$ uname -a
-> Linux archnet 5.10.17-1-lts #1 SMP Wed, 17 Feb 2021 11:11:31 +0000 x86_64 GNU/Linux

After reading the workarounds from @Aravisian & @deefster I decided to take a look at systemd power management hooks to see if I could write a script to correct the issue. Systemd will run any executable in the system-sleep directory 1. before suspending and 2. after resuming. This is located at /usr/lib/systemd/system-sleep/ on Arch systems. At this location I found that NVIDIA driver installation had already placed a script here called "nvidia".

#!/bin/sh

case "$1" in
    post)
        /usr/bin/nvidia-sleep.sh "resume"
        ;;
esac

As you can see this script simply calls /usr/bin/nvidia-sleep.sh with an argument of "resume" when the system resumes (pre case is ignored).

So looking at nvidia-sleep.sh I can see that it attempts to write the active VT to a file before the system suspends or hibernates. The script uses the value written to $XORG_VT_FILE But this code is never going to be called as the pre case in nvidia.sh is not handled!

#!/bin/bash

if [ ! -f /proc/driver/nvidia/suspend ]; then
    exit 0
fi

RUN_DIR="/var/run/nvidia-sleep"
XORG_VT_FILE="${RUN_DIR}"/Xorg.vt_number

PATH="/bin:/usr/bin"
case "$1" in
    suspend|hibernate)
        mkdir -p "${RUN_DIR}"
        fgconsole > "${XORG_VT_FILE}"
        chvt 63
        if [[ $? -ne 0 ]]; then
            exit $?
        fi
        echo "$1" > /proc/driver/nvidia/suspend
        exit $?
        ;;
    resume)
        echo "$1" > /proc/driver/nvidia/suspend 
        #
        # Check if Xorg was determined to be running at the time
        # of suspend, and whether its VT was recorded.  If so,
        # attempt to switch back to this VT.
        #
        if [[ -f "${XORG_VT_FILE}" ]]; then
            XORG_PID=$(cat "${XORG_VT_FILE}")
            rm "${XORG_VT_FILE}"
            chvt "${XORG_PID}"
        fi
        exit 0
        ;;
    *)
        exit 1
esac

So I simply modified nvidia.sh to handle the pre case and pass the suspend state to nvidia-sleep and added logging.

new nvidia.sh

#!/bin/sh
echo "NVIDIA executing nvidia.sh"
case "$1" in
    pre)
        /usr/bin/nvidia-sleep.sh $2
        ;;
    post)
        /usr/bin/nvidia-sleep.sh "resume"
        ;;
esac

new nvidia-sleep.sh

#!/bin/bash

if [ ! -f /proc/driver/nvidia/suspend ]; then
    exit 0
fi

RUN_DIR="/var/run/nvidia-sleep"
XORG_VT_FILE="${RUN_DIR}"/Xorg.vt_number

PATH="/bin:/usr/bin"
echo "NVIDIA received: $1"
case "$1" in
    suspend|hibernate)
        echo "NVIDIA creating folder: $RUN_DIR" 
        mkdir -p "${RUN_DIR}"
        echo "NVIDIA writing output from fgconsole to: $XORG_VT_FILE" 
        fgconsole > "${XORG_VT_FILE}"
        echo "NVIDIA changing VT to 63" 
        chvt 63
        if [[ $? -ne 0 ]]; then
            echo "NVIDIA failed to chvt" 
            exit $?
        fi
        echo "$1" > /proc/driver/nvidia/suspend
        exit $?
        ;;
    resume)
        echo "NVIDIA resuming"
        echo "$1" > /proc/driver/nvidia/suspend 
        #
        # Check if Xorg was determined to be running at the time
        # of suspend, and whether its VT was recorded.  If so,
        # attempt to switch back to this VT.
        #
        if [[ -f "${XORG_VT_FILE}" ]]; then
            echo "NVIDIA found VT File"
            XORG_PID=$(cat "${XORG_VT_FILE}")
            echo "NVIDIA deleting VT File"
            rm "${XORG_VT_FILE}"
            echo "NVIDIA changing VT to $XORG_PID"
            chvt "${XORG_PID}"
            echo "NVIDIA chvt success: $?"
        fi
        exit 0
        ;;
    *)
        exit 1
esac

$ journalctl -b -u systemd-suspend.service

...
Feb 23 17:00:02 archnet systemd[1]: Starting Suspend...
Feb 23 17:00:02 archnet systemd-sleep[44578]: NVIDIA executing nvidia.sh
Feb 23 17:00:02 archnet systemd-sleep[44579]: NVIDIA received: suspend
Feb 23 17:00:02 archnet systemd-sleep[44579]: NVIDIA creating folder: /var/run/nvidia-sleep
Feb 23 17:00:02 archnet systemd-sleep[44579]: NVIDIA writing output from fgconsole to: /var/run/nvidia-sleep/Xorg.vt_number
Feb 23 17:00:02 archnet systemd-sleep[44579]: NVIDIA changing VT to 63
Feb 23 17:00:03 archnet systemd-sleep[44576]: Suspending system...
Feb 23 17:00:31 archnet systemd-sleep[44763]: NVIDIA executing nvidia.sh
Feb 23 17:00:31 archnet systemd-sleep[44576]: System resumed.
Feb 23 17:00:31 archnet systemd-sleep[44771]: NVIDIA received: resume
Feb 23 17:00:31 archnet systemd-sleep[44771]: NVIDIA resuming
Feb 23 17:00:32 archnet systemd-sleep[44771]: NVIDIA found VT File
Feb 23 17:00:32 archnet systemd-sleep[44771]: NVIDIA deleting VT File
Feb 23 17:00:32 archnet systemd-sleep[44771]: NVIDIA changing VT to 1

Now when my system resumes the VT file exists and the script is able to chvt to correct one. Anyway this fixed my issue. I think this could be relevant for anyone running NVIDIA drivers on a distro using systemd. At the very least, if you didn't know already, know that you can hook into systemd power management events and perhaps find a workaround.

P.S. Systemd actually has 3 pre cases: suspend, hibernate and hybrid-sleep. Reviewing my logs, it doesn't appear that hybrid-sleep is every triggered on my system/configuration. Just a heads up. You may need to handle that as well.

Systemd Power Managment - sleep hooks

Xfce Forum

Sub domains

#1 2016-06-30 13:31:27

Dual Monitor after wake up mirrored

#2 2016-06-30 17:16:58

Re: Dual Monitor after wake up mirrored

#3 2016-07-01 07:56:40

Re: Dual Monitor after wake up mirrored

#4 2016-07-01 13:36:16

Re: Dual Monitor after wake up mirrored

#5 2016-07-05 08:13:21

Re: Dual Monitor after wake up mirrored

#6 2016-07-05 12:24:13

Re: Dual Monitor after wake up mirrored

#7 2016-07-07 07:47:49

Re: Dual Monitor after wake up mirrored

#8 2019-09-16 01:50:28

Re: Dual Monitor after wake up mirrored

#9 2019-09-16 02:40:25

Re: Dual Monitor after wake up mirrored

#10 2020-05-24 20:46:51

Re: Dual Monitor after wake up mirrored

#11 2021-02-24 19:45:37

Re: Dual Monitor after wake up mirrored

Board footer