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

2016-10-21 Thread Emil Velikov 
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.

Since mesa won't be able (in the foreseeable future) to export the KHR
flavour of extensions (another way one could assume that EGL 1.5 is
available) just drop all the heuristics and use the
EGL_EXT_platform_base extension.

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

Cc: Adam Jackson 
Signed-off-by: Emil Velikov 
---
 glamor/glamor_egl.h | 19 ---
 1 file changed, 8 insertions(+), 11 deletions(-)

diff --git a/glamor/glamor_egl.h b/glamor/glamor_egl.h
index 147aae6..6b05f57 100644
--- a/glamor/glamor_egl.h
+++ b/glamor/glamor_egl.h
@@ -49,23 +49,20 @@
  * have yet. So you have to query for extensions no matter what. Fortunately
  * epoxy_has_egl_extension _does_ let you query for client extensions, so
  * we don't have to write our own extension string parsing.
+ *
+ * 4. There is no EGL_KHR_platform_base to complement the EXT one, thus one
+ * needs to know EGL 1.5 is supported in order to use the eglGetPlatformDisplay
+ * function pointer.
+ * We can workaround this (circular dependency) by probing for the EGL 1.5
+ * platform extensions (EGL_KHR_platform_gbm and friends) yet it doesn't seem
+ * like mesa will be able to adverise these (even though it can do EGL 1.5).
  */
 static inline EGLDisplay
 glamor_egl_get_display(EGLint type, void *native)
 {
 EGLDisplay dpy = NULL;
 
-/* If we're EGL 1.5, the KHR extension will be there, try that */
-if (epoxy_has_egl_extension(NULL, "EGL_KHR_platform_base")) {
-PFNEGLGETPLATFORMDISPLAYPROC getPlatformDisplay =
-(void *) eglGetProcAddress("eglGetPlatformDisplay");
-if (getPlatformDisplay)
-dpy = getPlatformDisplay(type, native, NULL);
-if (dpy)
-return dpy;
-}
-
-/* Okay, maybe the EXT extension works */
+/* In practise any EGL 1.5 implementation would support the EXT extension 
*/
 if (epoxy_has_egl_extension(NULL, "EGL_EXT_platform_base")) {
 PFNEGLGETPLATFORMDISPLAYEXTPROC getPlatformDisplayEXT =
 (void *) eglGetProcAddress("eglGetPlatformDisplayEXT");
-- 
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 rendercheck] Report results on a per-test basis

2016-10-21 Thread Eric Anholt 
Martin Peres  writes:

> This allows a runner such as EzBench to track each test individually
> and not limit the resolution to groups.
>
> This feature can be triggered by using the -r parameter.

I don't really see the point of this -- you need an external runner to
be choosing a specific test subset to run per rendercheck call, since
the full matrix of composite tests is too long.  Once you have an
external runner calling rendercheck per test group, all you would be
able to do using this patch would be save a few spawns of the process,
which doesn't seem worth it.


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: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

2016-10-21 Thread Olivier Fourdan 
Hi,

> Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace
> related to an InitFonts -> SendErrorToClient -> FlushAllOutput
> call chain.
> 
> Since there is no trivial reproducer this is somewhat hard to debug,
> hence this mail. Anyone have a clue / hint ?  See:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1382444

Actually, I think we cannot really trust the symbols from Xorg's own generated 
backtrace, however, looking at the addresses, the sequence makes some more 
sense:

  FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612
  Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491
  dix_main() in /usr/src/debug/xorg-server-20160929/dix/main.c:296

with /usr/src/debug/xorg-server-20160929/os/io.c:612 

 612 xorg_list_for_each_entry_safe(client, tmp, _pending_clients, 
output_pending) {
 613 if (client->clientGone)
 614 continue;
 615 if (!client_is_ready(client)) {
 616 oc = (OsCommPtr) client->osPrivate;
 617 (void) FlushClient(client, oc, (char *) NULL, 0);
 618 } else
 619 NewOutputPending = TRUE;
 620 }

So it could be that output_pending_clients list got corrupted somehow.

Not sure I can go much further than that with so little data, but if that rings 
a bell with someone else...

Cheers,
Olivier
___
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] xfree86: Choose the largest output as primary for xf86TargetFallback()

