Re: [PATCH xserver v2] inputthread: On Linux leave the main thread's name as-is

2016-10-26 Thread Peter Hutterer
On Wed, Oct 26, 2016 at 12:21:16PM +0200, Hans de Goede wrote:
> From: Peter Hutterer 
> 
> On Linux, setting the main thread's name changes the program name
> (/proc/self/comm). Setting it to MainThread breaks scripts that rely on
> the command name, e.g. ps -C Xorg.
> 
> Signed-off-by: Peter Hutterer 
> Signed-off-by: Hans de Goede 

pushed, thanks.

   007f8ee..5cb3283  master -> master

Cheers,
   Peter

> ---
> Changes in v2 (hdegoede):
> -Only leave the main thread as-is in Linux, naming it is not an issue on
>  other platforms
> ---
>  os/inputthread.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/os/inputthread.c b/os/inputthread.c
> index ddafa7f..8e7f2ed 100644
> --- a/os/inputthread.c
> +++ b/os/inputthread.c
> @@ -431,11 +431,13 @@ InputThreadPreInit(void)
>  }
>  hotplugPipeWrite = hotplugPipe[1];
>  
> +#ifndef __linux__ /* Linux does not deal well with renaming the main thread 
> */
>  #if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID)
>  pthread_setname_np (pthread_self(), "MainThread");
>  #elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID)
>  pthread_setname_np ("MainThread");
>  #endif
> +#endif
>  
>  }
>  
> -- 
> 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] Fix race condition in ConfigureWindow

2016-10-26 Thread Erik Kurzinger

Currently, the ConfigureWindow function will deliver a ConfigureNotify
event to the application before calling into the window's appropriate
function with the new size / position.  Hence, the application may
begin to process the event before some server-size data structures are
updated with the new information leading to a potentially inconsistent
state.

The issue has been causing problems with our OpenGL driver,
specifically when something like the following sequence of events
happens after a window resize:
1. [xserver] send ConfigureNotify event to application
2. [application] call into client-side OpenGL code in response to resize
3. [driver]  read shared memory variable (call it x) indicating 
whether

 current window has been resized, see that it has not,
 proceed without updating client side data structures
4. [xserver] call pScreen->ResizeWindow(...), eventually calling into
 server-side OpenGL code
5. [driver]  update server side data structures, and write to x
 indicating that the window has changed

(2 -> 3) and (4 -> 5) occur asynchronously.  If they run in the order
described above, it can leave the client side and server side driver
components to disagree, causing problems later on.

This change will ensure the new configuration is fully processed by the
server before any event is sent to the application.

Signed-off-by: Erik Kurzinger 
---
 dix/window.c | 50 ++
 1 file changed, 26 insertions(+), 24 deletions(-)

diff --git a/dix/window.c b/dix/window.c
index ead4dc2..7177ae3 100644
--- a/dix/window.c
+++ b/dix/window.c
@@ -2368,6 +2368,32 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID 
*vlist, ClientPtr client)

 return Success;

  ActuallyDoSomething:
+if (mask & CWBorderWidth) {
+if (action == RESTACK_WIN) {
+action = MOVE_WIN;
+pWin->borderWidth = bw;
+}
+else if ((action == MOVE_WIN) &&
+ (beforeX + wBorderWidth(pWin) == x + (int) bw) &&
+ (beforeY + wBorderWidth(pWin) == y + (int) bw)) {
+action = REBORDER_WIN;
+(*pWin->drawable.pScreen->ChangeBorderWidth) (pWin, bw);
+}
+else
+pWin->borderWidth = bw;
+}
+if (action == MOVE_WIN)
+(*pWin->drawable.pScreen->MoveWindow) (pWin, x, y, pSib,
+   (mask & CWBorderWidth) ? 
VTOther

+   : VTMove);
+else if (action == RESIZE_WIN)
+(*pWin->drawable.pScreen->ResizeWindow) (pWin, x, y, w, h, pSib);
+else if (mask & CWStackMode)
+ReflectStackChange(pWin, pSib, VTOther);
+
+if (action != RESTACK_WIN)
+CheckCursorConfinement(pWin);
+
 if (pWin->drawable.pScreen->ConfigNotify) {
 int ret;

@@ -2400,31 +2426,7 @@ ConfigureWindow(WindowPtr pWin, Mask mask, XID 
*vlist, ClientPtr client)

 #endif
 DeliverEvents(pWin, , 1, NullWindow);
 }
-if (mask & CWBorderWidth) {
-if (action == RESTACK_WIN) {
-action = MOVE_WIN;
-pWin->borderWidth = bw;
-}
-else if ((action == MOVE_WIN) &&
- (beforeX + wBorderWidth(pWin) == x + (int) bw) &&
- (beforeY + wBorderWidth(pWin) == y + (int) bw)) {
-action = REBORDER_WIN;
-(*pWin->drawable.pScreen->ChangeBorderWidth) (pWin, bw);
-}
-else
-pWin->borderWidth = bw;
-}
-if (action == MOVE_WIN)
-(*pWin->drawable.pScreen->MoveWindow) (pWin, x, y, pSib,
-   (mask & CWBorderWidth) ? 
VTOther

-   : VTMove);
-else if (action == RESIZE_WIN)
-(*pWin->drawable.pScreen->ResizeWindow) (pWin, x, y, w, h, pSib);
-else if (mask & CWStackMode)
-ReflectStackChange(pWin, pSib, VTOther);

-if (action != RESTACK_WIN)
-CheckCursorConfinement(pWin);
 return Success;
 #undef RESTACK_WIN
 #undef MOVE_WIN
--
2.7.4


___
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 v2] ramdac: Check sPriv != NULL in xf86CheckHWCursor()

2016-10-26 Thread 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 | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/xfree86/ramdac/xf86HWCurs.c b/hw/xfree86/ramdac/xf86HWCurs.c
index da2b181..4481320 100644
--- a/hw/xfree86/ramdac/xf86HWCurs.c
+++ b/hw/xfree86/ramdac/xf86HWCurs.c
@@ -148,6 +148,10 @@ xf86CheckHWCursor(ScreenPtr pScreen, CursorPtr cursor, 
xf86CursorInfoPtr infoPtr
 continue;
 
 sPriv = dixLookupPrivate(>devPrivates, xf86CursorScreenKey);
+if (!sPriv) /* NULL if Option "SWCursor", possibly other conditions */
+return FALSE;
+
+/* FALSE if HWCursor not supported by slave */
 if (!xf86ScreenCheckHWCursor(pSlave, cursor, sPriv->CursorInfoPtr))
 return FALSE;
 }
-- 
1.9.1

___
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: [xserver PULL for 1.19] One more patch on top of Hans' pull request

2016-10-26 Thread Adam Jackson
On Wed, 2016-10-26 at 08:23 -0400, Olivier Fourdan wrote:

>   xwayland: Activate and enable touch devices (2016-10-26 14:16:42 +0200)

Merged:

remote: I: patch #117161 updated using rev 
007f8ee61a35ceda36b43e772a9a1074b8e27a06.
remote: I: 1 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   f68ba7b..007f8ee  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

Re: [xserver PULL for 1.19 ] Various small fixes for 1.19

2016-10-26 Thread Adam Jackson
On Wed, 2016-10-26 at 12:26 +0200, Hans de Goede wrote:
> Hi Adam, Keith,
> 
> Here is a pull-req with various small fixes
> (all with at least 1 Reviewed-by) which I've collected
> for merging into 1.19:
> 
> The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7:
> 
>    ddx: add new call to purge input devices that weren't added (2016-10-26 
> 15:35:07 +1000)
> 
> are available in the git repository at:
> 
>    git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19
> 
> for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f:
> 
>    xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 
> +0200)

Merged:

remote: I: patch #115617 updated using rev 
8fee6a917b6468e1b116d922f86484498874fb5c.
remote: I: patch #114694 updated using rev 
f6ff2e974c5de3071c899eba828789f1d4d8645a.
remote: I: patch #116072 updated using rev 
7d91063aca4e4d326c294e246bc2dc36cb05318e.
remote: I: patch #116414 updated using rev 
4aaeeda4774397dd6d80aa240ca623ae795ec5dc.
remote: I: patch #117406 updated using rev 
f5c6d751d08c6de77c2ca49ba2a48f8023758cef.
remote: I: patch #118152 updated using rev 
f68ba7b81ffe765380664fccc92f3e689c6c48c2.
remote: I: 6 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   d13cb97..f68ba7b  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

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

2016-10-26 Thread Adam Jackson
On Wed, 2016-10-26 at 11:29 +0100, Emil Velikov wrote:

> Maybe coffee hasn't kicked in, but it does seem to matter.

I did not misspeak, I promise.

> Think about: build against pre 1.2 [epoxy] then run against 1.2 or
> later and you'll get some lovely fireworks.

glamor_egl_screen_private::display is an EGLDisplay, so if you build
against pre-1.2 you will get build-time warnings about type mismatches
where we call epoxy_has_egl_extension. But it will work just fine,
because EGLDisplay is a pointer type anyway, and the pre-1.2 version of
that function is:

PUBLIC bool
epoxy_has_egl_extension(EGLDisplay *dpy, const char *ext)
{
return epoxy_extension_in_string(eglQueryString(dpy, EGL_EXTENSIONS), ext);
}

Which is to say: epoxy _also_ had a type mismatch warning here.

- 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

[xserver PULL for 1.19] One more patch on top of Hans' pull request

2016-10-26 Thread Olivier Fourdan
[...]

> Could we add https://patchwork.freedesktop.org/patch/117161/ to this as well?
> 
> It (hopefully) fixes a random crash in Xwayland with touch devices.
> 
> Or else I can prepare another pull request...

The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7:

  ddx: add new call to purge input devices that weren't added (2016-10-26 
15:35:07 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~ofourdan/xserver xwayland

for you to fetch changes up to 8c460a77cac6e403299ec81f60745c3e8fb37c01:

  xwayland: Activate and enable touch devices (2016-10-26 14:16:42 +0200)


Olivier Fourdan (1):
  xwayland: Activate and enable touch devices

 hw/xwayland/xwayland-input.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)
___
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: [xserver PULL for 1.19 ] Various small fixes for 1.19

2016-10-26 Thread Olivier Fourdan
Hi,

- Original Message -
> Hi Adam, Keith,
> 
> Here is a pull-req with various small fixes
> (all with at least 1 Reviewed-by) which I've collected
> for merging into 1.19:
> 
> The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7:
> 
>ddx: add new call to purge input devices that weren't added (2016-10-26
>15:35:07 +1000)
> 
> are available in the git repository at:
> 
>git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19
> 
> for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f:
> 
>xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38
>+0200)
> 
> 
> Hans de Goede (1):
>xfree86: Xorg.wrap: Do not require root rights for cards with 0
>outputs
> 
> Michel Dänzer (1):
>DRI2: Sync radeonsi_pci_ids.h from Mesa
> 
> Mihail Konev (2):
>xwin: make glx optional again
>modesetting: fix glamor ifdef
> 
> Nikhil Mahale (1):
>modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT
> 
> Rui Matos (1):
>xwayland: Transform pointer enter event coordinates
> 
>   configure.ac |  4 ++--
>   hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h   | 12 
>   hw/xfree86/drivers/modesetting/driver.c  |  2 ++
>   hw/xfree86/drivers/modesetting/drmmode_display.c |  2 --
>   hw/xfree86/xorg-wrapper.c|  2 +-
>   hw/xwayland/xwayland-input.c |  5 -
>   6 files changed, 21 insertions(+), 6 deletions(-)


Could we add https://patchwork.freedesktop.org/patch/117161/ to this as well?

It (hopefully) fixes a random crash in Xwayland with touch devices.

Or else I can prepare another pull request...

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

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

2016-10-26 Thread Emil Velikov
On 25 October 2016 at 15:59, Adam Jackson  wrote:
> 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
>
Maybe coffee hasn't kicked in, but it does seem to matter.

Think about: build against pre 1.2 [epoxy] then run against 1.2 or
later and you'll get some lovely fireworks.

>> > 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.
>
Seems like we've dived into [the] unintended direction. The goal is to
see how things start rolling again - would that be fd.o github,
whatever.

Nitpicking pros/cons for each one is a very subjective and never
ending battle that I'd rather not take part of :-)

Thanks
Emil
___
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

[xserver PULL for 1.19 ] Various small fixes for 1.19

2016-10-26 Thread Hans de Goede

Hi Adam, Keith,

Here is a pull-req with various small fixes
(all with at least 1 Reviewed-by) which I've collected
for merging into 1.19:

The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7:

  ddx: add new call to purge input devices that weren't added (2016-10-26 
15:35:07 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~jwrdegoede/xserver for-server-1.19

for you to fetch changes up to 7b135f5e7d79622c0b922de8ee827a2556504d8f:

  xwayland: Transform pointer enter event coordinates (2016-10-26 11:51:38 
+0200)


Hans de Goede (1):
  xfree86: Xorg.wrap: Do not require root rights for cards with 0 outputs

Michel Dänzer (1):
  DRI2: Sync radeonsi_pci_ids.h from Mesa

Mihail Konev (2):
  xwin: make glx optional again
  modesetting: fix glamor ifdef

Nikhil Mahale (1):
  modesetting: unifdef MODESETTING_OUTPUT_SLAVE_SUPPORT

Rui Matos (1):
  xwayland: Transform pointer enter event coordinates

 configure.ac |  4 ++--
 hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h   | 12 
 hw/xfree86/drivers/modesetting/driver.c  |  2 ++
 hw/xfree86/drivers/modesetting/drmmode_display.c |  2 --
 hw/xfree86/xorg-wrapper.c|  2 +-
 hw/xwayland/xwayland-input.c |  5 -
 6 files changed, 21 insertions(+), 6 deletions(-)

Regards,

Hans
___
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 v2] inputthread: On Linux leave the main thread's name as-is

2016-10-26 Thread Hans de Goede
From: Peter Hutterer 

On Linux, setting the main thread's name changes the program name
(/proc/self/comm). Setting it to MainThread breaks scripts that rely on
the command name, e.g. ps -C Xorg.

Signed-off-by: Peter Hutterer 
Signed-off-by: Hans de Goede 
---
Changes in v2 (hdegoede):
-Only leave the main thread as-is in Linux, naming it is not an issue on
 other platforms
---
 os/inputthread.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/os/inputthread.c b/os/inputthread.c
index ddafa7f..8e7f2ed 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -431,11 +431,13 @@ InputThreadPreInit(void)
 }
 hotplugPipeWrite = hotplugPipe[1];
 
+#ifndef __linux__ /* Linux does not deal well with renaming the main thread */
 #if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID)
 pthread_setname_np (pthread_self(), "MainThread");
 #elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID)
 pthread_setname_np ("MainThread");
 #endif
+#endif
 
 }
 
-- 
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 xf86-input-libinput] Don't init the AccelSpeed/LeftHanded properties on the base tablet device

2016-10-26 Thread Eric Engestrom
On Wednesday, 2016-10-26 15:08:23 +1000, Peter Hutterer wrote:
> This device never sends events, no point in exposing these options
> 
> Signed-off-by: Peter Hutterer 

Does what it says on the tin :)
Reviewed-by: Eric Engestrom 

> ---
>  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