| Summary: | Disabling laptop screen makes it also external screen disabled | ||
|---|---|---|---|
| Product: | [Plasma] KScreen | Reporter: | soee <kontakt> |
| Component: | libkscreen | Assignee: | Sebastian Kügler <sebas> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | kde, tietze.heiko |
| Priority: | NOR | Keywords: | multiscreen |
| Version: | git | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | http://commits.kde.org/libkscreen/90d8ee283f88cb07ff936ecb497b277593b99b98 | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: |
Screens configuration is System Settings
Wrong panel rendering after unplugging/plugging in hdmi cable kscreen.log Working screens configuration |
||
|
Description
soee
2016-08-18 12:07:58 UTC
Created attachment 100658 [details]
Screens configuration is System Settings
Created attachment 100659 [details]
Wrong panel rendering after unplugging/plugging in hdmi cable
Created attachment 100660 [details]
kscreen.log
Some more info: Dell Inspiron with hybrid graphics: Intel + Nvidia (working on nvidia profile with 370.23 propriety driver version). External screen is LG 29UC97C using 2560x1080 resolution. Could you please test this in the Intel profile as well? Yes i have the same issue on Intel profile. Also - as you can see on the second attached screen - after hdmi cable is unplugged and plugged in again (as i mentioned in bug report) the laptop screen is black (after i move whole panel to connected screen) and i do not have context menu when i right click on it etc. I have to restart plasmashell to have them laptop screen configuration back (wallpaper etc). plasmashell is entirely orthogonal here. We just look at the screen setup. Could rm kscreen.log, recreate the issue on Intel, and post that log as well? Before i do the check i wanted to report one thing: having the problem i switched back to Nvidia profile and did come power configuration setup changes System Settings -> Power Management -> Energy Saving: [X] Button events handling When laptop is closed: Turn Off Screen [X] Even when an external monitor is connected Than i closed laptop's lid and had only external screen active - pretty good os far. After reboot though GRUB/sddm is always loading on laptop screen (probably because user configuration is not available here) so i have to open laptop lid, login and ... this time even with laptop lid opened i had it's screen disabled as i wanted (see attached screenshot 3). Though i'm not sure why and how it started to work. Created attachment 100662 [details]
Working screens configuration
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? Wrong hunch. DPMS doesn't seem to mess up. What's happening is: - the left screen gets disabled - the right stays enabled, and its position is at the right edge of the left screen - the screen geometry is updated to *the dimensions* of a unified rect of all screens (done in the xrandr backend) - the right screen now falls (at least partly) outside of the screen - the xrandr backend can't deal with this situation and disables the "wrongly" positioned output Worse, in the xrandr backend, we're supposed to have all the policy checks done, so it will also happily disable all outputs. I've reproduced the problem and tracked down where it's going wrong in the code. I have a proof-of-concept patch which makes it work on my disk, which I need to polish up, autotest and post for review. We can fix this by updating the output's positions to the new screen size, basically normalizing all positions to the top-left outputs position. So i should wait with any more tests until your patch lands in master? Yes, I'm pretty sure we got the root cause of this problem by its balls. Proposed patch: https://phabricator.kde.org/D2496 (If you can easily test this, please go ahead and report back. Otherwise, you can wait until it's merged, should only be a few days.) Ow, by the way: you can work around the problem by moving the external enabled screen to the left in the preview, and then disabling the laptop screen, then apply. This should avoid the problem. Git commit 90d8ee283f88cb07ff936ecb497b277593b99b98 by Sebastian Kügler. Committed on 19/08/2016 at 10:43. Pushed by sebas into branch 'master'. normalize output positions in setoperation Summary: When setting a config, outputs may fall outside of the virtual screen layout. This can happen when, for example, a single screen is enabled and its position is not zero. The screen size is a unified rect of the enabled and connected outputs, which doesn't necessarily sit at 0,0 initially. By normalizing the output position, we avoid this pitfall. Especially the xrandr backend struggles with this, since it will disable outputs falling outside of the virtual screen, and it does so after policy checks have happened, so in the worst (and actually fairly common) case, it will disable the only remaining output, leading to ... The reason to do the normalization in SetConfigOperation right before the config is passed to the backends to apply is to catch this inconsistency problem with configs at a common entry-point. Doing it in the library, rather than in the xrandr backend also means that we can autotest it -- we can't sensible do that with the xrandr backend. Test Plan: * manually tested by enabling the left / top most output of two actual outputs, this failed before and left all outputs disabled, with this patch, it works as expected * added autotest to make sure the normalization works Reviewers: #plasma, graesslin Reviewed By: #plasma, graesslin Subscribers: graesslin, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D2496 M +43 -0 autotests/testscreenconfig.cpp M +33 -0 src/setconfigoperation.cpp http://commits.kde.org/libkscreen/90d8ee283f88cb07ff936ecb497b277593b99b98 *** Bug 351826 has been marked as a duplicate of this bug. *** |