Re: [PATCH v3 0/4] xprop: Free various allocated memory

Adam Jackson writes: > On Thu, 2015-07-23 at 11:17 +0200, Eirik Byrkjeflot Anonsen wrote: > >> I'm not particularly surprised, but given that the patch is made and is >> largely trivial it would be nice to get it into the official code. Does >> anyone have any idea how to make

[PATCH:xserver 2/5] protocol.txt: Add RANDR 1.5 requests

Signed-off-by: Alan Coopersmith --- dix/protocol.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/dix/protocol.txt b/dix/protocol.txt index cf612b5..dfeca5f 100644 --- a/dix/protocol.txt +++ b/dix/protocol.txt @@ -277,6 +277,9 @@ R038

[PATCH:xserver 4/5] protocol.txt: Add DRI3 1.0 requests

Signed-off-by: Alan Coopersmith --- dix/protocol.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/dix/protocol.txt b/dix/protocol.txt index ac66d95..459c385 100644 --- a/dix/protocol.txt +++ b/dix/protocol.txt @@ -101,6 +101,12 @@ R011 DRI2:WaitSBC

[PATCH:xserver 5/5] protocol.txt: Add MIT-SHM 1.2 requests

Signed-off-by: Alan Coopersmith --- dix/protocol.txt |2 ++ 1 file changed, 2 insertions(+) diff --git a/dix/protocol.txt b/dix/protocol.txt index 459c385..244556a 100644 --- a/dix/protocol.txt +++ b/dix/protocol.txt @@ -237,6 +237,8 @@ R002 MIT-SHM:Detach R003

[PATCH] glx: fix regression with copy sub buffer disappearing

From: Fedora X Ninjas So copy sub buffer isn't a core extensions it's a driver extension which means we are using totally the wrong interface to query for it here, which means bad things happen when you roll out this code, for instance MESA_copy_sub_buffer stops working.

[PATCH:xserver 1/5] protocol.txt: Remove extensions that died before Xorg was born

Adobe-DPS-Extension, DEC-XTRAP, X3D-PEX, XIE Signed-off-by: Alan Coopersmith --- dix/protocol.txt | 182 -- 1 file changed, 182 deletions(-) diff --git a/dix/protocol.txt b/dix/protocol.txt index 4633e08..cf612b5

[PATCH:xserver 3/5] protocol.txt: Add Present 1.0 requests

Signed-off-by: Alan Coopersmith --- dix/protocol.txt |5 + 1 file changed, 5 insertions(+) diff --git a/dix/protocol.txt b/dix/protocol.txt index dfeca5f..ac66d95 100644 --- a/dix/protocol.txt +++ b/dix/protocol.txt @@ -235,6 +235,11 @@ V000

Re: [pull request] xwayland fixes

Hi Adam, - Original Message - > Ugh. abidiff is still complaining, and I'm not entirely sure it's > wrong. The problem is there's a SpriteRec embedded in the middle of > TouchPointInfoRec, so changing the former at all changes the latter. It > seems icky to me to have that be a SpriteRec

Re: [PATCH v6 RFC 01/10] ephyr: allow passing explictly host X server display number and/or authorization file path

I'm not endorsing this patch anymore. It could be perfectly replaced with other approaches: * Rely on DM settings to set DISPLAY/XAUTHORITY variables * Set custom command "env DISPLAY=(...) XAUTHORITY=(...) Xephyr (...)" in DM settings Since patch 08/10 has already been merged, patches

Re: [PATCH v3 0/4] xprop: Free various allocated memory

On Thu, 2015-07-23 at 11:17 +0200, Eirik Byrkjeflot Anonsen wrote: > I'm not particularly surprised, but given that the patch is made and is > largely trivial it would be nice to get it into the official code. Does > anyone have any idea how to make that happen? Apologies for the delay here,

Re: [PATCH xserver] glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import

On Tue, 2015-09-22 at 15:35 +0100, Emil Velikov wrote: > Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image) > Cc: Eric Anholt > Suggested-by: Eric Anholt > Signed-off-by: Emil Velikov Thanks for catching this, I'd

[PATCH xserver] glamor: move GL_OES_EGL_image check next to EGL_EXT_image_dma_buf_import

We're using the former only as the latter is present. Thus in some cases we might incorrectly error out if it's missing. Namely - glamor_glx, glamor_egl without gbm, EGL_KHR_gl_texture_2D_image or EGL_EXT_image_dma_buf_import. Fixes 58d54ee82df(glamor: explicitly check for GL_OES_EGL_image) Cc:

Re: [PATCH] glamor: explicitly check for GL_OES_EGL_image

Hi Eric, On 17 September 2015 at 15:52, Eric Anholt wrote: > Emil Velikov writes: > >> Otherwise we'll fail miserably later on as we try to use >> glEGLImageTargetTexture2DOES. > > I thought this had been implied by other extensions we check for, but I