Re: [PATCH libx11] Plug a memory leak

[Peter Hutterer]

On Tue, Oct 25, 2016 at 09:30:15PM +0200, Emilio Pozuelo Monfort wrote:
> This was introduced in 8ea762f.
> 
> Reported-by: Julien Cristau 
> Signed-off-by: Emilio Pozuelo Monfort 

pushed, thanks.

   8f349fe..20a3f99  master -> master

Cheers,
   Peter

> ---
>  src/FontNames.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/src/FontNames.c b/src/FontNames.c
> index e55f338..3e23b5f 100644
> --- a/src/FontNames.c
> +++ b/src/FontNames.c
> @@ -98,12 +98,14 @@ int *actualCount) /* RETURN */
>   *ch = '\0';  /* and replace with null-termination */
>   count++;
>   } else {
> +Xfree(ch);
>  Xfree(flist);
>  flist = NULL;
>  count = 0;
>  break;
>   }
>   } else {
> +Xfree(ch);
>  Xfree(flist);
>  flist = NULL;
>  count = 0;
> -- 
> 2.9.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xf86-input-libinput] Don't init the AccelSpeed/LeftHanded properties on the base tablet device

[Peter Hutterer]

This device never sends events, no point in exposing these options

Signed-off-by: Peter Hutterer 
---
 src/xf86libinput.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 8ee6cbe..07b4d4e 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -4092,7 +4092,8 @@ LibinputInitAccelProperty(DeviceIntPtr dev,
enum libinput_config_accel_profile profile;
BOOL profiles[2] = {FALSE};
 
-   if (!libinput_device_config_accel_is_available(device))
+   if (!libinput_device_config_accel_is_available(device) ||
+   driver_data->capabilities & CAP_TABLET)
return;
 
prop_accel = LibinputMakeProperty(dev,
@@ -4260,7 +4261,8 @@ LibinputInitLeftHandedProperty(DeviceIntPtr dev,
 {
BOOL left_handed = driver_data->options.left_handed;
 
-   if (!libinput_device_config_left_handed_is_available(device))
+   if (!libinput_device_config_left_handed_is_available(device) ||
+   driver_data->capabilities & CAP_TABLET)
return;
 
prop_left_handed = LibinputMakeProperty(dev,
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: Transform pointer enter event coordinates

[Jonas Ådahl]

On Tue, Oct 25, 2016 at 07:24:49PM +0200, Rui Matos wrote:
> Pointer enter event coordinates are surface relative and we need them
> to be screen relative for pScreen->SetCursorPosition().
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=758283
> 
> Signed-off-by: Rui Matos 

Reviewed-by: Jonas Ådahl 

> ---
>  hw/xwayland/xwayland-input.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index f2327dc..1352197 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer 
> *pointer,
>  int i;
>  int sx = wl_fixed_to_int(sx_w);
>  int sy = wl_fixed_to_int(sy_w);
> +int dx, dy;
>  ScreenPtr pScreen = xwl_seat->xwl_screen->screen;
>  ValuatorMask mask;
>  
> @@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer 
> *pointer,
>  xwl_seat->pointer_enter_serial = serial;
>  
>  xwl_seat->focus_window = wl_surface_get_user_data(surface);
> +dx = xwl_seat->focus_window->window->drawable.x;
> +dy = xwl_seat->focus_window->window->drawable.y;
>  
>  master = GetMaster(dev, POINTER_OR_FLOAT);
> -(*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE);
> +(*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE);
>  
>  miPointerInvalidateSprite(master);
>  
> -- 
> 2.9.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: EXT: Re: [xserver-xorg][PATCH V2 1/1] xwayland-shm: block signals during fallocate

[Ian Ray]

On Thu, May 26, 2016 at 04:43:44PM +0100, Daniel Stone wrote:
> On 25 May 2016 at 08:41, Ian Ray  wrote:
> > posix_fallocate() does an explicit rollback if it gets EINTR, and
> > this is a problem on slow systems because when the allocation size
> > is sufficiently large posix_fallocate() will always be interrupted
> > by the smart scheduler's SIGALRM.
> >
> > Changes since v1 - big comment in the code to explain what is going on
> >
> > Signed-off-by: Ian Ray 
> 
> Acked-by: Daniel Stone 

Any news on this?  f48b0534f110397246809d279225afedb28aa233 does not
resolve the EINTR on slow systems.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH libxi 2/2] Check that allocating a buffer succeeded

[Peter Hutterer]

On Tue, Oct 25, 2016 at 09:31:19PM +0200, Emilio Pozuelo Monfort wrote:
> Since we are going to write into the buffer, we should make sure the
> allocation didn't fail.
> 
> Reported-by: Julien Cristau 
> Signed-off-by: Emilio Pozuelo Monfort 

both applied, thanks.

   1bdeb43..4c5c8d6  master -> master

Cheers,
   Peter

> ---
>  src/XIQueryDevice.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
> index e3b0c9f..a877d78 100644
> --- a/src/XIQueryDevice.c
> +++ b/src/XIQueryDevice.c
> @@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int 
> *ndevices_return)
>  {
>   *ndevices_return = reply.num_devices;
>   info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo));
> + buf = Xmalloc(reply.length * 4);
>  }
>  else
>  {
>   *ndevices_return = 0;
>   info = NULL;
> + buf = NULL;
>  }
>  
> -if (!info)
> +if (!info || !buf)
>  goto error;
>  
> -buf = Xmalloc(reply.length * 4);
>  _XRead(dpy, buf, reply.length * 4);
>  ptr = buf;
>  end = buf + reply.length * 4;
> @@ -135,9 +136,9 @@ error_loop:
>  Xfree(info[i].name);
>  Xfree(info[i].classes);
>  }
> +error:
>  Xfree(info);
>  Xfree(buf);
> -error:
>  UnlockDisplay(dpy);
>  error_unlocked:
>  SyncHandle();
> -- 
> 2.9.3
> 
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: https://lists.x.org/mailman/listinfo/xorg-devel
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] glamor: don't look for non-existing EGL_KHR_platform_base

[Adam Jackson]

On Fri, 2016-10-21 at 19:06 +0100, Emil Velikov wrote:
> > From: Emil Velikov 
> 
> The extensions does not exist in the registry, thus needs to know
> they're using EGL 1.5 in order to determine the eglGetPlatformDisplay
> function pointer is valid.
> 
> Thus brings us into some lovely circular dependency.

Ugh.  Right you are, I seem to have gotten a bit optimistic by seeing
other EGL_KHR_platform_* extensions.

> In practise (checked with the Mali driver) any EGL 1.5 driver will
> advertise support for EGL_EXT_platform_base.

Yeah, I think this pretty much has to be true. The whole point of the
platform extensions is that you have to use them _before_ you have an
EGL context, meaning you can't know if you're EGL 1.5 ahead of time.
It's kinda lame that 1.5 doesn't have a mandatory extension string for
this (since the KHR entrypoints really do have a different signature)
but that's Khronos' bug not Xorg's.

Merged, thanks:

remote: I: patch #117260 updated using rev 
7fc96fb02dade4a86f2fc038f3cf5f2d9c0cda00.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   5dcb066..7fc96fb  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libxi 2/2] Check that allocating a buffer succeeded

[Emilio Pozuelo Monfort]

Since we are going to write into the buffer, we should make sure the
allocation didn't fail.

Reported-by: Julien Cristau 
Signed-off-by: Emilio Pozuelo Monfort 
---
 src/XIQueryDevice.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
index e3b0c9f..a877d78 100644
--- a/src/XIQueryDevice.c
+++ b/src/XIQueryDevice.c
@@ -66,17 +66,18 @@ XIQueryDevice(Display *dpy, int deviceid, int 
*ndevices_return)
 {
*ndevices_return = reply.num_devices;
info = Xmalloc((reply.num_devices + 1) * sizeof(XIDeviceInfo));
+   buf = Xmalloc(reply.length * 4);
 }
 else
 {
*ndevices_return = 0;
info = NULL;
+   buf = NULL;
 }
 
-if (!info)
+if (!info || !buf)
 goto error;
 
-buf = Xmalloc(reply.length * 4);
 _XRead(dpy, buf, reply.length * 4);
 ptr = buf;
 end = buf + reply.length * 4;
@@ -135,9 +136,9 @@ error_loop:
 Xfree(info[i].name);
 Xfree(info[i].classes);
 }
+error:
 Xfree(info);
 Xfree(buf);
-error:
 UnlockDisplay(dpy);
 error_unlocked:
 SyncHandle();
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libxi 1/2] Plug a memory leak

[Emilio Pozuelo Monfort]

Introduced in commit 19a9cd6.

