Refresh patch, so it applies cleanly.

In D21278#470180, @sbruno wrote:

Is the raw patch updated so I can test it?

Update patch to apply to latest tree.

Fix USES.

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

Regarding this review, do I have permission to commit to the doc tree?

Exp run requested here:

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

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

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

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.

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#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#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

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

Fix xfce4-settings plist.

Update patch. Changes:

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

I submitted (in madpilot's repository) a new pull request, against x11-wm/xfce4-panel. Because when we change icons theme, the applications menu is not automatically reloaded.

In D21278#464648, @sbruno wrote:

Huh ... Settings->Keyboard->Typing Settings->Repeat Speed was reset to "1". I've bumped it locally back to 50 so I don't throw my keyboard across the room. :-)

In D21278#464643, @sbruno wrote:

Ugh, no. It does repeat but its on a 3 second or so output delay.

In D21278#464161, @sbruno wrote:

I've applied and compiled all this and it seems to do the right thing. A few icons on my tool bars lost their icons, but that was easily fixed.

I'm not the biggest fan of the color scheme changes in the default, but that's my "opinion". :-)

Remove some files directories containing old patches.

Add forgotten gtk2 argument to USES=xfce in xfce4-bsdcpufreq-plugin.

In D21278#463004, @kevans wrote:

In D21278#463000, @sbruno wrote:

In D21278#462738, @madpilot wrote:

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?

Strange, I generated it using arc from command line.

You can grab a ports overlay here:

https://github.com/madpilot78/FreeBSD-xfce4.13

it's the same as the patch.

I also uploaded the result of svn diff here:

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

Can you regenerate the svn diff with "--show-copies-as-adds"? The xfce4-places-plugin directory is very confused in the diff. It shows that it was copied from somewhere, but its not clear where it was copied from.

In D21278#462737, @sbruno wrote:

Hrm ... phabricator and patch really don't like to apply this to my local tree. It chokes on adding new stuff and I can't seem to work around it. Any suggestions?