I've been running this with no defects for quite some time.

Refresh patch, so it applies cleanly.

In D21278#470180, @sbruno wrote:

Is the raw patch updated so I can test it?

Is the raw patch updated so I can test it?

Update patch to apply to latest tree.

Really remove old patch integrated upstream in sysutils/xfce4-wavelan-plugin.

Update patch to remove the xfce4-vala port.

Update patch.

Update diff after recent tree changes (no functional change).

Exp run requested here:

In D21278#466627, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

Previous stable release of what? Have you changed your X11 setup? Are you using an xorg.conf file or letting it autodetect everything? Is hardware acceleration working with other software?

[1] http://pix.toile-libre.org/upload/original/1566927773.png

In D21278#466622, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I made some tests (on 12.0-STABLE):

Libepoxy and XPresent are required for support of vblank (Vertical blanking interval). Currently only GL backend (via libepoxy) is used. I get these warnings (.xession-errors)

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.750: Unsupported GL renderer (llvmpipe (LLVM 8.0, 128 bits)).

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.751: Screen is missing required GL renderer, GL support disabled.

This property (vblank) is by default on 'auto' xfconf-query -c xfwm4 -p /general/vblank_mode

Have you tested setting that to off?

According to compositor documentation, we can disable this property. If I use the kernel mode-setting port, borders are not well formed [1] (same result when vblank_mode is on 'auto'), but with Xorg drivers everything is fine (not checked warnings in .xsession-errors).

Then I tried with libXpresent (no update since 2015, but still uses by linux distributions), 2 backends are enabled, in my .xsession-errors messages related to xfwm4 disappeared. Render of borders (when I use the drm-kmod port) is always identical even if Xpresent is installed or not.

Presence of libXpresent avoids warnings for xfwm4. I can provide this port (and diff for x11-wm/xfce4-wm) if someone is interested.

If I understand the docs I read, the mere presence of libXpresent could not be enough. The window manager by default tries to autodetect what to use and could not even try using libXpresent by itself.

To be sure to test libXpresent you should run:

xfwm4 --vblank=xpresent --replace

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

[1] http://pix.toile-libre.org/upload/original/1566927773.png

I have no idea what is causing this at this point.

Now first a personal note. My poudriere machine died just today. I was testing a libXpresent port. I could not fully test it but here is the XFCE 4.14 diff including this port and adding it as a dependency for xfwm:

https://people.freebsd.org/~madpilot/xfce414-libXpresent.diff

I know this may sound obvious, but just to make sure, have you tried changing window manager theme?

In D21278#466622, @madpilot wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I made some tests (on 12.0-STABLE):

Libepoxy and XPresent are required for support of vblank (Vertical blanking interval). Currently only GL backend (via libepoxy) is used. I get these warnings (.xession-errors)

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.750: Unsupported GL renderer (llvmpipe (LLVM 8.0, 128 bits)).

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.751: Screen is missing required GL renderer, GL support disabled.

This property (vblank) is by default on 'auto' xfconf-query -c xfwm4 -p /general/vblank_mode

Have you tested setting that to off?

According to compositor documentation, we can disable this property. If I use the kernel mode-setting port, borders are not well formed [1] (same result when vblank_mode is on 'auto'), but with Xorg drivers everything is fine (not checked warnings in .xsession-errors).

Then I tried with libXpresent (no update since 2015, but still uses by linux distributions), 2 backends are enabled, in my .xsession-errors messages related to xfwm4 disappeared. Render of borders (when I use the drm-kmod port) is always identical even if Xpresent is installed or not.

Presence of libXpresent avoids warnings for xfwm4. I can provide this port (and diff for x11-wm/xfce4-wm) if someone is interested.

If I understand the docs I read, the mere presence of libXpresent could not be enough. The window manager by default tries to autodetect what to use and could not even try using libXpresent by itself.

To be sure to test libXpresent you should run:

xfwm4 --vblank=xpresent --replace