2016-10-21 Thread Chris Wilson 
With all things equal (i.e. same output preferences), use the largest
output as the primary. From the primary, we choose compatible modes for
the others, and given that we are configuring an extended desktop, we
have greater freedom in our selection and may as well base our choice on
the largest mode available.

Signed-off-by: Chris Wilson 
---
 hw/xfree86/modes/xf86Crtc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/hw/xfree86/modes/xf86Crtc.c b/hw/xfree86/modes/xf86Crtc.c
index 966a168..048c3b2 100644
--- a/hw/xfree86/modes/xf86Crtc.c
+++ b/hw/xfree86/modes/xf86Crtc.c
@@ -2413,7 +2413,10 @@ xf86TargetFallback(ScrnInfoPtr scrn, xf86CrtcConfigPtr 
config,
 default_preferred = (((default_mode->type & M_T_PREFERRED) != 0) +
  ((default_mode->type & M_T_USERPREF) != 0));
 
-if (default_preferred > target_preferred || !target_mode) {
+if (!target_mode ||
+default_preferred > target_preferred ||
+(default_preferred == target_preferred &&
+ biggestMode(default_mode, target_mode))) {
 target_mode = default_mode;
 target_preferred = default_preferred;
 target_rotation = config->output[o]->initial_rotation;
-- 
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: Activate and enable touch devices

2016-10-21 Thread Hans de Goede 

HI,

On 21-10-16 10:11, Olivier Fourdan wrote:

On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().

The (simplified) backtrace goes as follow:

 (gdb) bt
 #0  GetTouchEvents() at getevents.c:1892
 #1  QueueTouchEvents() at getevents.c:1866
 #2  xwl_touch_send_event() at xwayland-input.c:652
 #5  wl_closure_invoke() from libwayland-client.so.0
 #6  dispatch_event() from libwayland-client.so.0
 #7  wl_display_dispatch_queue_pending() from libwayland-client.so.0
 #8  xwl_read_events() at xwayland.c:483
 #9  ospoll_wait() at ospoll.c:412
 #10 WaitForSomething() at WaitFor.c:222
 #11 Dispatch() at dispatch.c:412
 #12 dix_main() at main.c:287
 #13 __libc_start_main() at libc-start.c:289
 #14 _start ()

The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.

Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.

Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.

Signed-off-by: Olivier Fourdan 


Patch LGTM:

Reviewed-by: Hans de Goede 

Regards,

Hans





---
 hw/xwayland/xwayland-input.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 4d447a5..9a7123a 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -1056,12 +1056,13 @@ init_touch(struct xwl_seat *xwl_seat)
 wl_touch_add_listener(xwl_seat->wl_touch,
   _listener, xwl_seat);

-if (xwl_seat->touch)
-EnableDevice(xwl_seat->touch, TRUE);
-else {
+if (xwl_seat->touch == NULL) {
 xwl_seat->touch =
 add_device(xwl_seat, "xwayland-touch", xwl_touch_proc);
+ActivateDevice(xwl_seat->touch, TRUE);
 }
+EnableDevice(xwl_seat->touch, TRUE);
+
 }

 static void


___
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 evdev] Fix off-by-one error counting axes

2016-10-21 Thread Hans de Goede 

Hi,

On 21-10-16 01:55, Peter Hutterer wrote:

We stopped counting one too early, but still initialized that axis later,
leading to a bug macro to trigger.

https://bugs.freedesktop.org/show_bug.cgi?id=97956

Signed-off-by: Peter Hutterer 


LGTM:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
 src/evdev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index 5ace238..96fd97d 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1238,7 +1238,7 @@ EvdevCountMTAxes(EvdevPtr pEvdev, int *num_mt_axes_total,
 return;

 /* Absolute multitouch axes: adjust mapping and axes counts. */
-for (axis = ABS_MT_SLOT; axis < ABS_MAX; axis++)
+for (axis = ABS_MT_SLOT; axis <= ABS_MAX; axis++)
 {
 int j;
 Bool skip = FALSE;
@@ -1288,7 +1288,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int 
num_scroll_axes)
 goto out;

 /* Find number of absolute axis, including MT ones, will decrease later. */
-for (i = 0; i < ABS_MAX; i++)
+for (i = 0; i <= ABS_MAX; i++)
 if (libevdev_has_event_code(pEvdev->dev, EV_ABS, i))
 num_axes++;

@@ -1456,7 +1456,7 @@ EvdevAddAbsValuatorClass(DeviceIntPtr device, int 
num_scroll_axes)
 }

 for (i = 0; i < num_touches; i++) {
-for (axis = ABS_MT_TOUCH_MAJOR; axis < ABS_MAX; axis++) {
+for (axis = ABS_MT_TOUCH_MAJOR; axis <= ABS_MAX; axis++) {
 if (pEvdev->abs_axis_map[axis] >= 0) {
 int val = pEvdev->mtdev ? 0 : 
libevdev_get_current_slot(pEvdev->dev);
 /* XXX: read initial values from mtdev when it adds support
@@ -1669,7 +1669,7 @@ EvdevAddRelValuatorClass(DeviceIntPtr device, int 
num_scroll_axes)
 if (!libevdev_has_event_type(pEvdev->dev, EV_REL))
 goto out;

-for (i = 0; i < REL_MAX; i++) {
+for (i = 0; i <= REL_MAX; i++) {
 if (i == REL_WHEEL || i == REL_HWHEEL || i == REL_DIAL)
 continue;



___
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 3/3] ddx: add new call to purge input devices that weren't added

2016-10-21 Thread Hans de Goede 

Hi,

On 20-10-16 23:50, Peter Hutterer wrote:

Special case for the systemd-logind case in xfree86: when we're vt-switched
away and a device is plugged in, we get a paused fd from logind. Since we
can't probe the device or do anything with it, we store that device in the
xfree86 and handle it later when we vt-switch back. The device is not added to
inputInfo.devices until that time.

When the device is removed while still vt-switched away, the the config system
never notifies the DDX. It only runs through inputInfo.devices and our device
was never added to that.

When a device is plugged in, removed, and plugged in again while vt-switched
away, we have two entries in the xfree86-specific list that refer to the same
device node, both pending for addition later. On VT switch back, the first one
(the already removed one) will be added successfully, the second one (the
still plugged-in one) fails. Since the fd is correct, the device works until
it is removed again. The removed devices' config_info (i.e. the syspath)
doesn't match the actual device we addded tough (the input number increases
with each plug), it doesn't get removed, the fd remains open and we lose track
of the fd count. Plugging the device in again leads to a dead device.

Fix this by adding a call to notify the DDX to purge any remainders of devices
with the given config_info, that's the only identifiable bit we have at this
point.

https://bugs.freedesktop.org/show_bug.cgi?id=97928

Signed-off-by: Peter Hutterer 
---
 Xi/stubs.c | 14 ++
 config/config.c|  2 ++
 hw/dmx/dmxinput.c  |  5 +
 hw/kdrive/src/kinput.c |  5 +
 hw/xfree86/common/xf86Xinput.c | 19 +++
 hw/xquartz/darwinXinput.c  | 15 +++
 include/input.h|  1 +
 7 files changed, 61 insertions(+)

diff --git a/Xi/stubs.c b/Xi/stubs.c
index 39bee7c..27848a2 100644
--- a/Xi/stubs.c
+++ b/Xi/stubs.c
@@ -143,3 +143,17 @@ DeleteInputDeviceRequest(DeviceIntPtr dev)
 {
 RemoveDevice(dev, TRUE);
 }
+
+/
+ *
+ * Caller: configRemoveDevice (and others)
+ *
+ * Remove any traces of the input device specified in config_info.
+ * This is only necessary if the ddx keeps information around beyond
+ * the NewInputDeviceRequest/DeleteInputDeviceRequest
+ *
+ */
+void
+RemoveInputDeviceTraces(const char *config_info)
+{
+}
diff --git a/config/config.c b/config/config.c
index 1fb368c..fb60295 100644
--- a/config/config.c
+++ b/config/config.c
@@ -107,6 +107,8 @@ remove_devices(const char *backend, const char *config_info)
 if (dev->config_info && strcmp(dev->config_info, config_info) == 0)
 remove_device(backend, dev);
 }
+
+RemoveInputDeviceTraces(config_info);
 }

 BOOL
diff --git a/hw/dmx/dmxinput.c b/hw/dmx/dmxinput.c
index 4ccb439..d201034 100644
--- a/hw/dmx/dmxinput.c
+++ b/hw/dmx/dmxinput.c
@@ -123,3 +123,8 @@ void
 DeleteInputDeviceRequest(DeviceIntPtr pDev)
 {
 }
+
+void
+RemoveInputDeviceTraces(const char *config_info)
+{
+}
diff --git a/hw/kdrive/src/kinput.c b/hw/kdrive/src/kinput.c
index 2c39624..8b08747 100644
--- a/hw/kdrive/src/kinput.c
+++ b/hw/kdrive/src/kinput.c
@@ -2302,3 +2302,8 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev)
 {
 RemoveDevice(pDev, TRUE);
 }
+
+void
+RemoveInputDeviceTraces(const char *config_info)
+{
+}
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 0095272..d673711 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -1119,6 +1119,25 @@ DeleteInputDeviceRequest(DeviceIntPtr pDev)
 input_unlock();
 }

+void
+RemoveInputDeviceTraces(const char *config_info)
+{
+PausedInputDevicePtr d, tmp;
+
+if (new_input_devices_list.next == NULL &&
+new_input_devices_list.prev == NULL)
+xorg_list_init(_input_devices_list);


This bit is unnecessary, as you already initialize
new_input_devices_list when you declare it at the top of the file.

With these 3 lines dropped the entire series looks good to me and is:

Reviewed-by: Hans de Goede 

Regards,

Hans




+
+xorg_list_for_each_entry_safe(d, tmp, _input_devices_list, node) {
+const char *ci = xf86findOptionValue(d->pInfo->options, "config_info");
+if (!ci || strcmp(ci, config_info) != 0)
+continue;
+
+xorg_list_del(>node);
+free(d);
+}
+}
+
 /*
  * convenient functions to post events
  */
diff --git a/hw/xquartz/darwinXinput.c b/hw/xquartz/darwinXinput.c
index 3efaa2c..fea7e92 100644
--- a/hw/xquartz/darwinXinput.c
+++ b/hw/xquartz/darwinXinput.c
@@ -147,3 +147,18 @@ DeleteInputDeviceRequest(DeviceIntPtr dev)
 {
 DEBUG_LOG("DeleteInputDeviceRequest(%p)\n", dev);
 }
+
+/
+ *
+ * Caller: configRemoveDevice (and others)
+ *
+ *

[PATCH xserver] xwayland: Activate and enable touch devices

2016-10-21 Thread Olivier Fourdan 
On some random condition, a touch event may trigger a crash in Xwayland
in GetTouchEvents().

The (simplified) backtrace goes as follow:

 (gdb) bt
 #0  GetTouchEvents() at getevents.c:1892
 #1  QueueTouchEvents() at getevents.c:1866
 #2  xwl_touch_send_event() at xwayland-input.c:652
 #5  wl_closure_invoke() from libwayland-client.so.0
 #6  dispatch_event() from libwayland-client.so.0
 #7  wl_display_dispatch_queue_pending() from libwayland-client.so.0
 #8  xwl_read_events() at xwayland.c:483
 #9  ospoll_wait() at ospoll.c:412
 #10 WaitForSomething() at WaitFor.c:222
 #11 Dispatch() at dispatch.c:412
 #12 dix_main() at main.c:287
 #13 __libc_start_main() at libc-start.c:289
 #14 _start ()

The crash occurs when trying to access the sprite associated with the
touch device, which appears to be NULL. Reason being the device itself
is more a keyboard device than a touch device.

Moreover, it appears the device is neither enabled nor activated
(inited=0, enabled=0) which doesn't seem right, but matches the code in
init_touch() from xwayland-input.c which would enable the device if it
was previously existing and otherwise would create the device but not
activate it.

Make sure we do activate and enable touch devices just like we do for
other input devices such as keyboard and pointer.

Signed-off-by: Olivier Fourdan 
---
 hw/xwayland/xwayland-input.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 4d447a5..9a7123a 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -1056,12 +1056,13 @@ init_touch(struct xwl_seat *xwl_seat)
 wl_touch_add_listener(xwl_seat->wl_touch,
   _listener, xwl_seat);
 
-if (xwl_seat->touch)
-EnableDevice(xwl_seat->touch, TRUE);
-else {
+if (xwl_seat->touch == NULL) {
 xwl_seat->touch =
 add_device(xwl_seat, "xwayland-touch", xwl_touch_proc);
+ActivateDevice(xwl_seat->touch, TRUE);
 }
+EnableDevice(xwl_seat->touch, TRUE);
+
 }
 
 static void
-- 
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