[PATCH 2/3] sync: Serialise access to the fence before waking clients

By waking the clients before we finish the work associated with the fence we expose ourselves to a race where the clients may see the incomplete results. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- miext/sync/misyncshm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

DRI3 fixes

There is an issue with the DRI3 protocol that limits stride to CARD16. Even on old Intel hw we can exceed that which prevents the protocol from transporting many valid buffers. [PATCH 1/3] xfree86: Report DRI3 as a built-in module [PATCH 2/3] sync: Serialise access to the fence before waking

[PATCH 1/3] xfree86: Report DRI3 as a built-in module

This is so that drivers can do a runtime check that DRI3 is available, similar to existing runtime checks performed by the drivers for DRI and DRI2. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk --- hw/xfree86/loader/loadmod.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 3/3] sync: Record the associated Drawable for a shm/fd fence

Alongside DRI3, SHM fences are used to serialise changes to the Pixmap shared between the client and the xserver. By recording the associated Drawable for a particular fence, the driver can reduce the amount of work required for serialisation (i.e. it only has to serialise access to one Pixmap,

Re: [PATCH 1/3] xfree86: Report DRI3 as a built-in module

From: Chris Wilson ch...@chris-wilson.co.uk Date: Mon, 12 May 2014 08:12:37 +0100 This is so that drivers can do a runtime check that DRI3 is available, similar to existing runtime checks performed by the drivers for DRI and DRI2. Does that run-time check actually work? It seems any check

Re: [PATCH 1/3] xfree86: Report DRI3 as a built-in module

On Mon, May 12, 2014 at 11:29:58AM +0200, Mark Kettenis wrote: From: Chris Wilson ch...@chris-wilson.co.uk Date: Mon, 12 May 2014 08:12:37 +0100 This is so that drivers can do a runtime check that DRI3 is available, similar to existing runtime checks performed by the drivers for DRI and

Re: XCMSDB stdin handling broke in v 1.0.3 - 1.0.4

It looks like that change came from Jeremy's fixes for static analysis: http://cgit.freedesktop.org/xorg/app/xcmsdb/commit/?id=f872b47cb606d448766c1fa750709fd06a8a6904 Sorry, but I'm not going to have time to work on fixing this soon, so I'm cc'ing the mailing list in case someone else has time

Re: [PATCH 2/3] sync: Serialise access to the fence before waking clients

Chris Wilson ch...@chris-wilson.co.uk writes: diff --git a/miext/sync/misyncshm.c b/miext/sync/misyncshm.c index 01f82fc..4d11b57 100644 --- a/miext/sync/misyncshm.c +++ b/miext/sync/misyncshm.c @@ -50,9 +50,9 @@ miSyncShmFenceSetTriggered(SyncFence * pFence) { SyncShmFencePrivatePtr

Re: [PATCH 3/3] sync: Record the associated Drawable for a shm/fd fence

Chris Wilson ch...@chris-wilson.co.uk writes: Alongside DRI3, SHM fences are used to serialise changes to the Pixmap shared between the client and the xserver. By recording the associated Drawable for a particular fence, the driver can reduce the amount of work required for serialisation

Re: [PATCH] glamor: Don't forget to check whether we can fall back in polysegment.

Eric Anholt e...@anholt.net writes: Part of the _nf contract is that glamor will only return FALSE if glamor has checked that UXA can actually map the pixmaps (UXA only allocates the BO itself in the screen pixmap and DRI2 cases, and can't map it otherwise). Fixes server segfaults zooming in

Re: [PULL] MatchSeat, logind patch, two invalid memory access

Peter Hutterer peter.hutte...@who-t.net writes: Laércio de Sousa (2): xfree86: allow fallback to PCI bus probe for graphics devices on non-seat0 X servers (#66851) xfree86: add short description about MatchSeat key in xorg.conf man page Oleg Samarin (1): xfree86: add new

Re: [PATCH] rrcrtc: brackets are hard, lets go shopping.

Dave Airlie airl...@gmail.com writes: Slaving two outputs on a secondary GPU to a primary GPU testing picked this up, in that we'd try to resize to the totally the wrong thing, then as usual segfault in the rotation code. Signed-off-by: Dave Airlie airl...@redhat.com Merged, with review:

Re: [PATCH 1/5] xorg: Fix a bunch of format string size warnings in debug code.

walter harms wha...@bfs.de writes: -DebugF(xf86ReadBIOS: BIOS at 0x%08x has signature 0x%04x\n, +DebugF(xf86ReadBIOS: BIOS at 0x%08lx has signature 0x%04x\n, Base, ptr[0] | (ptr[1] 8)); (void) memcpy(Buf, (void *) (ptr + Offset), Len); (void) munmap((caddr_t)

Re: [PATCH 5/5] ephyr: Fix a bad debug print format string.

Eric Anholt e...@anholt.net writes: Signed-off-by: Eric Anholt e...@anholt.net --- hw/kdrive/ephyr/ephyr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/kdrive/ephyr/ephyr.c b/hw/kdrive/ephyr/ephyr.c index def50d8..11b5ae9 100644 --- a/hw/kdrive/ephyr/ephyr.c +++

[PATCH] openchrome: Do not require libdrm

We can build without it. Proper non-fatal finer libdrm detection is already done below this. Signed-off-by: Samuel Thibault samuel.thiba...@ens-lyon.org diff --git a/configure.ac b/configure.ac index b13cb2c..9e77dc8 100644 --- a/configure.ac +++ b/configure.ac @@ -80,7 +80,7 @@

xorg endless vacation of code

i have read the wiki page of xorg evoc but still dont know how to proceed...by the way any book for xorg development??would be great if anybody could help :) -- Tapesh Mandal Flat No. S-1 Wastusakha Sahaniwas 185/3, J.B.Thakkar Marg P.O. Giripeth. Nagpur - 440 010

[PATCH] DRI2: By default, throttle after two pending swaps.

According to Chris Wilson, the Intel driver has a horrifying kludge to get triple-buffering despite the swap_limit being set to only allow double-buffering by default. This kludge makes OML_sync_control unusable if the Intel driver goes into page-flipping mode. Since triple-buffering is preferred

Re: [PATCH] Fix XNextRequest() after direct usage of XCB

On Sat, May 10, 2014 at 02:55:11PM +0200, Uli Schlachter wrote: On 10.05.2014 00:21, otay...@redhat.com wrote: From: Owen W. Taylor otay...@fishsoup.net When XCB owns the X socket, dpy-request is not updated, so NextRequest() and XNextRequest() return the wrong value. There's nothing