I also noticed (on my laptop) compositor is not functional (it was functional with the previous stable release).

[1] http://pix.toile-libre.org/upload/original/1566927773.png

I have no idea what is causing this at this point.

Now first a personal note. My poudriere machine died just today. I was testing a libXpresent port. I could not fully test it but here is the XFCE 4.14 diff including this port and adding it as a dependency for xfwm:

https://people.freebsd.org/~madpilot/xfce414-libXpresent.diff

I'm posting this patch just in case someone could test it.

I will need a little time to fix or rebuild the failed machine before I can do much work on ports.

Apart from this we need some plan to get ahead on this. I'm personally out of ideas and unable to test it since it does not show on my hardware.

I'd like to understand if this is an xfce problem, an x11 problem or a driver problem. I'm asking someone with hardware showing the problem to run another compositing window manager, to check what happens.

I also need to decide if I should push to commit this update anyway, or wait for a solution. Keeping XFCE not updated indefinitely does not look like a good thing to me. Also because now I have problems updating the old ports. I'd need to build a brand new testing environment. I was hoping to update everything at once with this big update.

Does someone has a suggestion on how to address or manage this issue? Is it really a showstopper?

In D21278#466552, @duchateau.olivier_gmail.com wrote:

In D21278#466552, @duchateau.olivier_gmail.com wrote:

I made some tests (on 12.0-STABLE):

Libepoxy and XPresent are required for support of vblank (Vertical blanking interval). Currently only GL backend (via libepoxy) is used. I get these warnings (.xession-errors)

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.750: Unsupported GL renderer (llvmpipe (LLVM 8.0, 128 bits)).

(xfwm4:1092): xfwm4-WARNING **: 16:28:42.751: Screen is missing required GL renderer, GL support disabled.

This property (vblank) is by default on 'auto' xfconf-query -c xfwm4 -p /general/vblank_mode

I made some tests (on 12.0-STABLE):

In D21278#466240, @madpilot wrote:

In D21278#466236, @madpilot wrote:

In D21278#466231, @ltning-freebsd_anduin.net wrote:

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

This is an hard issue to fix. I really don't have a solution right away. And I can't if it's a specific xfwm problem, a driver problem, a compositing problem. I'd like someone experiencing this to try another compositing window manager, so we can understand if it's specific to xfwm or a general compositing problem. I'm at odds with this. Keeping xfce at 4.12 isn't acceptable though.

In general newer hardware (especially laptop hardware) s more problematic.

Could you post a screenshot of the problem? So I get a better idea what we're against?

I'm not sure if disabling compositing from the config (or command line) actually disables the usage of hardware acceleration and is able to mitigate the problem, looks like it's not enough. It was worth a try.

Also, I'm on head, which has newer in kernel drivers. Which FreeBSD version are you using?

I'm using 12-STABLE.

This could also be a relevant difference. The drivers on 13 are newer and could not have this problem.

There are too many factors, and we need to exclude at least some. If I was experiencing the bug I'd try myself, but I cant reproduce it.

I found this further guidance. trying the "off" option described here could be worth it:

https://forum.xfce.org/viewtopic.php?id=13233

In D21278#466236, @madpilot wrote:

In D21278#466231, @ltning-freebsd_anduin.net wrote:

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

This is an hard issue to fix. I really don't have a solution right away. And I can't if it's a specific xfwm problem, a driver problem, a compositing problem. I'd like someone experiencing this to try another compositing window manager, so we can understand if it's specific to xfwm or a general compositing problem. I'm at odds with this. Keeping xfce at 4.12 isn't acceptable though.

In general newer hardware (especially laptop hardware) s more problematic.

Could you post a screenshot of the problem? So I get a better idea what we're against?

I'm not sure if disabling compositing from the config (or command line) actually disables the usage of hardware acceleration and is able to mitigate the problem, looks like it's not enough. It was worth a try.

