Update XFCE to 4.14

[madpilot]

Summary

Some points which may require clarification:

• Since XFCE moved to GTK3 as default toolkit, I changes the default USES keyword.
• The previous change is reflected in many ports. I bumped PORTREVISION on such ports if there was no new version, to be on the safe side.
• Upstream added back the places plugin, so I removed the old MOVED line and reintegrated the port (maintaining history)
• I take advantage of the update for some housekeeping. Sorting things and solving porltint warnings. I also removed some unneeded dependencies and clened up unneeded use of USE_GNOME=intlhack
• I added some PORTSCOUT lines to avoid getting notices to the mailing list for future 4.15 development releases.
• I'm deprecating two ports which are not needed annymore, due tu superceded functionality (xfce4-vala and thunar-vfs). The xfce4-vala port now conflicts with it's own dependency, since its functionality has been moved there.
• Some patches from upstream bug reports have been imported
• Patches to xfce4-settings and xfce4-wm set the default themes to new ones installed by defualt by the meta port to be nearer what xfce developers use and consider default. A pkg-message has been added to the xfce4-settings port describing the change.
• Regarding the meta ports, I've removed slim as the default display manager and replaced it with lightdm. I've also added xfce4-screensaver as the default screensaver tool.

I'd also like to thank Olivier Duchateau for his help with this update.

Test Plan

I have performed multiple builds with multiple OPTIONS combinations of all the affected ports and their dependencies. I'm also running binaries obtained by this patch set on my desktop with success.

I also tested installing from scratch and checking I get a functional desktop and upgrading from 4.12 in a VM.

If required I can ask for an exp run.

[sbruno]

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

[sbruno]

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

[madpilot]

In D21278#464643, @sbruno wrote:

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

Maybe some "assistive technology" function got enabled. You should check in Settings/Accessibility.

From your description it looks like it's "Slow keys".

If I understand correctly if the master knob for the "assistive technologies" is enabled these functionality can enable itself depending on what you do. I usually keep it all disabled since I don't need it. I think having the default to on is to help people who actually need these things.

[madpilot]

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

Oh, strange. The default here appears to be more reasonable.

[madpilot]

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.

I'll fix it tomorrow, and also have a better look at your suggestions on github.

[madpilot]

Update patch. Changes:

• Update xfce4-settings to 4.14.1
• Imported upstream patch to allow panel to notice theme changes without reboot [1]
• Fix catfix patches to respect python indentition [1]
• Fix USES=xfce:gtk2 [1]

[1] submitted by: Olivier Duchateau

[madpilot]

Fix xfce4-settings plist.

[duchateau.olivier_gmail.com]

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

[madpilot]

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

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

Good catch.

It was actually added in r380565 (which was authored by you, if I'm correct).

I'll remove that from the default test and update the review.

[madpilot]

Remove debugging option from default CONFIGURE_ARGS in xfce4-settings.

Added a conditional putting it back in when WITH_DEBUG is defined.

[ltning-freebsd_anduin.net]

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

[madpilot]

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?

[ltning-freebsd_anduin.net]

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

[duchateau.olivier_gmail.com]

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

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

[madpilot]

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

As stated by Olivier this if the log file for the port textproc/ibus, which is untouched by this patch. It looks like an unrelated issue.

[ltning-freebsd_anduin.net]

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.

[duchateau.olivier_gmail.com]

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.

[madpilot]

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.

Thanks for the explanation.

Now the problem has many angles. In the patches I removed the PERL option from the defaults, but unluckily users who already compiled this port with old defaults will still see it selected in the requester and without indications will not disable it, even if they are not actually using the functionality.

Now, if the option brakes the build this is a big problem. The option could be saved by adding a conditional dependency on dbus when the option is turned on. This is simple to do and I'd do this as a first solution. I would also add a "(deprecated)" text to the option.

As for removing the option, I'd like to know more about the alternative. As I understand it the GIR option provides that, but I know very little about GObject Introspection, is there some documentation about this somewhere?

[duchateau.olivier_gmail.com]

Documention of GObject Introspection is available here.

Personally I mainly use it with Python (sometimes with Vala). With Perl there is equivalent in ports tree, which calls devel/p5-Glib-Object-Introspection. So we can inform users PERL option is deprecated, and they should use this port.

I don't know, why ltning-freebsd_anduin.net needs this option. He can access methods (and signals) of org.xfce.Xfconf service.

Below command which displays methods (and signals) of this service:

gdbus introspect --session --dest org.xfce.Xfconf --object-path /org/xfce/Xfonf

• SetProperty
• GetProperty
• GetAllProperties
• PropertyExists
• ResetProperty
• ListChannels
• IsPropertyLocked

To use these methods with Perl (with p5-Glib-Object-Introspection port) we need to "call" the Gio typelib file (files available in /usr/local/lib/girepository-1.0/ directory). With these methods we can only access of properties of given channel (as xfconf-query).

Now there is GObject Introspection support in Xfconf, so instead to use Gio typelib, we can directly use the Xfconf typelib. According to documentation of Perl module calls to the Xfconf is simple:

use Glib::Object::Introspection;
Glib::Object::Introspection->setup(
  basename => 'Xfconf',
  version => '0,
  package => 'Xfconf');

For example to create new channel, we must use the Xfconf::Channel class.

[madpilot]

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

I filed a new bug report in their bugzilla:

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

posting it here for reference, and Olivier could be interested too.

[madpilot]

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

Also add a (deprecated) warning to the option.

[madpilot]

I'm planning a few more changes.

I want to add USES=xorg (required by r509895), integrate some upstream patches and updates, and a few other minor things I noticed.

I'm also testing installing xfce unthemed by default, as to reduce difference in behaviour with what we have in the tree at present.

New patch will followup soon.

[ltning-freebsd_anduin.net]

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.

[madpilot]

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 using these patches on my two machines. One is a desktop PC with nvidia card. The other is an oldish laptop with an i3 using the integrated graphics card with intel driver.

The kernel driver I'm using there is i915kms.ko, which should be the modesetting one.

Everything works fine there.

XFCE uses a compositing window manager, while windowmaker (AFAIK) does not. This could explain the difference.

Maybe disabling shadows and other effect could fix the problem you are seeing on your hardware.

[duchateau.olivier_gmail.com]

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.

[madpilot]

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?

[duchateau.olivier_gmail.com]

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?

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.

Note: it is dual boot, on linux amdgpu driver is functional.

[madpilot]

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?

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

Note: it is dual boot, on linux amdgpu driver is functional.

I'm not an expert about graphics drivers. I imagine linux has better in kernel drivers, since hardware providers directly develop them there while we have to port them.

[ltning-freebsd_anduin.net]

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?

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

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

I'm using 12-STABLE.

[madpilot]

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.

[madpilot]

• 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

[1] https://bugzilla.xfce.org/show_bug.cgi?id=15886

[madpilot]

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

As Olivier pointed out the xpresent method is not available in FreeBSD, and is specified as the one working best with AMD hardware. You can try the other option, just in case it works better.

Olivier: I don't know the details about this library, but, if it was made merged in x11, the functionality is there, unless the API was radically changed, maybe there is a way to enable it again? I'll take a look tomorrow, but maybe you know already.

[madpilot]

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

Also disabling compositor from xfwm4 command line could be a useful experiment:

xfwm4 --replace --compositor=off

[duchateau.olivier_gmail.com]

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

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.

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

[madpilot]

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?

[madpilot]

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

[ltning-freebsd_anduin.net]

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?

Summary of my attempts so far:

• xfwm4 --replace --compositor=on --vblank=off
• xfwm4 --replace --compositor=off --vblank=off
• xfwm4 --replace --compositor=on --vblank=glx
• xfwm4 --replace --compositor=off --vblank=glx

None of them make any difference. Attached screenshot (crude, I know).

[madpilot]

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

[duchateau.olivier_gmail.com]

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

For x11-wm/xfce-wm, xorgproto is also required (configure script checks the presentproto.pc pkgconfig file).

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?

[duchateau.olivier_gmail.com]

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

Previous stable release, I mean 4.12.

About compositor, in fact it works fine, I can see shadows (they disappear, when I disable compositor). It is just Alt + mouse wheel scroll (zoom effecr) which is not functional. I think it is hardware problem (this behaviour is fonctional on my linux box), and I'll wait before to use kernel mode setting.

With support of libXpresent, I have no "artifacts" at beginning of session. For me, you can ask for exp-run to portmgr@

[madpilot]

Exp run requested here:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240236

[madpilot]

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

[madpilot]

Update patch.

Fix errors discovered by exp-run.

Also mark xfce4-vala as BROKEN since it now conflicts with it's own dependency.

[madpilot]

Update patch to remove the xfce4-vala port.

It's deprecated and unsupported upstream. The functionality is
available in the xfce library ports compiled with the VAPI option
(the default)

Also fix IMPLIES helper to the correct option name in two ports.

[madpilot]

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

[madpilot]

Update patch to apply to latest tree.

[sbruno]

Is the raw patch updated so I can test it?

[madpilot]

In D21278#470180, @sbruno wrote:

Is the raw patch updated so I can test it?

Yes it is.

[madpilot]

Refresh patch, so it applies cleanly.

[sbruno]

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