Created attachment 9407 Debug files Hello, I have a laptop running Debian bullseye and Xfce. A few days ago (after some packages update) I can see a strange behaviour of my desktop. Laptop's screen resolution is 1920x1080 and external monitor has 1920x1200. Laptop is configured to disable the internal display when lid is closed. If I login to the Xfce, connect the external display, and close the lid, then everything work fine - desktop adapts to the external display correctly as expected. In the attached display_debug-ok.txt file you can find .xsession-errors output after closing the lid (when external display is already connected and laptop's screen switches off). But after some time (cannot determine what happens) if I disconnect the external monitor and connect it back, then something goes wrong and desktop doesn't adapt again - desktop remains at 1920x1080, so the bottom panel doesn't go down the screen. See display_debug-fail.txt - there are less events than in the previous case. display_desktop.png shows the desktop at that time and display_settings_laptop.png and display_settings_monitor.png show the display settings. If I re-login to Xfce, then everything work perfectly again for a while. Here is the list of recently upgraded packages that might be involved: - xfce4-settings:amd64 (4.14.1-1, 4.14.2-1) - xfce4-session:amd64 (4.14.0-1+b1, 4.14.1-1) - libxfce4panel-2.0-4:amd64 (4.14.1-1, 4.14.3-1) - xfce4-panel:amd64 (4.14.1-1, 4.14.3-1) - xserver-xorg-core:amd64 (2:1.20.6-1, 2:1.20.7-2) Thanks Zbynek
I have downgraded xfce4-settings package back to 4.14.1-1, restarted xfsettingsd and now desktop resizing works fine again! :) So there must be some regression in xfsettingsd. Maybe it's already fixed in 4.15.0? Regards Zbynek
Looking at the changelog I see nothing that could cause this, to be honest... https://git.xfce.org/xfce/xfce4-settings/tag/?h=xfce4-settings-4.14.2 This is the only "related" patch/change (related as it affected display handling), but it's fairly irrelevant, only initializes a variable: https://git.xfce.org/xfce/xfce4-settings/commit/?h=xfce-4.14&id=db3ca3c489ca33bdca8b616fe321af196462f1ae
Ok, let me try to re-compile 4.14.2 with reverting the mentioned change (display: Initialize crtc->scalex/y).
So I can confirm that reverting that change resolved the issue. I am providing a debug logs (XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon), please see the attached files. - xfsettingsd_debug-ok.txt - xfce4-settings-4.14.2 with reverted mentioned commit - works fine in all cases - xfsettingsd_debug-ok-fresh.txt - upstream xfce4-settings-4.14.2 - works only after fresh login to Xfce - xfsettingsd_debug-fail.txt - upstream xfce4-settings-4.14.2 - fails after some time of running Xfce
Created attachment 9413 xfsettingsd debugs
Are you using RandR display scaling? (The two variables that get initialized there with a default value are responsible for that, I still can't imagine how that would affect your setup/scenario.)
I don't think so, how can I recognize it to make sure? There is another observation to mention - in case of correct desktop resizing I can see that screen of the external monitor goes blank (black) for cca 1 second immediately after closing the laptop's lid. But this doesn't happen when resizing fails.
Just to clarify my previous comment - external monitor goes blank (black) for cca 1 second only with 4.14.2 version with the reverted commit. Upstream 4.14.2 version doesn't do that, even when resizing works correctly (after the fresh Xfce login). Question would be why 4.14.2 stops to behave correctly after some time of running the Xfce environment? Restarting of the xfsettingsd process doesn't help in this case (xfsettingsd --replace). Is there anything I can debug deeper to help resolve the issue? Thanks Zbynek
That patch fixes a bug where plugging in a new monitor causes your other monitors to turn off. I think what is happening is that when you unplug the external, the internal display turns back on (logically anyway) because otherwise you'd have no displays at all. Then you plug in the external monitor and one of two things happens: - Before the patch: the bug happens and causes the internal monitor to turn off. This just happens to be what you want, but it happens accidentally. - After the patch, the bug doesn't happen so the internal monitor stays on. The taskbar is constrained to the smaller one because they both have position 0x0. What happens if you open and close the laptop after getting into the fail state?
I'm sending a display setup when the lid is closed (lid_closed.png) and opened (lid_opened.png) when I'm in the fail state. Also please see the external monitor screenshot (external_display.png) - it's the same for opened and closed lid (nothing changes when opening/closing the lid) in the fail state. > What happens if you open and close the laptop after getting into the fail state? Nothing happens. Desktop setup of the external monitor is the same regardless of the lid state.
Created attachment 9439 Display setup
I'd like to mention that my setup in the Power Manager is to switch off display when the laptop lid is closed (for both on battery and plugged in). This means: - lid is closed -> laptop's display is switched off - lid is opened -> laptop's display is switched on This works as expected.
I can reproduce the bug with 4.14.1. Testing hardware: Thinkpad X240, Dell U2410 monitor on VGA Testing software: Xubuntu 20.04 with default xfsettingsd and also 4.14.2 built from source. Testing method: 1. Start with laptop open, no external monitor connected. 2. ssh into laptop and run "DISPLAY=:0 XFSETTINGSD_DEBUG=1 xfsettingsd --replace --no-daemon" 3. Connect external display. 4. Close laptop. 5. Disconnect external display. 6. Reconnect external display. 7. Open laptop. 8. Close laptop. 9. Now build and install 4.14.2 from source and repeat the above steps. Log files to be attached shortly...
Created attachment 9442 Log file with 4.14.1
Created attachment 9443 Log with 4.14.2
The only difference between 4.14.1 and 4.14.2 that I can reproduce is that 4.14.1 often results in a partially or completely blank screen after a monitor change, which is caused by bug #15971. In both cases the sequence of events is the same: - When I first connect the external monitor, the taskbar is constrained to the smaller of the two monitors. - When I close the laptop, I see this in the log: xfce4-settings(displays): UPower lid event received (open -> closed). xfce4-settings(displays): Normalized CRTC 64: size=1920x1200, pos=0x0. The taskbar is no longer constrained to the internal display because it has been disabled. The external is now the only active monitor. - When I disconnect the external I see this: xfce4-settings(displays): No active output anymore! Attempting to re-enable the internal output. xfce4-settings(displays): Normalized CRTC 63: size=1920x1080, pos=0x0. Here the internal display is re-enabled because there are no other displays left. - When I reconnect the external: xfce4-settings(displays): Normalized CRTC 63: size=1920x1080, pos=0x0. xfce4-settings(displays): Normalized CRTC 64: size=1920x1200, pos=0x0. The newly connected external is enabled, and the internal display is already enabled. Now the taskbar is constrained to the smaller display. - When I open the laptop: xfce4-settings(displays): UPower lid event received (closed -> open). Here, the displays are not reconfigured, because they are already in the correct state for external connected and laptop open. - Finally when I close the laptop again: xfce4-settings(displays): Normalized CRTC 64: size=1920x1200, pos=0x0. Now external is the only connected monitor and the taskbar is at the bottom of the screen.
Some other random observations: "Noutputs" reads 2 when the external is connected and laptop is closed but it reads 1 when the laptop is open and the external is disconnected. I think this is because when you close the laptop, the display is not disconnected, just disabled. The difference in observed behavior may be down to display profiles or the setting "automatically configure connected displays". Both of these affect the way xfsettingsd processes the current display information: Display profiles can cause the display scale to be initialized from the saved profile, meaning that bug #15971 will only happen when the set of connected monitors does not match any known profile. This happens whenever you plug in a new monitor that Xfce has never seen before. It also happens if you unplug one monitor which is part of a set, and the new set does not match any profile. The latter is quite easy to trigger if you have three monitors: you need 7 profiles to cover all possible combinations. If the setting "automatically configure connected displays" is not selected then Xfce won't do anything when a new display is connected and no existing profile is matched. However it will still reconfigure all displays whenever a monitor is disconnected, and I think if a profile is matched. This all adds up to the behavior on monitor connect/disconnect being very hard to debug.
> If the setting "automatically configure connected displays" is not selected then Xfce won't do anything when a new display is connected Note again the difference between "connected" and "enabled" here. When you open the laptop, this is not a connection event, so it is handled differently. Or at least that is how it seems. We really need more in-depth debugging in xfsettingsd to proceed, however it looks as if it will need to query the open/closed state whenever a connection event happens, and take it into account when choosing a profile or making an automatic one.
Thanks Alistair for detailed investigation. Do we have answer for question why 4.14.2 xfsettingsd behaves correctly some time after fresh start of Xfce and then it gets broken? I don't understand this nondeterministic behaviour.
No idea yet. I could not reproduce that part of the bug. I have pushed a branch with a lot more debugging here: https://git.xfce.org/users/ajb/xfce4-settings/log/?h=moredebug This is based on 4.14.2. Can you please get logs using this one?
Also please note that there are two issues here: First, the behaviour that I observed when testing 4.14.2 (reconnecting the external monitor with the lid closed enables both displays, opening and closing the lid disables the internal) is what I expect to happen given the current code. If it does something different for you, that is a bug. Second, for laptops, plugging in an external display should check whether the lid is open or closed, and disable the internal display if it is closed. This is a feature request. I would like to fix the bug before tackling the feature.
I'm trying the moredebug version, but it ends on segfault when closing the lid and opening it again - see debug-segfault.txt.
Created attachment 9474 Debug segfault
Seems to be caused by reading crtc->id here: xfsettings_dbg (XFSD_DEBUG_DISPLAYS, "xdh_toggle_internal: LVDS output %s (CRTC %lu) will be re-enabled.", lvds->info->name, crtc->id);
I have pushed a fix.
Thanks for the fix. I'm running the debug version since Thursday and everything works surprisingly fine so far...
I'm sending the outputs of the debug version. Here is the procedure I have taken: 1. Laptop is with opened lid and external display is disconnected. 2. Connecting the external display. 3. Closing the laptop lid. Debug files are containing outputs for the step 2 and 3. For both ok (display_debug-ok.txt) and failing (display_debug-fail.txt) state to have a chance to compare it.
Created attachment 9498 Display debugs
From the log I can see that when it fails, it thinks you have three CRTCs active. Two of them map to the internal display. When you close the laptop, only one is removed, leaving the other one. This all suggests that there is a problem in the xrandr code used to get monitor information. I'll add further debugging soon...
Is anything I can do it here now?
@Ali: Anything close to a patch?
It's very unlikely I can find the root cause of this before 20.04 if that's what you are getting at. :) I'm really stumped by this. It is as if xrandr reported a monitor twice for some reason. I suspect linked list corruption but I can't see anything that looks wrong.
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-settings/-/issues/155. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev