secondary monitor not fully activated

Submitted by O H @olh

Assigned to Simon Steinbeiß @ochosi

Link to original bug (#15485)

Description

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?

Attachment 8586, "displays.xml":
displays.xml

Version: 4.13.3

See also

• https://bugzilla.xfce.org/show_bug.cgi?id=15697

O H @olh uploaded an attachment:

Attachment 8587, "Xorg.0.log.txt":
Xorg.0.log.txt

Simon Steinbeiß @ochosi said:

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?

O H @olh said:

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%.

Olivier Fourdan @olivier said:

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.

O H @olh said:

This is during fresh boot, the HDMI cable is already attached and the monitor is powered on.

O H @olh said:

It happens to work with current master. Maybe the update 20190523T214703.89f3ab5d -> 20190528T221425.4efaeafd fixed it?

Olivier Fourdan @olivier said:

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?

O H @olh said:

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.

O H @olh said:

I have not seen this anymore, even with the downgraded gtk3. So it silently fixed it by itself.

O H @olh said:

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

Olivier Fourdan @olivier submitted a patch:

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).

Patch 8739, "[PATCH] session: Serialize startup of xfsettings daemon":
0001-session-Serialize-startup-of-xfsettings-daemon.patch

Simon Steinbeiß @ochosi said:

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!

O H @olh said:

Does the same change need to go to /etc/xdg/autostart/xfsettingsd.desktop, or does this one serve a different purpose?

O H @olh said:

(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.

Olivier Fourdan @olivier said:

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)

O H @olh said:

Yes, running xfsettingsd first, then xfwm4 appears to work.

Olivier Fourdan @olivier submitted a patch:

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.

Patch 8748, "Updated patch for xfce4-session":
0001-session-Serialize-startup-of-xfsettings-daemon.patch

Olivier Fourdan @olivier said:

See also bug 15697

GitBot @GitBot said:

Olivier Fourdan referenced this bugreport in commit 195b4235

session: Serialize startup of xfsettings daemon

https://git.xfce.org/xfce/xfce4-session/commit?id=195b423599fd1cde5204a281846318c820e11a61

Simon Steinbeiß @ochosi said:

Thanks for the final patch Olivier and the testing Olaf.

O H @olh said:

Started to happen again with git.xfce.org from this Friday.

Olivier Fourdan @olivier said:

Not surprising, we had to revert the change.

added 5. Multi-Monitor label

@olivier: tagging you in.

unassigned @ochosi

added 5. Login / Startup label

There has not been any activity or new feedback in quite some time, so I will close this report.

It can be reopened if the problem is still reproducible.

closed