Bug 449878 - With multi-monitor setup, a monitor that is disabled does not power off
Summary: With multi-monitor setup, a monitor that is disabled does not power off
Status: RESOLVED FIXED
Alias: None
Product: KScreen
Classification: Unclassified
Component: common (show other bugs)
Version: 5.24.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kscreen-bugs-null@kde.org
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2022-02-09 18:45 UTC by ready2rumbel
Modified: 2022-03-29 09:35 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24.4


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ready2rumbel 2022-02-09 18:45:50 UTC
SUMMARY
My laptop has an external monitor connected to it via DisplayPort. On the desktop, under 'Display and Monitor', it has been configured to disable the laptop monitor and enable the external monitor as the sole default. When the laptop boots up, the boot/loading screen is displayed on the laptop up to the login screen. Once logged in, the laptop monitor should power off and display only on the external. This has been the case from Plasma 5.23.5 and pre.

As of 5.24, the sequence is practically the same except the laptop monitor does not power off. Instead, it remains powered on while showing the last frame displayed on it prior to swapping over to the external monitor. The only way, in this instance, to power it off is to manually close the laptop lid.

This behavior applies even to the inverse configuration; setting the laptop screen as the sole primary default and disabling the external monitor, assuming the OS loaded with the external monitor enabled.

STEPS TO REPRODUCE
1. Under 'Display and Monitor', enable an external monitor and set it as primary. Then disable the internal/laptop monitor.

OBSERVED RESULT
The disabled monitor does not power off, instead it remains powered on while stuck showing the last frame before it was disabled.

EXPECTED RESULT
When the monitor is disabled, it should power off.

SOFTWARE/OS VERSIONS
Linux: Fedora 35 KDE
KDE Plasma Version: 5.24.0
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
System:
  Host: xxxxx Kernel: 5.16.5-200.fc35.x86_64 x86_64 bits: 64
    Desktop: KDE Plasma 5.24.0 Distro: Fedora release 35 (Thirty Five)
Machine:
  Type: Laptop System: ASUSTeK product: ROG Strix G513QY v: 1.0
    serial: <superuser required>
  Mobo: ASUSTeK model: G513QY v: 1.0 serial: <superuser required>
    UEFI: American Megatrends LLC. v: G513QY.316 date: 11/29/2021
CPU:
  Info: 8-core model: AMD Ryzen 9 5900HX with Radeon Graphics bits: 64
    type: MT MCP cache: L2: 4 MiB
Graphics:
  Device-1: AMD Navi 22 [Radeon RX 6700/6700 XT / 6800M] driver: amdgpu
    v: kernel
  Device-2: AMD Cezanne driver: amdgpu v: kernel
  Display: wayland server: X.Org 1.21.1.4 driver: loaded: amdgpu,ati
    unloaded: fbdev,modesetting,radeon,vesa resolution: 1920x1080~144Hz
  OpenGL: renderer: AMD Radeon RX 6800M (navy_flounder LLVM 13.0.0 DRM 3.44
  5.16.5-200.fc35.x86_64)
    v: 4.6 Mesa 22.1.0-devel
Comment 1 ready2rumbel 2022-02-10 15:38:02 UTC
Another side effect of this is that the mouse cursor, in certain game menus, stutters (which may be related to an inherent Wayland multi-screen & VRR quirk; I'm trying to find the link to a thread that described this).
Comment 2 ready2rumbel 2022-02-10 15:52:12 UTC
(In reply to ready2rumbel from comment #1)
> Another side effect of this is that the mouse cursor, in certain game menus,
> stutters (which may be related to an inherent Wayland multi-screen & VRR
> quirk; I'm trying to find the link to a thread that described this).

I mentioned this because this mouse stuttering didn't occur in Plasma 5.23.5, so based off reading that nugget of info + the current symptoms, the monitor may still be registered as active despite Plasma/kwin indicating otherwise.
Comment 3 Zamundaaa 2022-02-24 03:21:37 UTC
Is some kernel argument set, like amdgpu.dc=0? And are you using any environment variables for KWin?

This sounds a lot like the legacy driver bug that https://invent.kde.org/plasma/kwin/-/merge_requests/2019 fixes, but by default your hardware should use the atomic modesetting pathways.
Comment 4 ready2rumbel 2022-02-24 06:58:06 UTC
(In reply to Zamundaaa from comment #3)
> Is some kernel argument set, like amdgpu.dc=0? And are you using any
> environment variables for KWin?
>
> This sounds a lot like the legacy driver bug that
> https://invent.kde.org/plasma/kwin/-/merge_requests/2019 fixes, but by
> default your hardware should use the atomic modesetting pathways.

The kernel running is the version provided by Fedora and I've not edited GRUB to modify any amdgpu related parameters. As for the second question, the only thing I've personally tweaked from the out-of-box experience is adding two scripts to /etc/profile.d , one is to force Firefox to start in Wayland mode (export MOZ_ENABLE_WAYLAND=1) and the other is to set my dGPU as the primary adapter (export KWIN_DRM_DEVICES=/dev/dri/card0:/dev/dri/card1).
Comment 5 Randall Leeds 2022-03-25 03:11:24 UTC
I experience the same.

Operating System: Kubuntu 22.04
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.2
Kernel Version: 5.15.0-22-lowlatency (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-8665U CPU @ 1.90GHz
Memory: 15.3 GiB of RAM
Graphics Processor: AMD Radeon RX 6600 XT
Comment 6 Randall Leeds 2022-03-27 00:31:15 UTC
I've had a chance to test and setting `amdgpu.dc=0` or `amdgpu.dc=1` makes no difference.
Comment 7 Zamundaaa 2022-03-27 14:55:59 UTC
Hmm, the BUG keywords seems to not work again :/

This bug is caused by an assumption in KWin, that there's always at least one enabled output... per GPU. This MR should fix it: https://invent.kde.org/plasma/kwin/-/merge_requests/2185
Comment 8 Zamundaaa 2022-03-29 09:33:21 UTC
Git commit 658457df5f832b593ec9d1c399a5e29a2e9f4ef8 by Xaver Hugl.
Committed on 29/03/2022 at 09:19.
Pushed by zamundaaa into branch 'master'.

backends/drm: attempt a modeset on output disabling

When modesets are necessary, they are attempted when an output on the given
GPU gets presented. With multi-gpu setups however, the situation can arise
where there is only one disabled output on a GPU; in that case KWin eternally
waits and never properly turns off the display.
In order to work around this, explicitly call DrmGpu::maybeModeset when
an output gets disabled.
FIXED-IN: 5.24.4

M  +3    -0    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/commit/658457df5f832b593ec9d1c399a5e29a2e9f4ef8
Comment 9 Zamundaaa 2022-03-29 09:35:18 UTC
Git commit 3e7223a9af4dec6ebb73a46eae8ba0aeb5a2d657 by Xaver Hugl.
Committed on 29/03/2022 at 09:35.
Pushed by zamundaaa into branch 'Plasma/5.24'.

backends/drm: attempt a modeset on output disabling

When modesets are necessary, they are attempted when an output on the given
GPU gets presented. With multi-gpu setups however, the situation can arise
where there is only one disabled output on a GPU; in that case KWin eternally
waits and never properly turns off the display.
In order to work around this, explicitly call DrmGpu::maybeModeset when
an output gets disabled.
FIXED-IN: 5.24.4


(cherry picked from commit 658457df5f832b593ec9d1c399a5e29a2e9f4ef8)

M  +3    -0    src/backends/drm/drm_output.cpp

https://invent.kde.org/plasma/kwin/commit/3e7223a9af4dec6ebb73a46eae8ba0aeb5a2d657