Also, I'm on head, which has newer in kernel drivers. Which FreeBSD version are you using?

I'm using 12-STABLE.

This could also be a relevant difference. The drivers on 13 are newer and could not have this problem.

There are too many factors, and we need to exclude at least some. If I was experiencing the bug I'd try myself, but I cant reproduce it.

• Add USES=xorg
• Import upstream patch to fix regression in worspace switcher panel plugin [1]
• Updated xfce4-screenshooter-plugin
• Changed defaults to an "unthemed" xfce, more similar to what old ports did

In D21278#466231, @ltning-freebsd_anduin.net wrote:

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

I have disabled compositing, it doesn't make a difference at all. Used the "Window manager tweaks" panel to do so.

In D21278#466181, @madpilot wrote:

In D21278#466163, @duchateau.olivier_gmail.com wrote:

Can you specify exactly which driver is creating problems?

It is AMD Radeon R2.

vgapci0@pci0:0:1:0:     class=0x030000 card=0x108a1025 chip=0x98531002 rev=0x40 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Mullins [Radeon R2 Graphics]'
    class      = display
    subclass   = VGA

Xorg loads the Vesa driver (amdgpu is also installed, but not loaded).

If I follow this documentation, I have same problem as Eirik.

So it depends on the hardware.

I'm almost sure it has to do with the compositing functionality. shadows, transparencies and the like. I'm sorry I have no idea how to "fix" this.

Could you try using some other compositing window manager and check if the problem appears with them too? (compiz for example)

Another thing to try iis disabling the compositing functionality in xfwm. I found this:

https://www.reddit.com/r/GlobalOffensiveLinux/comments/6b3cs5/is_it_possible_to_disable_compositing_in_xfce_for/

Could you try this and see if the problem goes away?

In D21278#466163, @duchateau.olivier_gmail.com wrote:

Can you specify exactly which driver is creating problems?

It is AMD Radeon R2.

vgapci0@pci0:0:1:0:     class=0x030000 card=0x108a1025 chip=0x98531002 rev=0x40 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Mullins [Radeon R2 Graphics]'
    class      = display
    subclass   = VGA

Xorg loads the Vesa driver (amdgpu is also installed, but not loaded).

If I follow this documentation, I have same problem as Eirik.

In D21278#466058, @madpilot wrote:

In D21278#466034, @duchateau.olivier_gmail.com wrote:

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

I have same issue with the latest stable release 4.14 (and before, with 4.13.x development releases). I use X11 drivers and everything works fine.

I think problem comes from xfwm4, by default we use the GL backend (libepoxy), because XPresent was removed in our ports tree (merged into x11 library). Sometimes if fails (xfwm4 is rather complex). Some linux distribution still provide this library that's why there are 2 backends.

I don't have more recent hardware to test with.

Can you specify exactly which driver is creating problems?

In D21278#466034, @duchateau.olivier_gmail.com wrote:

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

I have same issue with the latest stable release 4.14 (and before, with 4.13.x development releases). I use X11 drivers and everything works fine.

I think problem comes from xfwm4, by default we use the GL backend (libepoxy), because XPresent was removed in our ports tree (merged into x11 library). Sometimes if fails (xfwm4 is rather complex). Some linux distribution still provide this library that's why there are 2 backends.

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

In D21278#465974, @ltning-freebsd_anduin.net wrote:

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I haven't had a chance to test with the previous xfce version yet, sorry.

And yes, I prefer modesetting - it's much faster than Intel, especially with compositing turned on. :) Also, the intel driver cannot resume from suspend after more than ~30 minutes.

ThinkPad X1, 6th gen, last years model - so pretty recent.

Has the new xfwm4 been tested with the modesetting X driver? When I do, all window decorations are black. That is - buttons and title shows up, also the corner pieces of windows, but the rest is just black. Switching to intel driver does not show this problem. Other window managers (windowmaker tested so far) do not seem to exhibit any such issues.

I'm planning a few more changes.

