Bug 104678

Hi.

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

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.

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.

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

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"

Reverted on the 1.19 branch as well, thanks Adam! And apologies for any inconvenience.

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

Thank you for the revert.

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.

which version of the xserver is used by Fedora 28 ?

1.19.6 The bad one.

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.

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