[PATCH xserver] xkb: fix SlowKeys release/reject beeps

Wrong use of the mask here caused a beep whenever a key was rejected but also when it was released after being accepted. Fix the mask to check for the correct enabled controls. Signed-off-by: Peter Hutterer --- xkb/xkbAccessX.c | 5 - 1 file changed, 4

Re: [PATCH xserver 0/9] double frees in AddResource failure paths

Le 07/03/2016 23:20, Julien Cristau a écrit : > Hi, > > prompted by Adam's recent fixes for unchecked AddResource, I've been > looking at the failure paths, and found a number of places where it > looks like we're freeing things twice (once as part of AddResource > itself calling the destroy

[PATCH xserver 3/9] glx: don't call pGlxDraw->destroy() if AddResource fails

AddResource will have called DrawableGone, which takes care of the destruction. Signed-off-by: Julien Cristau --- glx/glxcmds.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/glx/glxcmds.c b/glx/glxcmds.c index 0416dac..6eb3541 100644 ---

[PATCH xserver 0/9] double frees in AddResource failure paths

Hi, prompted by Adam's recent fixes for unchecked AddResource, I've been looking at the failure paths, and found a number of places where it looks like we're freeing things twice (once as part of AddResource itself calling the destroy function for the resource, and once in the caller). Plus more

[PATCH xserver 6/9] xwin: no need to free auth data if AddResource fails

This is taken care of by SecurityDeleteAuthorization Signed-off-by: Julien Cristau --- hw/xwin/winauth.c | 17 +++-- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/hw/xwin/winauth.c b/hw/xwin/winauth.c index 7efa1c0..7be7dca 100644 ---

[PATCH xserver 4/9] dmx/glxProxy: don't free the glx pixmap twice if AddResource fails

Signed-off-by: Julien Cristau --- hw/dmx/glxProxy/glxcmds.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/hw/dmx/glxProxy/glxcmds.c b/hw/dmx/glxProxy/glxcmds.c index ddcb981..a77d556 100644 --- a/hw/dmx/glxProxy/glxcmds.c +++

[PATCH xserver 2/9] dri3: return an error if AddResource fails

Signed-off-by: Julien Cristau --- dri3/dri3_request.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/dri3/dri3_request.c b/dri3/dri3_request.c index 2b36221..35548b6 100644 --- a/dri3/dri3_request.c +++ b/dri3/dri3_request.c @@ -178,8 +178,8 @@

[PATCH xserver 7/9] record: don't call RecordDeleteContext when AddResource fails

Signed-off-by: Julien Cristau --- record/record.c | 1 - 1 file changed, 1 deletion(-) diff --git a/record/record.c b/record/record.c index 1caf3f1..82bb060 100644 --- a/record/record.c +++ b/record/record.c @@ -1878,7 +1878,6 @@ ProcRecordCreateContext(ClientPtr client)

[PATCH xserver 8/9] render: free already allocated formats in PictureInit failure case

Probably pointless, if this fails you're not likely to get far... Signed-off-by: Julien Cristau --- render/picture.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/render/picture.c b/render/picture.c index 6d9c9df..9e4036e 100644 --- a/render/picture.c +++

[PATCH xserver 9/9] xfixes: avoid double free if AddResource fails

pChc is already freed through CursorFreeHideCount → deleteCursorHideCount. Signed-off-by: Julien Cristau --- xfixes/cursor.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/xfixes/cursor.c b/xfixes/cursor.c index 5619aad..10f9b23 100644 ---

[PATCH xserver 1/9] xvmc: Fix unchecked AddResource

Signed-off-by: Julien Cristau --- Xext/xvmc.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/Xext/xvmc.c b/Xext/xvmc.c index 64eda92..7565c17 100644 --- a/Xext/xvmc.c +++ b/Xext/xvmc.c @@ -253,6 +253,10 @@

[PATCH xserver 5/9] modesetting: avoid double free if AddResource fails

ms_dri2_frame_event_client_gone or ms_dri2_frame_event_drawable_gone already free the resource. Signed-off-by: Julien Cristau --- hw/xfree86/drivers/modesetting/dri2.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On 07-03-16 19:23, Hans de Goede wrote: Hi, On 07-03-16 18:44, Olivier Fourdan wrote: Key repeat is handled by the X server, but for Wayland, the key press/release events need to be processed and forwarded by the Wayland compositor first. If the Wayland compositor get stuck for whatever

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On 07-03-16 18:44, Olivier Fourdan wrote: Key repeat is handled by the X server, but for Wayland, the key press/release events need to be processed and forwarded by the Wayland compositor first. If the Wayland compositor get stuck for whatever reason and does not process the key release

[PATCH xserver 2/2] xwayland: add a server sync before repeating keys

Key repeat is handled by the X server, but input events need to be processed and forwarded by the Wayland compositor first. Make sure the Wayland compositor is actually processing events, to avoid repeating keys in xwayland while the Wayland compositor cannot deal with input events for whatever

[PATCH xserver 1/2] xkb: add hook to allow/deny AccessX key repeat

The xserver generates the key repeat by itself. But when used with another server processing inputs first (e.g. a Wayland compositor), the other server may be busy dealing with some other things and not queue up key release events in time. Add a vfunc in XkbSrvInfo to possibly add a check before

[PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Key repeat is handled by the X server, but for Wayland, the key press/release events need to be processed and forwarded by the Wayland compositor first. If the Wayland compositor get stuck for whatever reason and does not process the key release event fast enough, this may cause the Xwayland