[PATCH xserver 3/4] dri2: Only create one unnamed reference per Drawable per Client

This workarounds issues in mesa and Mali that likes to create a new DRI2Drawble per context and per frame, respectively. The idea is that we only create one unnamed reference per Client on each Drawable that is never destroyed - and we make the assumption that the only caller is the DRI2

[PATCH xserver 2/4] dri2: Split resource tracking for DRI2Drawable and references to them

In order to ease resource tracking, disentangle DRI2Drawable XIDs from their references. This will be used in later patches to first limit the object leak from unnamed references created on behalf of Clients and then never destroy, and then to allow Clients to explicit manage their references to

[PATCH xserver 4/4] dri2: Unblock Clients on Drawable release

If the Window is destroyed by another client, such as the window manager, the original client may be blocked by DRI2 awaiting a vblank event. When this happens, DRI2DrawableGone forgets to unblock that client and so the wait never completes. Note Present/xshmfence is also suspectible to this

[PATCH xserver 1/4] dri2: Only invalidate the immediate Window upon SetWindowPixmap

All callers of SetWindowPixmap will themselves be traversing the Window heirachy updating the backing Pixmap of each child and so we can forgo doing the identical traversal inside the DRI2SetWindowPixmap handler. Reported-by: Loïc Yhuel Link:

Re: [PATCH] xwayland: Only request cursor frame events if the surface is visible

On Tue, 2 Feb 2016 21:06:33 +0100 Rui Matos wrote: > If the wayland compositor hides our cursor surface (e.g. because the > pointer moved over a different wayland client) before our last > submitted buffer gets a chance to be displayed, no frame event will be > sent and

Re: [PATCH xserver 1/3] res: Simplify QueryClientPixmapBytes

Adam Jackson writes: > I suspect this code predates the common resource hooks for computing > sizes. It's ugly in any case since the Resource extension shouldn't > need to know which extensions can take a reference on pixmaps. Instead, > let's just walk every resource for the

Re: [PATCH xserver 1/3] res: Simplify QueryClientPixmapBytes

Adam Jackson writes: > I don't really understand your objection about pixmaps not in the > resdb, because ResQueryClientPixmapBytes is _already_ not accounting > for those, and it's not clear to me how it even could. Sorry, that code has gotten a lot more sophisticated since I

Re: [PATCH xserver 4/4] dri2: Unblock Clients on Drawable release

On Wed, Feb 03, 2016 at 09:54:46AM +, Chris Wilson wrote: > If the Window is destroyed by another client, such as the window > manager, the original client may be blocked by DRI2 awaiting a vblank > event. When this happens, DRI2DrawableGone forgets to unblock that > client and so the wait

[PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

The last cursor frame we commited before the pointer left one of our surfaces might not have been shown. In that case we'll have a cursor surface frame callback pending which we need to clear so that we can continue submitting new cursor frames. Signed-off-by: Rui Matos ---

Re: [PATCH xserver 3/4] dri2: Only create one unnamed reference per Drawable per Client

On Wed, Feb 03, 2016 at 09:54:45AM +, Chris Wilson wrote: > This workarounds issues in mesa and Mali that likes to create a new > DRI2Drawble per context and per frame, respectively. The idea is that we > only create one unnamed reference per Client on each Drawable that is > never destroyed -

Re: [PATCH xserver 2/4] dri2: Split resource tracking for DRI2Drawable and references to them

On Wed, Feb 03, 2016 at 09:54:44AM +, Chris Wilson wrote: > In order to ease resource tracking, disentangle DRI2Drawable XIDs from > their references. This will be used in later patches to first limit the > object leak from unnamed references created on behalf of Clients and > then never

Re: [PATCH xserver 1/3] res: Simplify QueryClientPixmapBytes

On Wed, 2016-02-03 at 21:34 +1100, Keith Packard wrote: > Adam Jackson writes: > > > I suspect this code predates the common resource hooks for computing > > sizes.  It's ugly in any case since the Resource extension shouldn't > > need to know which extensions can take a

Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

On Wed, Feb 03, 2016 at 05:46:35PM -0800, Bryce Harrington wrote: > On Wed, Feb 03, 2016 at 04:14:09PM +0100, Rui Matos wrote: > > The last cursor frame we commited before the pointer left one of our > > surfaces might not have been shown. In that case we'll have a cursor > > surface frame

Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

On Wed, Feb 03, 2016 at 04:14:09PM +0100, Rui Matos wrote: > The last cursor frame we commited before the pointer left one of our > surfaces might not have been shown. In that case we'll have a cursor > surface frame callback pending which we need to clear so that we can > continue submitting new

Re: [PATCH xserver 1/4] dri2: Only invalidate the immediate Window upon SetWindowPixmap

On Wed, Feb 03, 2016 at 09:54:43AM +, Chris Wilson wrote: > All callers of SetWindowPixmap will themselves be traversing the Window > heirachy updating the backing Pixmap of each child and so we can forgo > doing the identical traversal inside the DRI2SetWindowPixmap handler. > > Reported-by: