Bug 383633 - Putting external monitor in standby suspends laptop and stops video signal to external monitor
Summary: Putting external monitor in standby suspends laptop and stops video signal to...
Status: RESOLVED WORKSFORME
Alias: None
Product: Powerdevil
Classification: Plasma
Component: general (show other bugs)
Version: 5.10.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-17 14:17 UTC by Jonathan Wakely
Modified: 2022-12-08 05:14 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Wakely 2017-08-17 14:17:27 UTC
I have a laptop on AC power with an external monitor connected via DisplayPort. The laptop lid is closed. Powerdevil is configured to suspend when the lid is closed, but not when an external monitor is connected.

When I turn off the external monitor (e.g. because I'm going to lunch or otherwise AFK for a while) my session is locked, the system is suspended, and the external monitor no longer gets any signal until after I open the laptop lid to unsuspend and then unlock my session.

Steps to reproduce:

Press power button on external monitor to go to standby.
Press again to turn back on.

Results:

When turning the monitor back on I briefly see the locked session screen, prompting me for a password to unlock, and then the display goes dark. The monitor pops up a dialogue saying "Switching to power-save mode" meaning that there is no signal from the computer. Using the mouse or keyboard does not wake the system up again, I have to open the laptop lid or press the power button to get the session unlock screen back. Once unlocked I find that my network connections have been dropped, so any VPN session is lost and must be reconnected. This is extremely disruptive.

If I change the Powerdevil settings to "When laptop lid is closed: [Do nothing]" then this doesn't happen. It seems that turning off to the external monitor (N.B. just putting it in standby, not actually unplugging it from AC power) is now interpreted as disconnecting that monitor, so the powerdevil settings for the closed lid take effect.

This behaviour did not happen with previous versions (I recently upgraded from powerdevil-5.8.7-1.fc24 to powerdevil-5.10.4-1.fc26.x86_64). Previously turning the screen off and on again did not suspend, so didn't lock my desktop or drop network connections. How do I restore that old behaviour?

I do not want putting the  external monitor in standby to be treated as disconnecting it.

I want to be able to have:

[x] Button events handling
           When laptop lid closed [Suspend]
  [ ] Even when an external monitor is connected

And only suspend when the lid is closed if I really disconnect the external monitor, i.e. remove the displayport cable, not just put the monitor in standby.
Comment 1 Jonathan Wakely 2017-08-17 14:21:03 UTC
(In reply to Jonathan Wakely from comment #0)
> And only suspend when the lid is closed if I really disconnect the external
> monitor, i.e. remove the displayport cable, not just put the monitor in
> standby.

In other words, I want the monitor's power button to only turn off the monitor, not suspend the entire system. If I wanted to suspend the computer I would do that.

I just want to turn the screen off to save power while I'm not using it, but I need my system to keep running in the background, and keep VPN connections up.
Comment 2 Jonathan Wakely 2017-08-17 14:28:53 UTC
With the current behaviour when I go to lunch I have to leave the screen on, so that powerdevil will switch it to energy saving mode after 10 minutes. This wastes power for 10 minutes.

Alternatively I have to change the button events handling depending on whether the external monitor is connected or not. That completely defeats the purpose of the "Even when an external monitor is connected" option, if I have to manually adjust the settings each time I connect/disconnect from the monitor.
Comment 3 Justin Zobel 2022-11-08 06:50:01 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 4 Bug Janitor Service 2022-11-23 05:14:46 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Bug Janitor Service 2022-12-08 05:14:18 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!