https://bugs.kde.org/show_bug.cgi?id=367490
Sebastian Kügler <se...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |CONFIRMED
Keywords| |multiscreen
CC| |k...@privat.broulik.de
Ever confirmed|0 |1
--- Comment #10 from Sebastian Kügler <se...@kde.org> ---
Thanks for the report and details. I've had a look at the information, here are
my thoughts:
I can't seem to reproduce this issue, for me, with a laptop and an HDMI screen
attached, the following works:
- When both are connected, I disable the laptop screen in kscreen's kcm in
systemsettings
- this makes all content move to the external monitor, the laptop display is
not part of my desktop anymore (it's now essentially a single-screen system
- when unplugging, the laptop screen gets enabled again, all content moves
there, all is fine
I think powerdevil isn't really helpful here. The "Turn off screen" action has
a bit of an unclear effect:
- for laptops with single screen, "do nothing" will also switch off the display
(the backlight in fact)
- for laptops with dual screen, it triggers dpms off on all screens
These DPMS tricks while we're doing screen changes are tricky, since dpms waits
for some kind of input, and then re-enables the screen, this seems to mess up
the config we receive from xrandr callbacks. This may happen due to dpms
affecting, at least temporarily, the geometry of the screens, like this:
1471559631060 ; kded ; resuming : KScreen::Output( 66 "eDP-1" connected
enabled QPoint(0,0) QSize(-1, -1) "72" )
The QSize(-1, -1) seems to be the culprit, that should not happen.
What seems to work for me is not setting powerdevil to "Turn off screen", but
leave it to suspend, or do nothing, based on your preference (just to avoid the
dpms calls during lid close). Could you try that and see if it works for you?
--
You are receiving this mail because:
You are watching all bug changes.
