Bug 104678 - wine gallium nine d3dadapter applications freeze after single frame for PresentCompleteNotify (commit 5c00e69363)
Summary: wine gallium nine d3dadapter applications freeze after single frame for Prese...
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2018-01-17 20:04 UTC by John
Modified: 2018-12-13 22:38 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description John 2018-01-17 20:04:42 UTC
After commit:
present: Only send PresentCompleteNotify events to the presenting client

Wine gallium nine d3dadapter applications freeze after drawing one frame

With this commit reverted, applications function as expected

It is reported for wine gallium nine:
Two xcb connections are used
Two clients use the same windows and wine gallium nine hits what the patch disallows
Believed legal according to the specification?

If this is not the case, where is the error?

Thank you,

wine gallium nine issue:

Wine gallium nine usage of present:

Found using:
Arch Linux
linux 4.14.13
mesa 17.3.2
llvm 5.0.1
xorg-server 1.19.6
wine-staging + gallium nine 2.21
PathOfExile.exe --nodx9ex (directx9)
Comment 1 Axel Davy 2018-01-18 08:26:14 UTC

Gallium nine uses an xcb connection to do presentation, and another one to do everything else (including listening to present events).

The backend was written a few years ago, and there was issues with libxcb back then. The use of two connections was a way to avoid these issues and have a safe 
 and efficient implementation (presentations can occur in a different thread and at the same time the presentation occur, the main thread may be waiting for presentation events).
Comment 2 Michel Dänzer 2018-01-18 10:38:27 UTC
I believe the intent was for this to be controlled via the PRESENTEVENTID described in the Present extension. Unfortunately, the PresentPixmap request doesn't take a PRESENTEVENTID parameter, so the only choices for PresentCompleteNotify events are either sending all of them to all clients which registered for them for the given window, or only sending them to the client which made the corresponding PresentPixmap request.

I made the change in question to fix a problem with Mozilla Firefox and Thunderbird getting confused by each other's PresentCompleteNotify events on the same window (probably the root window). However, I just landed https://cgit.freedesktop.org/mesa/mesa/commit/?id=7b0e8264dd21ae05521d08d41fecd84139401fef , which prevents the same problem on the client side. So if nine really can't use the same client connection for making PresentPixmap requests and processing the resulting PresentCompleteNotify events (do the XCB issues persist with 1.11.1 or newer?), the xserver change can be reverted.
Comment 3 Axel Davy 2018-01-20 09:22:29 UTC
Reading carefully the present proto, I don't see any reference to whether a client listening on a window should receive the events produced by requests of another client or not.
There is the sentence "RedirectNotify events inform clients about other clients PresentPixmap requests." but that sentence is about requests, not events.

If one has to use the same client, how would you have one thread (a) waiting on events and one other thread (b) sending present pixmap requests (which is what gallium nine does with some configuration options) ?
If the thread (a) is waiting, (b) cannot even send a presentNotifyMSC request to wake it up, since (b) cannot use the same xcb connection (unless the same xcb connection can be used by two threads at the same time ?).

Thus unless there is a way I haven't seen to handle well that two thread approach, I would suggest to revert the change and allow several clients again.
Comment 4 Axel Davy 2018-01-20 09:52:31 UTC
I seem to remember now that waiting on one thread with libxcb and sending events on another with the same connection is supposed to be allowed with libxcb.
We hit issues with that approach and some events were disappearing. libxcb was later patched to fix the issue.

We could give a try to having gallium nine using only one connection again, but we need to make sure there is no regression on several configurations (I think wine uses Xlib too, and if I remember well, we have to be careful when using libxcb in multithread when linked with Xlib).
Comment 5 Michel Dänzer 2018-01-24 10:50:35 UTC
I've come to the conclusion that this change needs to be reverted. Adam, please backport this to the 1.19 branch as well:

commit 76732f498f1e73fb081841a04faf068660f3d5c7
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Jan 24 11:40:50 2018 +0100

    Revert "present: Only send PresentCompleteNotify events to the presenting client"
Comment 6 Michel Dänzer 2018-01-24 16:13:50 UTC
Reverted on the 1.19 branch as well, thanks Adam! And apologies for any inconvenience.
Comment 7 Adam Jackson 2018-01-24 16:19:47 UTC
(In reply to Michel Dänzer from comment #6)
> Reverted on the 1.19 branch as well, thanks Adam! And apologies for any
> inconvenience.

No worries, thanks for the heads up.
Comment 8 Axel Davy 2018-01-24 17:44:30 UTC
Thank you for the revert.
Comment 9 Artivision 2018-05-02 01:03:07 UTC
On Fedora 28 and Intel-AMD prime Laptop still happens. It first happened for me on Fedora 27 after updated xorg-x11-server-Xorg from 1.19.5 to 1.19.6.
Comment 10 Axel Davy 2018-05-08 10:35:31 UTC
which version of the xserver is used by Fedora 28 ?
Comment 11 Artivision 2018-05-11 18:45:19 UTC
1.19.6 The bad one.
Comment 12 Artivision 2018-05-18 16:14:18 UTC
Situation saved by manually download and install the package: xorg-x11-server-Xorg-1.19.5-1.fc27.x86_64.rpm from https://pkgs.org/download/xorg-x11-server-Xorg then you need to untick/exclude the package from the updates.
Comment 13 GitLab Migration User 2018-12-13 22:38:53 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/530.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.