[PATCH libX11 v3] XKB: fix XkbGetKeyboardByName with Xming server

XkbGetKeyboardByName relies on flags to read the data from the server. If the X server sends us the wrong flags or if a subreply is smaller than it should be, XkbGetKeyboardByName will not read all the available data and leave data in the buffer, which will cause the next _XReply() to fail with:

[PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

XkbGetKeyboardByName relies on flags to read the data from the server. If the X server sends us the wrong flags or if a subreply is smaller than it should be, XkbGetKeyboardByName will not read all the available data and leave data in the buffer, which will cause the next _XReply() to fail with:

Re: [PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

+ Peter of course! On 21 January 2016 at 09:58, Olivier Fourdan wrote: > XkbGetKeyboardByName relies on flags to read the data from the server. > > If the X server sends us the wrong flags or if a subreply is smaller > than it should be, XkbGetKeyboardByName will not read

[PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

XkbGetKeyboardByName relies on flags to read the data from the server. If the X server sends us the wrong flags or if a subreply is smaller than it should be, XkbGetKeyboardByName will not read all the available data and leave data in the buffer, which will cause the next _XReply() to fail with:

Re: [PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

On Thu, Jan 21, 2016 at 10:48:05AM +0100, Olivier Fourdan wrote: > XkbGetKeyboardByName relies on flags to read the data from the server. > > If the X server sends us the wrong flags or if a subreply is smaller > than it should be, XkbGetKeyboardByName will not read all the available > data and

Re: [PATCH libX11] XKB: fix XkbGetKeyboardByName with Xming server

Hi, On 21 January 2016 at 08:58, Olivier Fourdan wrote: > XkbGetKeyboardByName relies on flags to read the data from the server. > > If the X server sends us the wrong flags or if a subreply is smaller > than it should be, XkbGetKeyboardByName will not read all the available

Re: [PATCH libX11 v2] XKB: fix XkbGetKeyboardByName with Xming server

On 21 January 2016 at 09:48, Olivier Fourdan wrote: > XkbGetKeyboardByName relies on flags to read the data from the server. > > If the X server sends us the wrong flags or if a subreply is smaller > than it should be, XkbGetKeyboardByName will not read all the available >

Re: [PATCH xserver] glx: Fix GLX_EXT_create_context_es2_profile support

On Wed, 2016-01-20 at 15:50 -0500, Adam Jackson wrote: > As of v4 of this extension, any GLES version number may be requested (to > enable GLES3 and later). To comply with this, simply remove the API > version checks and leave it to the DRI driver to validate. This happens > to also enable using

Re: [PATCH libX11 v3] XKB: fix XkbGetKeyboardByName with Xming server

On Thu, Jan 21, 2016 at 11:54:19AM +0100, Olivier Fourdan wrote: > XkbGetKeyboardByName relies on flags to read the data from the server. > > If the X server sends us the wrong flags or if a subreply is smaller > than it should be, XkbGetKeyboardByName will not read all the available > data and

[PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

Please cherry-pick this to active stable branches. Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up failing, unless you're doing a straight copy at the same bpp where the misinterpretation matches on both sides. Fixes rendercheck/blend/over and renderhceck/blend/src in piglit.

[PATCH xserver 2/2] glamor: Drop the composite_with_copy path entirely.

I originally inherited this from the EXA code, without determining whether it was really needed. Regular composite should end up doing the same thing, since it's all just shaders anyway. To the extent that it doesn't, we should fix composite. Signed-off-by: Eric Anholt ---

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

On 22 January 2016 at 07:06, Eric Anholt wrote: > Please cherry-pick this to active stable branches. > > Reading and writing to 16-depth pixmaps using PICT_x1r5g5b5 ends up > failing, unless you're doing a straight copy at the same bpp where the > misinterpretation matches on

Re: [PATCH xserver 2/2] glamor: Drop the composite_with_copy path entirely.

On 22 January 2016 at 07:06, Eric Anholt wrote: > I originally inherited this from the EXA code, without determining > whether it was really needed. Regular composite should end up doing > the same thing, since it's all just shaders anyway. To the extent > that it doesn't, we

[PATCH xserver 1/3] glamor: Drop duplicated GLAMOR_DEFAULT_PRECISIONs in render accel.

We only need it once at the top of the shader, so just put it there. Signed-off-by: Eric Anholt --- glamor/glamor_render.c | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index

[PATCH xserver 2/3] squash: glamor: Fix rendering to a8 textures in core profile.

Signed-off-by: Eric Anholt --- glamor/glamor_priv.h | 10 +- glamor/glamor_render.c | 50 +++--- 2 files changed, 52 insertions(+), 8 deletions(-) diff --git a/glamor/glamor_priv.h b/glamor/glamor_priv.h index

[PATCH xserver 0/3] Fixups for GL_RED patch.

Here are my fixes for the regressions in the glamor-core-profile series. The first commit would go just before the GL_RED change, then I'd squash the other two into GL_RED. The series is now in glamor-core-profile of my fdo tree. Eric Anholt (3): glamor: Drop duplicated

[PATCH xserver 3/3] squash: glamor: Fix Render blending for alpha-to-red.

Signed-off-by: Eric Anholt --- glamor/glamor_render.c | 36 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index c36b345..51718d1 100644 --- a/glamor/glamor_render.c +++

Re: [PATCH xserver 1/2] glamor: Fix copy-like Render operations between 15 and 16 depth.

Eric Anholt writes: > if (op == PictOpSrc) { > +/* We can't do direct copies between different depths at 16bpp > + * because r,g,b are allocated to different bits. > + */ > +if (dst->pDrawable->bitsPerPixel == 16 && > +