When I start Xfwm4 with Present compositing: XFWM4_USE_PRESENT=1 xfwm4 --replace the screen is frozen at the moment Xfwm4 takes control. I can move the mouse pointer and it changes shape when it is supposedly over objects like text areas, but the picture itself is no more updated. Stopping Xfwm4 resumes screen updates. There are no errors or warnings from Xfwm4, in Xorg log or dmesg. This is xfwm4 version 4.12.0git.0586f95c (revision 0586f95c) for Xfce 4.12 Released under the terms of the GNU General Public License. Compiled against GTK+-2.24.31, using GTK+-2.24.31. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Xpresent support: Yes - Embedded compositor: Yes - Epoxy support: Yes - KDE systray proxy (deprecated): No Kernel version is Linux 4.9.0, X.org version is 1.18.4 and xf86-video-intel is a recent build from Git master (2.99.917+746+g169c74f). The hardware is 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) Present support appears to be enabled in the driver: [ 4393.261] (II) intel(0): direct rendering: DRI2 DRI3 enabled [ 4393.261] (II) intel(0): hardware support for Present enabled
Can you try without DRI3 ?
Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=84252
Just tried on Fedora 25 on intel hardware with the modesettings driver (not intel driver), works fine.
(In reply to Olivier Fourdan from comment #3) > Just tried on Fedora 25 on intel hardware with the modesettings driver (not > intel driver), works fine. Works with intel driver as well.
Created attachment 6943 xtrace log Thanks a lot for testing this. I tried xf86-video-intel without DRI3; the modesetting driver; and X.org 1.19.0. The result is the same in all cases. Today I also tested this on another computer running the same OS with the xf86-video-ati driver and ATI Radeon HD 3600 XT. I verified that Xorg.log contained [ 785.384] (II) RADEON(0): Present extension enabled [ 785.384] (**) RADEON(0): DRI3 enabled and still the result was the same. I suppose this may be a configuration or a library dependency problem. The OS is x86-64 Arch Linux. Here are a few more component versions that may be related: libepoxy 1.3.1 gtk2 2.24.31 gdk-pixbuf2 2.36.2 glib2 2.50.2 libxpresent 1.0.0 libx11 1.6.4 xorg-server 1.19.0 xf86-video-intel 2.99.917+746+g169c74f linux 4.9 gcc 6.2.1 Xfwm4 is configured with ./configure \ --enable-maintainer-mode \ --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/lib \ --localstatedir=/var \ --disable-static \ --enable-startup-notification \ --enable-randr \ --enable-compositor \ --enable-xsync \ --disable-debug and in the presence of libxpresent. libxpresent is configured with just ./configure --prefix=/usr. Running xfwm4 with gdb shows that it is sleeping in main() -> gtk_main() -> g_main_loop_run() — this looks like normal execution. The linked bug mentions the xtrace tool. I used it to capture communication from xfwm4, see the attached log file. The log file approximately corresponds to these actions: - Run "XFWM4_USE_PRESENT=1 xfwm4 --replace" in a text console - Switch VT to where the X server is running - Verify that picture is not updated - Switch back to the text VT - Press Ctrl+C What other information can I provide?
Best would be to capture a backtrace of xfwm4 while it's not updating the screen, I suspect it's waiting for a PresentCompleteNotify event which is not coming.
Created attachment 6944 Debug output This is a full backtrace (after pressing Ctrl+C in gdb): Program received signal SIGINT, Interrupt. 0x00007ffff414a470 in __poll_nocancel () from /usr/lib/libc.so.6 (gdb) bt #0 0x00007ffff414a470 in __poll_nocancel () at /usr/lib/libc.so.6 #1 0x00007ffff52cd786 in () at /usr/lib/libglib-2.0.so.0 #2 0x00007ffff52cdb12 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #3 0x00007ffff678e3a7 in gtk_main () at /usr/lib/libgtk-x11-2.0.so.0 #4 0x00000000004437e6 in main (argc=1, argv=0x7fffffffe128) at main.c:686 The attached file contains debug output when compiled with --enable-debug=full. In particular, I can indeed see that the last Present-related message is DBG[compositor.c:2222] paint_all(): present flip requested, present pending...
Yeah, xfwm4 is waiting for the present flip notification, but never gets it. Dunno what to say, it works just fine here, maybe it's a driver issue on your side? Have you tried with the modesettings driver?
Well, as you can see above, I tried the modesetting driver and also another computer with a Radeon card and the same OS. Looking at the attached xtrace log, I see that it contains these lines: 000:<:199c: 72: Present-Request(148,1): UNKNOWN opcode=0x94 opcode2=0x01 unparsed-data=0x8a,0x01,0x00,0x00,0x5d,0x02,0x60,0x04,0x00,0x00,0x00,0x00,0x02,0x06,0x60,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x06,0x60,0x04,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0xd0,0x05,0x60,0x04,0x2a,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00; . . . 000:>:199c:Error 3=Window: major=148, minor=1, bad=394 I'm not familiar with the protocol, but it looks like 199c is the command sequence number and 148,1 are the opcodes of the Present extension and one of its functions. From presenttokens.h, opcode 1 is "X_PresentPixmap". This error would explain why the notification event doesn't come.
Yes, that would make sense, and error 3 is BadWindow. Humm...
Created attachment 6955 [PATCH] compositor: check errors after XPresentPixmap() Can you try with the attached patch?
Created attachment 6956 Debug output with XPresentPixmap error handling Thanks for looking into this. I tested the attached patch in debug mode, and DBG ("XPresentPixmap() ...") was not actually printed, but the debug output contained this instead: DBG[compositor.c:2236] paint_all(): present flip requested, present pending... XError: BadWindow (invalid Window parameter) ==> XID 0x46004ab, Request 148, Error 3 <== Following https://developer.gnome.org/gdk2/stable/gdk2-General.html#gdk-error-trap-push, I added a gdk_flush() call before gdk_error_trap_pop(), and received this output: DBG[compositor.c:1638] present_flip(): XPresentPixmap() window 0x460025d pixmap 0x46004a2: Error 3 DBG[compositor.c:1638] present_flip(): XPresentPixmap() window 0x460025d pixmap 0x46004ce: Error 3 DBG[compositor.c:1638] present_flip(): XPresentPixmap() window 0x460025d pixmap 0x46004a2: Error 3 ... Of course, the desktop still freezes when xfwm4 is started in Present mode.
(In reply to Andrey Vihrov from comment #12) > Created attachment 6956 > Debug output with XPresentPixmap error handling DBG[compositor.c:4289] compositorManageScreen(): Overlay enabled (0x8d -> 0x460025d) DBG[compositor.c:4299] compositorManageScreen(): Window used for output: 0x460025d (overlay) ... DBG[compositor.c:1638] present_flip(): XPresentPixmap() window 0x460025d pixmap 0x46004a2: Error 3 So calling XPresentPixmap() fails on the overlay window, which is weird. Can you post the output of "xwininfo" taken on this window that is said to cause an error (the COW), like for example: xwininfo -id 0x460025d (as with your example, the window id of the COW is 0x460025d)
Another test you could try, disable overlays by adding #undef HAVE_OVERLAYS in src/compositor.c as follow: @@ -57,6 +57,8 @@ #include <X11/extensions/Xdamage.h> #include <X11/extensions/Xrender.h> +#undef HAVE_OVERLAYS + #ifndef SHADOW_RADIUS #define SHADOW_RADIUS 12 Rebuild, and see if present works.
Created attachment 6958 Debug output without overlays Here is the xwininfo output for both the overlay window and the root window on one particular run: xwininfo: Window id: 0x300025d (has no name) Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 1080 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+0 -0+0 -0-0 +0-0 -geometry 1920x1080+0+0 xwininfo: Window id: 0x8d (has no name) Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 1080 Depth: 24 Visual: 0x20 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x22 (not installed) Bit Gravity State: ForgetGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: yes Corners: +0+0 -0+0 -0-0 +0-0 -geometry 1920x1080+0+0 I tested the #undef HAVE_OVERLAYS suggestion, and the result is the same except that now also the previous picture (which appeared frozen before) disappears from the screen and clear desktop background is shown. Debug output is attached above.
DBG[compositor.c:4301] compositorManageScreen(): Window used for output: 0xf5 (root) DBG[compositor.c:4409] compositorManageScreen(): Compositor using XPresent for vsync ... DBG[compositor.c:1640] present_flip(): XPresentPixmap() window 0xf5 pixmap 0x3000526: Error 3 DBG[compositor.c:2243] paint_all(): Warning, present flip failed! So XPresentPixmap() fails on our own child of the overlay window and on the root pixmap as well, I think it's pretty safe to assume that XPresent doesn't work on this system. But I agree xfwm4 should be able to recover and diasble XPresent in that case, that would be the way forward. Meanwhile, I don't know why XPresent fails on your system, which distribution is that? Any particular patch added to the XServer? Any chance that you could try with a build of xserver 1.18.4 pristine or even xserver 1.19.1 built from sources? (note that would need a rebuild of all drivers, though, so probably not practical for you)
Thanks for the response. I use Arch Linux. You can see the precise component versions above, except that now I have Linux 4.9.3 and X.org server 1.19.1. The X.org server build is vanilla without additional patches (see https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/xorg-server). Do you happen, by chance, to know any simple tests for the Present extension that I could run and confirm that it is broken? Previously I found some in https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/test , but from #intel-gfx on FreeNode I understood that they are not expected to pass with current git master.
In the Fedora package source the configure line for the X.org server contains --enable-present, but in the above Arch Linux package source it does not. https://src.fedoraproject.org/cgit/rpms/xorg-x11-server.git/tree/xorg-x11-server.spec#n409 It would be quite stupid if this was the problem, but I will try to rebuild with this option and see the results…
I don't think "--enable-present" is the problem, but there is another difference that strikes me, Archlinux package enables only "--enable-dri" whereas Fedora enables all 3 versions using "--enable-dri --enable-dri2 --enable-dri3". As Xpresent depends on dri3, I wonder if that could be that DRI3 support is missing for you? Can you post the output of xdpyinfo on your system?
Created attachment 6960 xdpyinfo output Indeed, the Present extension is enabled by default: https://cgit.freedesktop.org/xorg/xserver/tree/configure.ac#n617 From xdpyinfo, both DRI3 and Present are enabled. So it appears that the server enables the required features.
Can you try with current git code, I have pushed a series of patches aimed at detecting the error with XPresent and disabling it in that case. That won't fix XPresent support, but at least the desktop will be usable.
I tested the latest git revision, and received a somewhat unexpected result: when present_error_handler() is called, screen_info is set to NULL, and the following if check evaluates to false. myDisplayGetScreenFromOutput() prints this: "no screen found for output window (nil)". I replaced %p with %lx to match the Window type, and the result is "0".
Today I tested the Enlightenment DR16 window manager, which can also support XPresent through libXpresent. It hangs in the same way when Present compositing is enabled. So, most likely, this bug is a problem with one of the underlying components rather than the window manager.
Today presentproto headers version 1.1 were released. After upgrading from presentproto 1.0 and rebuilding libXpresent/xfwm4, Present compositing works. In fact, I subjectively see less lag than with OpenGL compositing. I think that this commit is relevant: https://cgit.freedesktop.org/xorg/proto/presentproto/commit/?id=8405ee4552565825d776e6a8963d33d9cd9cddf0 It would explain the problem exactly. Did you run tests on a 32-bit machine or with presentproto newer than 1.0? I suppose that the special XPresentPixmap() error handling in compositor.c is probably unneeded now (it doesn't work anyway, see comment 22). I would like to say thanks for helping to debug this problem, even though in the end it turned out to be elsewhere.
Closing as per comment 24