Reported-by: Julien Cristau 
Signed-off-by: Emilio Pozuelo Monfort 
---
 src/XIQueryDevice.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/XIQueryDevice.c b/src/XIQueryDevice.c
index a457cd6..e3b0c9f 100644
--- a/src/XIQueryDevice.c
+++ b/src/XIQueryDevice.c
@@ -135,6 +135,8 @@ error_loop:
 Xfree(info[i].name);
 Xfree(info[i].classes);
 }
+Xfree(info);
+Xfree(buf);
 error:
 UnlockDisplay(dpy);
 error_unlocked:
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH libx11] Plug a memory leak

[Emilio Pozuelo Monfort]

This was introduced in 8ea762f.

Reported-by: Julien Cristau 
Signed-off-by: Emilio Pozuelo Monfort 
---
 src/FontNames.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/FontNames.c b/src/FontNames.c
index e55f338..3e23b5f 100644
--- a/src/FontNames.c
+++ b/src/FontNames.c
@@ -98,12 +98,14 @@ int *actualCount)   /* RETURN */
*ch = '\0';  /* and replace with null-termination */
count++;
} else {
+Xfree(ch);
 Xfree(flist);
 flist = NULL;
 count = 0;
 break;
}
} else {
+Xfree(ch);
 Xfree(flist);
 flist = NULL;
 count = 0;
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] xwayland: Transform pointer enter event coordinates

[Eric Engestrom]

On Tuesday, 2016-10-25 19:24:49 +0200, Rui Matos wrote:
> Pointer enter event coordinates are surface relative and we need them
> to be screen relative for pScreen->SetCursorPosition().
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=758283
> 
> Signed-off-by: Rui Matos 

LGTM :)
Reviewed-by: Eric Engestrom 

> ---
>  hw/xwayland/xwayland-input.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index f2327dc..1352197 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer 
> *pointer,
>  int i;
>  int sx = wl_fixed_to_int(sx_w);
>  int sy = wl_fixed_to_int(sy_w);
> +int dx, dy;
>  ScreenPtr pScreen = xwl_seat->xwl_screen->screen;
>  ValuatorMask mask;
>  
> @@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer 
> *pointer,
>  xwl_seat->pointer_enter_serial = serial;
>  
>  xwl_seat->focus_window = wl_surface_get_user_data(surface);
> +dx = xwl_seat->focus_window->window->drawable.x;
> +dy = xwl_seat->focus_window->window->drawable.y;
>  
>  master = GetMaster(dev, POINTER_OR_FLOAT);
> -(*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE);
> +(*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE);
>  
>  miPointerInvalidateSprite(master);
>  
> -- 
> 2.9.3
> 
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

[PATCH xserver] xwayland: Transform pointer enter event coordinates

[Rui Matos]

Pointer enter event coordinates are surface relative and we need them
to be screen relative for pScreen->SetCursorPosition().

https://bugzilla.gnome.org/show_bug.cgi?id=758283