Fix build of xfce4-conf when PERL option is enabled.

I discovered now a regression in the workspace switcher. It looks like an upstream bug.

Documention of GObject Introspection is available here.

In D21278#465841, @duchateau.olivier_gmail.com wrote:

In D21278#465839, @ltning-freebsd_anduin.net wrote:

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

I'm very sorry - managed to pick the wrong address from all the open tabs. Here is the log in question:
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-24_21h36m29s/logs/errors/xfce4-conf-4.14.1.log

I'm builng ibus because it's pulled in by gnome3(-lite), so that's unrelated to xfce. It did give me a nasty dependency loop though, but that's unrelated.

In D21278#465839, @ltning-freebsd_anduin.net wrote:

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

I'm very sorry - managed to pick the wrong address from all the open tabs. Here is the log in question:
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-24_21h36m29s/logs/errors/xfce4-conf-4.14.1.log

I'm building ibus because it's pulled in by gnome3(-lite), so that's unrelated to xfce. It did give me a nasty dependency loop though, but that's unrelated.

Your problem comes from PERL option. You should disable this option. Perl bindings has not been tested by upstream since the 4.13.0 release (port to gdbus).

In the past there was soname change, but upstream decided to keep this field untouched for backwards-compatibility. Personally I wish this option to be removed.

In D21278#465839, @ltning-freebsd_anduin.net wrote:

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

I'm very sorry - managed to pick the wrong address from all the open tabs. Here is the log in question:
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-24_21h36m29s/logs/errors/xfce4-conf-4.14.1.log

I'm builng ibus because it's pulled in by gnome3(-lite), so that's unrelated to xfce. It did give me a nasty dependency loop though, but that's unrelated.

In D21278#465837, @duchateau.olivier_gmail.com wrote:

Your log is related to ibus, not xfce4-conf. Xfconf does not depend of dbus-glib anymore, only of gdbus through gio.

In D21278#465836, @ltning-freebsd_anduin.net wrote:

In D21278#465772, @madpilot wrote:

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

[...]

Could you provide a full build log for the failure so this can be investigated?

Can you access this?
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-25_09h03m05s/logs/errors/ibus-1.5.20.log

In D21278#465836, @ltning-freebsd_anduin.net wrote:

In D21278#465772, @madpilot wrote:

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

This isn't failing for me in poudriere. It builds fine(I've been testing all the xfce ports with poudriere with various FreeBSD versions and OPTIONS combinations for some time) and the resulting binaries are not linked with libdbus, which is the reason why I removed the dependency.

Also xfce components have been migrated away from dbus-glib to gdbus, which, if I'm correct, is included in glib, so the new versions don't need that library.

Could you provide a full build log for the failure so this can be investigated?

Can you access this?
https://pkg.osl3.modirum.com/data/120amd64-default-wmaker/2019-08-25_09h03m05s/logs/errors/ibus-1.5.20.log

In D21278#465772, @madpilot wrote:

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

This isn't failing for me in poudriere. It builds fine(I've been testing all the xfce ports with poudriere with various FreeBSD versions and OPTIONS combinations for some time) and the resulting binaries are not linked with libdbus, which is the reason why I removed the dependency.

Also xfce components have been migrated away from dbus-glib to gdbus, which, if I'm correct, is included in glib, so the new versions don't need that library.

Could you provide a full build log for the failure so this can be investigated?

In D21278#465745, @ltning-freebsd_anduin.net wrote:

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

The following needs adding back before it will build (using poudriere):
LIB_DEPENDS= libdbus-1.so:devel/dbus \

libdbus-glib-1.so:devel/dbus-glib

x11/xfce4-conf fails to build because it need dbus, but this has been removed from the Makefile.

Remove debugging option from default CONFIGURE_ARGS in xfce4-settings.

In D21278#464977, @duchateau.olivier_gmail.com wrote:

I wonder, why debug option is set in sysutils/xfce4-settings (I did not see history).