Created attachment 8586 displays.xml Since about two weeks the secondary display is not activated properly, it remains black. I can move windows that do appear there with Alt+space+<Move>, the mouse and movement cursor is visible. If I tweak any knob in the settings that does affect the secondary display, it is instantly drawn. Is there any log to report success/failure of all the actions required to enable both displays as required?
Created attachment 8587 Xorg.0.log.txt
This could also be a bug in xfwm4 - at least running "xfwm4 --replace" fixed this problem for me when I saw this issue for the first time. Did you recently upgrade xfwm4?
I run git.xfce.org#master since a few weeks, and update every other day to the current snapshot. You are right, Alt+F2 and 'xfcm4 --replace' also fixes it. Looks like I can reproduce it 100%.
Is that at startup with the monitor already attached, or when hot-plugging a secondary monitor, or just by enabling/disabling the output using the xfce display settings? FTR, I cannot reproduce with the latter.
This is during fresh boot, the HDMI cable is already attached and the monitor is powered on.
It happens to work with current master. Maybe the update 20190523T214703.89f3ab5d -> 20190528T221425.4efaeafd fixed it?
No, that's unlikely. And I am not convinced this is a bug in xfwm4, I suspect this could be a race between the settings manager adding/configuring the output at startup via xrandr, and xfwm4. If adding/removing/reconfiguring outputs once the session has started works (as it seems it does), then xfwm4 is working as expected. Could that be some recent changes in the session manager and the way it starts the different core components?
Essentially only xfwm4, xfce4-panel, and xfdesktop got updated. Not sure if GTK3 bug#550 also is related "Set a transparent background for windows on X11#". At least it worked now for three boots.
I have not seen this anymore, even with the downgraded gtk3. So it silently fixed it by itself.
I spoke too soon. It may have worked once or twice, but I was on the road for a while. Current workaround: ==> .config/autostart/xfwm4.desktop <== [Desktop Entry] Encoding=UTF-8 Version=0.9.4 Type=Application Name=xfwm4 Comment=xfwm4 Exec=xfwm4 --replace OnlyShowIn=XFCE; RunHook=0 StartupNotify=false
Created attachment 8739 [PATCH] session: Serialize startup of xfsettings daemon As I said in comment 7, I doubt this is an issue in xfwm4, I suspect a race with xfsettingsd at startup. Can you try to apply that patch to "xfce4-session" and retry? Make sure to use the default session and not a custom one (or else make sure to apply the same change to your custom session).
In theory the default session should start services in groups, where xfwm4 is in the first, highest-prio group and xfsettingsd is in the second. Olivier's patch looks good though (thanks a lot!), I'm tempted to push that anyway. But please do test!
Does the same change need to go to /etc/xdg/autostart/xfsettingsd.desktop, or does this one serve a different purpose?
(In reply to Olivier Fourdan from comment #11) > Can you try to apply that patch to "xfce4-session" and retry? This does not fix it: 2024 ? Ss 0:00 \_ /usr/bin/gpg-agent --sh --daemon --keep-display /etc/X11/xinit/xinitrc 2073 ? Sl 0:01 \_ xfwm4 2077 ? Sl 0:00 \_ xfsettingsd --no-daemon 2085 ? Sl 0:01 \_ xfce4-panel I will see if adding a sleep prior launch of xfsettingsd will make any difference.
Can you try swapping the priorities between xfwm4 and xfsettingsd in the session.xml file so that xfsettingsd is started before xfwm4? (currently `xfwm4` has prio 15 and `xfsettingsd` has prio 20 in the session.xml, I'd rather try the opposite to see if that makes a difference, keeping the `--no-deamon` for `xfsettingsd` as well)
Yes, running xfsettingsd first, then xfwm4 appears to work.
Created attachment 8748 Updated patch for xfce4-session I think it makes a lot of sense to start xfsettingsd with the highest priority, because all other components depend on the settings applied by xfsettingsd and applying those after the other components have started is very expensive, clients have to reconfigure themselves, reload fonts, themes, relod xrandr configration, etc. If we load the settings first, the apps do not need all that reconfiguration and therefore that speeds up the startup time.
See also bug 15697
Olivier Fourdan referenced this bugreport in commit 195b423599fd1cde5204a281846318c820e11a61 session: Serialize startup of xfsettings daemon https://git.xfce.org/xfce/xfce4-session/commit?id=195b423599fd1cde5204a281846318c820e11a61
Thanks for the final patch Olivier and the testing Olaf.
Started to happen again with git.xfce.org from this Friday.
Not surprising, we had to revert the change.
-- 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-session/-/issues/55. 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