Signed-off-by: Rui Matos 
---
 hw/xwayland/xwayland-input.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index f2327dc..1352197 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -298,6 +298,7 @@ pointer_handle_enter(void *data, struct wl_pointer *pointer,
 int i;
 int sx = wl_fixed_to_int(sx_w);
 int sy = wl_fixed_to_int(sy_w);
+int dx, dy;
 ScreenPtr pScreen = xwl_seat->xwl_screen->screen;
 ValuatorMask mask;
 
@@ -314,9 +315,11 @@ pointer_handle_enter(void *data, struct wl_pointer 
*pointer,
 xwl_seat->pointer_enter_serial = serial;
 
 xwl_seat->focus_window = wl_surface_get_user_data(surface);
+dx = xwl_seat->focus_window->window->drawable.x;
+dy = xwl_seat->focus_window->window->drawable.y;
 
 master = GetMaster(dev, POINTER_OR_FLOAT);
-(*pScreen->SetCursorPosition) (dev, pScreen, sx, sy, TRUE);
+(*pScreen->SetCursorPosition) (dev, pScreen, dx + sx, dy + sy, TRUE);
 
 miPointerInvalidateSprite(master);
 
-- 
2.9.3

___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2

[Adam Jackson]

On Tue, 2016-10-25 at 08:50 -0700, Eric Anholt wrote:

> I've said it before a couple of times, but it stands: The next step for
> epoxy is that someone needs to look into YaronCT's fork and decide if we
> should just bless it as the maintained upstream.

Just read through the diff between your branch and Yaron's, it all
looks good to me. Including a epoxy_egl_get_current_gl_context_api fix
that I'd independently written long after the fact.

I'll move my pull requests over.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver] configure.ac: bump epoxy requirement to 1.2

[Eric Anholt]

Adam Jackson  writes:

> On Mon, 2016-10-24 at 12:19 -0700, Matt Turner wrote:
>> On Mon, Oct 24, 2016 at 2:39 AM, Emil Velikov  
>> wrote:
>> > > > From: Emil Velikov 
>> > 
>> > As pointed out in the ABI tracker[1], epoxy has gone through a few
>> > non-backwards compatible ABI changes, yet preserved the DSO name.
>
> I don't particularly object to bumping the required version, but...
>
>> > Most noticeable of which, from xserver POV, in epoxy_has_egl_extension()
>> > - s/EGLDisplay */EGLDisplay/.
>
> This happens not to matter. If you read the corresponding commit you'll
> see that the parameter was always treated as an opaque pointer anyway:
>
> https://github.com/anholt/libepoxy/commit/e20b3ce6c7895f355fd1bad81b45341d98b5ee76
>
>> > Eric, iirc Dave had some ideas about moving libepoxy to fd.o [+ making
>> > it the canonical/upstream source] and was looking for your blessing.
>> > 
>> > How is that going ? The state of the github repo looks tragic.
>> 
>> ajax and anholt were talking about epoxy's status at XDC. Cc'ing ajax.
>
> I'm honestly on anholt's side here about leaving upstream on github.
> fdo is lovely and all but the contribution model for people not already
> in posession of an fdo account is terrible. Moving epoxy to fdo would
> be a step backwards, and we should continue to hold out on that front
> until fdo grows better collaborative hosting.
>
> The more serious issue to me is that epoxy needs a release, and that
> release should involve merging up the various forks on github. (This is
> an argument _in favor_ of github: not only was it easy for people to
> create their forks, but we can track them all down easily.) I'm sure
> epoxy isn't Eric's first priority (which is entirely reasonable) so
> it's kind of up to him how to proceed here.

I've said it before a couple of times, but it stands: The next step for
epoxy is that someone needs to look into YaronCT's fork and decide if we
should just bless it as the maintained upstream.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor()

[Hans de Goede]

Hi,

On 25-10-16 00:25, Alex Goins wrote:

xf86CheckHWCursor() would dereference sPriv without NULL checking it. If Option
"SWCursor" is specified, sPriv == NULL. In this case we should assume that HW
cursors are not supported.

Signed-off-by: Alex Goins 
Reviewed-by: Andy Ritger 


Patch looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 hw/xfree86/ramdac/xf86HWCurs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index da2b181..5e99526 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
xf86CursorInfoPtr infoPtr
 continue;

 sPriv = dixLookupPrivate(>devPrivates, xf86CursorScreenKey);
-if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
+if (!sPriv ||
+!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
 return FALSE;
 }
 return TRUE;


___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] ramdac: Check sPriv != NULL in xf86CheckHWCursor()

[walter harms]

Am 25.10.2016 00:25, schrieb Alex Goins:
> xf86CheckHWCursor() would dereference sPriv without NULL checking it. If 
> Option
> "SWCursor" is specified, sPriv == NULL. In this case we should assume that HW
> cursors are not supported.
> 
> Signed-off-by: Alex Goins 
> Reviewed-by: Andy Ritger 
> ---
>  hw/xfree86/ramdac/xf86HWCurs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
> index da2b181..5e99526 100644
> --- a/hw/xfree86/ramdac/xf86HWCurs.c
> +++ b/hw/xfree86/ramdac/xf86HWCurs.c
> @@ -148,7 +148,8 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
> xf86CursorInfoPtr infoPtr
>  continue;
>  
>  sPriv = dixLookupPrivate(>devPrivates, xf86CursorScreenKey);
> -if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
> +if (!sPriv ||
> +!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
>  return FALSE;
>  }
>  return TRUE;


I would go for 2 lines that will make things more clear also adding a comment 
would help
future debugging operations.

1. if (!sPriv) return FALSE;  /* maybe option "SWCursor" */

2. if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))  /* 
HWCursor not supported */


just my 2 cents,

re,
 wh
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel