Hi, I have recently updated XFCE to version 4.14 included in the FreeBSD ports collection. While it is working generally and everything worked fine for me in my testing users are reporting an issue with the window manager. With certain graphics hardware/driver combinations they report blank or black window decorations, without rounded borders or other eye candy. The original user messages describing the issue can be viewed here: https://lists.freebsd.org/pipermail/freebsd-xfce/2019-September/002434.html https://lists.freebsd.org/pipermail/freebsd-xfce/2019-September/002438.html I'm trying to gather more information about this. What is needed to try to address the issue? Thanks in advance!
First of all, try with the default xfwm4 theme with adwaita gtk theme. Does that issue affects only the window decorations or all the window content? Try disabling the compositor, does it make a difference? Possibly a driver issue, I am using a T440s here as well and everything works fine on Linux.
(In reply to Olivier Fourdan from comment #1) I'm not personally experiencing the issue, but working as a middleman. I'll point users to this bug report so they can reply with details they see. I'm only asking for details how to perform the checks you ask so they have detailed reference here. > First of all, try with the default xfwm4 theme with adwaita gtk theme. > > Does that issue affects only the window decorations or all the window > content? AFAIK only window decorations, but please wait for confirmation about this. I've asked if a screenshot of the issue can be taken. > > Try disabling the compositor, does it make a difference? is this the correct way to disable the compositor? $ xfconf-query -c xfwm4 -p /general/use_compositing -s false Do they need to restart XFCE after that for the chaange to take effect? > > Possibly a driver issue, I am using a T440s here as well and everything > works fine on Linux. Looks like it, but I was hoping a workaround can be found.
Hi, I am the guy with the problem, reported below (2nd post): http://freebsd.1045724.x6.nabble.com/Welcome-XFCE-4-14-td6350486.html Default xfwm4 theme with adwaita gtk theme suffers from same bahaviour. This afects only window decorations, not the content. Chromium window decoration is not affected. Disabling compositor (from "Compositor" tab of "Windows Manager Tweaks") does not improve the situation, instead it additionally adds black border around XFCE menu. Here's screenshot: https://oblak.mimar.rs/index.php/s/SmEXetTyYdmk9oT
OK, that really looks like a theme issue... Can you please post a screenshot with the xfwm4 default theme?
Here it is: https://oblak.mimar.rs/index.php/s/wtLgwASN8ypcXw8
Are you using the modesetting driver or the intel driver with Xorg?
Modesetting, this one: https://www.freshports.org/graphics/drm-fbsd12.0-kmod/
Hi, for reference, I can also see this behaviour on FreeBSD 12.0-RELEASE. My hardware is a Thinkpad T450, I'm using packages and the drm-next-kmod-4.11.g20181027_1 driver. My decorations look exactly the same as for Marko, affecting both Adwaita and Greybird. $ pciconf -lv vgapci0 vgapci0@pci0:0:2:0: class=0x030000 card=0x503417aa chip=0x16168086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'HD Graphics 5500' class = display subclass = VGA
For further reference I'm not seeing the issue on my laptop. Main difference I'm using FreeBSD head (13.0, development version, still unreleased), which uses a newer version of the modesetting driver: drm-current-kmod-4.16.g20190918 pciconf -lv vgapci0 vgapci0@pci0:0:2:0: class=0x030000 card=0x05061025 chip=0x01168086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = '2nd Generation Core Processor Family Integrated Graphics Controller' class = display subclass = VGA I also have an older machine with older display hardware.
*** Bug 15992 has been marked as a duplicate of this bug. ***
That really looks like a driver issue, especially if an upgrade of the drm driver on freebsd fixes it. Meanwhile can you try with the intel DDX (Xorg) instead?
(In reply to Olivier Fourdan from comment #11) > That really looks like a driver issue, especially if an upgrade of the drm > driver on freebsd fixes it. While that is a possibility, we are not sure of it. I have not experienced the issue and I also am on older hardware. Also updating the driver in FreeBSD 12.0 is not feasible. The intel drivers depend on kernel parts being ported, but rules dictate that kernel ABI cannot be broken on a stable release, so users of 12.x are limited to a specific driver version...except for some incremental updates. This just to put the issue into perspective. It's strange that the old 4.12.x version of xfwm did not cause this issue.
That's why I suggested trying the intel DDX instead. But I am not even sure we are talking of the same, you seem to be talking about a kernel driver whereas I am talking about Xorg drivers (modesetting or intel). Because that particular bug, I've seen it a few years ago with SNA acceleration on the intel DDX... So it's not as if my replies where completely random either... So best would be to post the actual Xorg logs from an affected system, so at least I know what DDX we're talking about here.
(In reply to Olivier Fourdan from comment #13) > That's why I suggested trying the intel DDX instead. > > But I am not even sure we are talking of the same, you seem to be talking > about a kernel driver whereas I am talking about Xorg drivers (modesetting > or intel). I'm not an expert about graphics drivers. In FreeBSD the situation is quite different from Linux, and using modesetting drivers requires specific kernel drivers. If I understand correctly the kernel driver provides a compatibility layer with linux modesetting, so that the same drivers from intel made for Linux can be used with FreeBSD. That's why I was mixing up things a little > > Because that particular bug, I've seen it a few years ago with SNA > acceleration on the intel DDX... So it's not as if my replies where > completely random either... Just to avoid confusion I did not think you were suggesting random things. > > So best would be to post the actual Xorg logs from an affected system, so at > least I know what DDX we're talking about here. I'm not experiencing the issue, so we will have to wait for someone else to test this. But I would actually don't know how to switch to a DDX driver right away on FreeBSD. Maybe users also need guidance. I'm going to look this up so I can help if needed.
(In reply to Guido Falsi from comment #14) > (In reply to Olivier Fourdan from comment #13) > > > > So best would be to post the actual Xorg logs from an affected system, so at > > least I know what DDX we're talking about here. > > I'm not experiencing the issue, so we will have to wait for someone else to > test this. > > But I would actually don't know how to switch to a DDX driver right away on > FreeBSD. Maybe users also need guidance. I'm going to look this up so I can > help if needed. I'd say this translates to using the old driver from x11-drivers/xf86-video-intel. But I don't know what kind of support that driver can have for newer hardware.
jet rotatif (In reply to Guido Falsi from comment #15) > > I'd say this translates to using the old driver from > x11-drivers/xf86-video-intel. yep > But I don't know what kind of support that driver can have for newer > hardware. The issue was reported on a t440 which is Haswell, not exactly new :) To be clear, the goal here is to pinpoint if this is a driver issue.
I noticed, on another FreeBSD 12.0 box, using legacy modesetting driver, and not yet updated to 4.14, behaviour which could matter here. This hardware is even older than Haswell: vgapci0@pci0:0:2:0: class=0x030000 card=0x1790103c chip=0x016a8086 rev=0x09 hdr=0x00 vendor = 'Intel Corporation' device = 'Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller' class = display subclass = VGA This is my office desktop. I mostly lock my xfce sesion in the afternoons, and unlock it in the mornings. In the morning, most (all?) of my windows have black bars in window decoration: https://oblak.mimar.rs/index.php/s/fKRL5946z6CYY7a Any interaction with the window (click decoration, click window button in menu, minimising/maximising) restores decoration to normal (see ws1). So, black window decorations are observed also on 4.12, but are not-persistent. On 4.14, they are persistent. Hope this helps.
Hoping to add some useful info to help tracking this annoying bug. The same is happening on iMac 10,1 (27"), running FreeBSD 12.0-RELEASE-p8 amd64 with this GPU: % pciconf -lv vgapci0 vgapci0@pci0:2:0:0: class=0x030000 card=0x00b6106b chip=0x94881002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'RV730/M96-XT [Mobility Radeon HD 4670]' class = display subclass = VGA The issue shows with both x11-drivers/xf86-video-ati-legacy and graphics/drm-kmod (x11-drivers/xf86-video-ati always produced blank screen at X11 load on this machine). I just noticed that Bug 16032 seems to report the same problem... I just tried to build xfwm4-4.13.0 on FreeBSD but I'm not so skilled to solve the following errors at build time... :( helper-dialog.c:44:27: error: use of undeclared identifier 'gdk_display' XSetTransientForHint (gdk_display, GDK_WINDOW_XID (dialog->window), xid); ^ helper-dialog.c:44:27: error: use of undeclared identifier 'gdk_display' XSetTransientForHint (gdk_display, GDK_WINDOW_XID (dialog->window), xid); ^
(In reply to Andrew from comment #18) > Hoping to add some useful info to help tracking this annoying bug. > > The same is happening on iMac 10,1 (27"), running FreeBSD 12.0-RELEASE-p8 > amd64 with this GPU: > > % pciconf -lv vgapci0 > vgapci0@pci0:2:0:0: class=0x030000 card=0x00b6106b chip=0x94881002 rev=0x00 > hdr=0x00 > vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' > device = 'RV730/M96-XT [Mobility Radeon HD 4670]' > class = display > subclass = VGA > > The issue shows with both x11-drivers/xf86-video-ati-legacy and > graphics/drm-kmod (x11-drivers/xf86-video-ati always produced blank screen > at X11 load on this machine). > > I just noticed that Bug 16032 seems to report the same problem... I just > tried to build xfwm4-4.13.0 on FreeBSD but I'm not so skilled to solve the > following errors at build time... :( How did you do that? The easiest way is to modify the existing port to compile an older version. You could also grab the experimental ports I have made while testing XFCE 4.13 in the last few months which you can find here: https://github.com/madpilot78/FreeBSD-xfce4.13 (look at the history for older version of the port and grab changes you need) > > helper-dialog.c:44:27: error: use of undeclared identifier 'gdk_display' > XSetTransientForHint (gdk_display, GDK_WINDOW_XID (dialog->window), xid); > ^ > helper-dialog.c:44:27: error: use of undeclared identifier 'gdk_display' > XSetTransientForHint (gdk_display, GDK_WINDOW_XID (dialog->window), xid); > ^ Strange error, but it looks like some include file was not properly processed. I suspect you've trying building yourself without using the port. Ports apply a lot of "magic" when building software, and it is quite possible that this same erro would not show when building through a port.
I have had a better look at bug 16032, I posted a followup there too. Looking at the range provided there the migration to cairo to draw borders looks like a possible point when the issue started appearing. What version of cairo is used with XFCE usually? FreeBSD has 1.16.0 at present in the ports tree. Also could the fact that the FreeBSD cairo port is by default built with the experimental OpenGL support turned on be an issue? Is there anyone experiencing the issue who is willing to test cairo with the OPENGL option turned off?
(In reply to Guido Falsi from comment #19) > > I just noticed that Bug 16032 seems to report the same problem... I just > > tried to build xfwm4-4.13.0 on FreeBSD but I'm not so skilled to solve the > > following errors at build time... :( > > How did you do that? The easiest way is to modify the existing port to > compile an older version. I simply downloaded the .tar at the revision suggested in bug 16032 (https://git.xfce.org/xfce/xfwm4/tag/?h=xfwm4-4.13.0), then I substituted its contents in the workdir of the latest version of x11-wm/xfce4-wm (at the stage "make extract"), solving several build errors until stopping at these ones I was unable to workaround... :( I tried this method in order not to have to downgrade all XFCE-related ports and rebuild them all on the workstation I'm using. > You could also grab the experimental ports I have made while testing XFCE > 4.13 in the last few months which you can find here: > > https://github.com/madpilot78/FreeBSD-xfce4.13 > > (look at the history for older version of the port and grab changes you need) I'll eventually try to do what you suggest in a VM, but I guess it would be better to do on a machine where the GUI problem happens.
(In reply to Guido Falsi from comment #20) > Also could the fact that the FreeBSD cairo port is by default built with the > experimental OpenGL support turned on be an issue? > > Is there anyone experiencing the issue who is willing to test cairo with the > OPENGL option turned off? I'm running cairo 1.16.0, and I just tried reinstalling it from ports without the OPENGL option. Nothing changed: after rebooting, windows titlebar still has the issue.
(In reply to Andrew from comment #22) > (In reply to Guido Falsi from comment #20) > > Also could the fact that the FreeBSD cairo port is by default built with the > > experimental OpenGL support turned on be an issue? > > > > Is there anyone experiencing the issue who is willing to test cairo with the > > OPENGL option turned off? > > I'm running cairo 1.16.0, and I just tried reinstalling it from ports > without the OPENGL option. Nothing changed: after rebooting, windows > titlebar still has the issue. Thanks for the test. It was worth a try. Just for good measure, could you also try giving the command "xfwm4 --replace" from a terminal window and see if anything changes?
Yep, I already tried to restart xfwm4 in place: it does not solve the glitch. Also changing/deactivating the compositor (I had compton installed) does not change anything.
(In reply to Andrew from comment #24) > Yep, I already tried to restart xfwm4 in place: it does not solve the glitch. > Also changing/deactivating the compositor (I had compton installed) does not > change anything. Thanks again. The problem here is isolate the issue and understand exactly where the problem is happening. There are many factors at play. I'll be trying to get some more ideas.
Maybe a good news: I just managed to get the point in time (at least, one point in time) during 4.13 development phase, when xfwm4 didn't show the issue! I wasn't able to make it work by using your experimental ports, Guido (https://github.com/madpilot78/FreeBSD-xfce4.13) but, following what I read in bug 16032, I create a package by using this snapshot: https://archive.xfce.org/src/xfce/xfwm4/4.13/xfwm4-4.13.0.tar.bz2 Then, I build a package from the next archive (https://archive.xfce.org/src/xfce/xfwm4/4.13/xfwm4-4.13.1.tar.bz2), which gave me the same GUI problem. This I can confirm that the cause has been introduces between these two development releases. Now can anyone suggest how can I help you narrow it down anymore? Here below are 24-hour links to download both packages, if they can be useful in someway: https://a.uguu.se/aiP4CO3t6GwK_xfce4-wm-4.13.0.txz https://a.uguu.se/iAgYQorEHqiy_xfce4-wm-4.13.1.txz
(In reply to Andrew from comment #26) > Maybe a good news: I just managed to get the point in time (at least, one > point in time) during 4.13 development phase, when xfwm4 didn't show the > issue! > > I wasn't able to make it work by using your experimental ports, Guido > (https://github.com/madpilot78/FreeBSD-xfce4.13) but, following what I read > in bug 16032, I create a package by using this snapshot: > https://archive.xfce.org/src/xfce/xfwm4/4.13/xfwm4-4.13.0.tar.bz2 > > Then, I build a package from the next archive > (https://archive.xfce.org/src/xfce/xfwm4/4.13/xfwm4-4.13.1.tar.bz2), which > gave me the same GUI problem. Thanks for your tests. This proves thee issue was introduced in between also on FreeBSD. This is definitely helpful > > This I can confirm that the cause has been introduces between these two > development releases. Now can anyone suggest how can I help you narrow it > down anymore? Without any further insight the usual solution is bisecting the code to narrow down the exact commit causing the issue. https://en.wikipedia.org/wiki/Bisection_(software_engineering) You should test the middle commit between the one now working and the one not working so to narrow down to half options the change causing the bug. Then repeat until you narrow it to a single commit. It's tedious work, but would give exact information where to look at to the developers. git also has specific commands to bisect code but I'm no git wizard and cannot provide detailed guidance.
(In reply to Guido Falsi from comment #27) > Without any further insight the usual solution is bisecting the code to > narrow down the exact commit causing the issue. > > https://en.wikipedia.org/wiki/Bisection_(software_engineering) > > You should test the middle commit between the one now working and the one > not working so to narrow down to half options the change causing the bug. > Then repeat until you narrow it to a single commit. It's ok for me to put some efforts on this (I need to get some rudiment about git, but I think I'll manage it). But I need your help only on a single point: how can I create what I found at this location [1] from the code I can grab here [2]? I just gave it a try: I grabbed the code with "git clone", then launched ./autogen.sh (after installing devel/xfce4-dev-tools), but the resulting folder does not contain a couple of dirs ("src" and "themes"), which I can find in the .tar.bz2 I can download here [1]. Thanks for your help. [1] https://archive.xfce.org/src/xfce/xfwm4 [2] https://git.xfce.org/xfce/xfwm4/
(In reply to Andrew from comment #28) > (In reply to Guido Falsi from comment #27) > > Without any further insight the usual solution is bisecting the code to > > narrow down the exact commit causing the issue. > > > > https://en.wikipedia.org/wiki/Bisection_(software_engineering) > > > > You should test the middle commit between the one now working and the one > > not working so to narrow down to half options the change causing the bug. > > Then repeat until you narrow it to a single commit. > > It's ok for me to put some efforts on this (I need to get some rudiment > about git, but I think I'll manage it). But I need your help only on a > single point: how can I create what I found at this location [1] from the > code I can grab here [2]? > > I just gave it a try: I grabbed the code with "git clone", then launched > ./autogen.sh (after installing devel/xfce4-dev-tools), but the resulting > folder does not contain a couple of dirs ("src" and "themes"), which I can > find in the .tar.bz2 I can download here [1]. > The src dir should be there actually. Not sure why it's not there. You can check the deskutils/xfce4-generic-slider port which uses the dev tools and copy what that is doing.
Created attachment 9155 Output of autogen.sh on FreeBSD 12.0 Sorry man, but I had some hard time understanding git (il)logic: since I'm not a developer and I always worked only with RCS, CVS, and SVN versioning tools. Now I'm "mastering" Git too (ahem), but I not yet able to build a specific commit in FreeBSD because, after I run "autogen.sh", the make command (and consequently the Port's "make build" command) fails with this error: make all-recursive Making all in defaults Making all in helper-dialog CC helper_dialog-helper-dialog.o CCLD helper-dialog Making all in icons Making all in 22x22 Making all in 48x48 Making all in scalable Making all in po Making all in settings-dialogs GEN monitor-icon.h GEN xfwm4-dialog_ui.h *** Error code 1 Stop. It looks like I'm still missing something here! :( I found this old thread [1] in Xfce mailing list, but it does not helped me to solve, since the "--enable-maintainer-mode" option seems to be enabled by default in autogen.sh I just attached the output I get by running "autogen.sh". Can someone help me understand what I'm missing? [1] https://mail.xfce.org/pipermail/xfce4-dev/2012-October/030052.html
I just tried: $ git clone https://git.xfce.org/xfce/xfwm4/ $ sudo cp -a xfwm4/ copy1xfwm4/ (saves me re cloning if things go wrong, git and autotools allow you to reset but sometimes bits get left over if things aren't set up for that) $ cd copy1xfwm4/ $ ./autogen.sh \ --prefix=/usr \ --libexecdir=/usr/lib \ --sysconfdir=/etc \ --localstatedir=/var \ --disable-dependency-tracking \ --disable-static \ --enable-epoxy \ --enable-startup-notification \ --enable-xsync \ --enable-render \ --enable-randr \ --enable-xpresent \ --enable-compositor \ --disable-debug (which I just copy pasted from the AUR PKGBUILD) $ make And it built successfully. So you can give arguments to .autogen.sh. But having run that, you have a "configure" executable script so you can also run ./configure --help to see options available and re-run configure. Then I tried ./autogen --help, and then ran ./autogen as before but adding --disable-maintainer-mode to the args, and it still built with no obvious difference in the output. Some of these are GNU autotool built in options and may not be connected to anything useful. But it's interesting to consider those autogen options too, which I had not seen. Generally if you get a git repo using GNU autotools (there are other build systems too) then there is no configure or MAKEFILE so you either run the included autogen.sh or similar to create them. But you can also run autoreconf (which is on your system if autotools are installed) then do ./configure and make which might be required for some builds. The source package releases have had the autogen / autoreconf bit done already when the GNU autotools make a "release" package. Before you build if you run: $ git checkout 89c29f54d2967a1a174db30de877faa1e02b62d5 that should work [2017-11-14 18:40:38 +0100 I18n: Update translation ko (100%).] and then in another clean copy of the original dir $ git checkout 574ea24bceddde438c1d30aae5abe0b1e314e82a should be not working [2017-07-07 06:03:48 +0300 menu: remove deprecations] which was the closest I could narrow it down as the commits between didn't compile for me, but perhaps you will be able to progress further. (git checkout will rewrite the code to the point of the specified commit.) So far as the error goes, you need to try and find the first error (there might be several) and show the output from there as there is always a final error just to say it didn't work
(In reply to stratus from comment #31) > I just tried: > $ ./autogen.sh \ > --prefix=/usr \ > --libexecdir=/usr/lib \ > --sysconfdir=/etc \ > --localstatedir=/var \ > --disable-dependency-tracking \ > --disable-static \ > --enable-epoxy \ > --enable-startup-notification \ > --enable-xsync \ > --enable-render \ > --enable-randr \ > --enable-xpresent \ > --enable-compositor \ > --disable-debug > (which I just copy pasted from the AUR PKGBUILD) > $ make > And it built successfully. Thank you so much. I tried again by using several sets of options, starting from what I found in FreeBSD port's Makefile [1], but it does not build yet, stopping with a slightly different output: make all-recursive Making all in defaults Making all in helper-dialog CC helper_dialog-helper-dialog.o CCLD helper-dialog Making all in icons Making all in 22x22 Making all in 48x48 Making all in scalable Making all in po Making all in common CC libxfwm_common_la-xfwm-common.lo CCLD libxfwm-common.la Making all in settings-dialogs GEN xfwm4-dialog_ui.h *** Error code 1 Stop. It seems unable to build something under ./settings-dialogs, but I have no idea about what is missing yet. I'd really wish to know how archives published at https://archive.xfce.org/src/xfce/xfwm4/ are generated, since I have no problem to build xfwm4 from them on FreeBSD! :( [1] https://svnweb.freebsd.org/ports/head/x11-wm/xfce4-wm/Makefile?view=markup#l25
autogen.sh runs xdt-autogen, part of xfce4-dev-tools which may need to be a compatible version with the version of xfwm4 you are building. There doesn't seem to be a make dist target defined to create a compressed release package but usually that would only do something like run autogen, delete .git and possibly other unrequired things, and tar up the rest.
(In reply to stratus from comment #33) > autogen.sh runs xdt-autogen, part of xfce4-dev-tools which may need to be a > compatible version with the version of xfwm4 you are building. Thank you again very much. I switched back the xfce4-dev-tools package from 4.14.0 to 4.13.0, then I tried with version 4.12.0 too, but the build process always stopped exactly at the same point... :( So I'm very sorry, but at this point I guess I won't actually be able to even start seeking for the commit which caused the bug! :(
When you git clone it will be at head ie 4.14, so if you haven't done so already you would need to checkout the right commit before you do anything. I have current versions installed again now, so I can build with no git commands first, which would not be the case if I had the older packages. Also not all commits build. I tried 4 or 5 points in the suspect section and none built, it looked like the build was broken as that was when it was changed from GTK2 to GTK3, so I assumed the change was made in several commits added over a few days, so from Prepare to GTK3 up to Fix remaining deprecations it's probably non buildable anyway unless you modified stuff, which is why I could not narrow it down any more with that approach, and I'm now trying some other debugging and logging methods instead. Anyway, It could be something that was not changed and should have been, rather than something that was. I don't know, I'm only another XFCE user. Thank's for your help so far, you already identified the affected versions in BSD.
This could probably be caused by the Cairo addition, after I did some bisecting in frame.c which seemed like a candidate. Using a Radeon VII/Vega20 with the 12.1-RELEASE KMS DRM v5.0 driver on Github, if that helps.
Hi, I wanted to inform that on the FreeBSD bugzilla bug tracking this same issue, it has been reported that the recent upgrade to Xorg server 1.20.7 fixes this issue. [1] The newer Xorg server is available in the FreeBSD ports tree and in the "latest" binary package set. It will hit the quarterly package set at the start of April. If everything works fine I propose to mark this issue as resolved after the start of April once the new Xorg server version is generally available to FreeBSD users with default configuration. [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240887#c11
*** Bug 16577 has been marked as a duplicate of this bug. ***
Hi, Various people have reported the issue going away with Xorg-server 1.20.7, which is now generally available to all FreeBSD users via binary packages. So I'm closing this since it is not an issue anymore for FreeBSD users. For further reference please check here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240887 Thanks for the support and help provided!