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

2016-10-17 Thread 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 
---
 os/inputthread.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/os/inputthread.c b/os/inputthread.c
index 4980502..65247b4 100644
--- a/os/inputthread.c
+++ b/os/inputthread.c
@@ -433,12 +433,6 @@ InputThreadPreInit(void)
 }
 hotplugPipeWrite = hotplugPipe[1];
 
-#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
-
 }
 
 /**
-- 
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

Re: [PATCH:xserver] Use pthread_setname_np to set thread names if available

2016-10-17 Thread Jeremy Sequoia 


Sent from my iPhone...

> On Oct 17, 2016, at 18:48, Alan Coopersmith  
> wrote:
> 
>> On 10/17/16 06:36 PM, Peter Hutterer wrote:
>>> On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote:
>>> I have only tested this on Solaris, not MacOS or Linux, but since the
>>> similar code in glib works on both, hope this will too.
>> 
>> 
>> this broke a few scripts here, e.g. ps -C Xorg won't work anymore because
>> the program name is now MainThread. I understand why we'd want to label the
>> input thread but do we get any benefit out of labelling the main thread?
> 
> Oh, I didn't know it would do that on Linux - Solaris still shows the process
> name for the process, and the thread names only when looking at the threads.

On macOS, this also just changes the name of the thread, not the process.

IMO, it seems wrong that it would have such an effect on Linux.

> I just figured it was handy when libraries spawn their own threads, so we 
> could
> tell the difference between our thread and theirs, but if it's causing 
> problems,
> I don't think it's useful enough to force the issue and am okay seeing the 
> main
> thread name dropped.
> 
> -- 
>-Alan Coopersmith-  alan.coopersm...@oracle.com
> Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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] Use pthread_setname_np to set thread names if available

2016-10-17 Thread Alan Coopersmith 

On 10/17/16 06:36 PM, Peter Hutterer wrote:

On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote:

I have only tested this on Solaris, not MacOS or Linux, but since the
similar code in glib works on both, hope this will too.



this broke a few scripts here, e.g. ps -C Xorg won't work anymore because
the program name is now MainThread. I understand why we'd want to label the
input thread but do we get any benefit out of labelling the main thread?


Oh, I didn't know it would do that on Linux - Solaris still shows the process
name for the process, and the thread names only when looking at the threads.

I just figured it was handy when libraries spawn their own threads, so we could
tell the difference between our thread and theirs, but if it's causing problems,
I don't think it's useful enough to force the issue and am okay seeing the main
thread name dropped.

--
-Alan Coopersmith-  alan.coopersm...@oracle.com
 Oracle Solaris Engineering - http://blogs.oracle.com/alanc
___
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] Swap the registered input device on DEVICE_OFF when needed

2016-10-17 Thread Peter Hutterer 
If we don't swap out the pInfo previously passed to xf86AddEnabledDevice(),
the thread eventually calls read_input on a struct that has been deleted.
Avoid this by swapping out the to-be-destroyed pInfo with the first one we
find.

Reproducer: sudo udevadm trigger --type=devices --action=add

Signed-off-by: Peter Hutterer 
---
Changes to the RFC:
- checking for the driver now

 src/xf86libinput.c | 46 ++
 1 file changed, 46 insertions(+)

diff --git a/src/xf86libinput.c b/src/xf86libinput.c
index 69f7ae3..061e495 100644
--- a/src/xf86libinput.c
+++ b/src/xf86libinput.c
@@ -87,6 +87,7 @@
 struct xf86libinput_driver {
struct libinput *libinput;
int device_enabled_count;
+   void *registered_InputInfoPtr;
 };
 
 static struct xf86libinput_driver driver_context;
@@ -583,6 +584,7 @@ xf86libinput_on(DeviceIntPtr dev)
if (driver_context.device_enabled_count == 0) {
 #if HAVE_THREADED_INPUT
xf86AddEnabledDevice(pInfo);
+   driver_context.registered_InputInfoPtr = pInfo;
 #else
/* Can't use xf86AddEnabledDevice on an epollfd */
AddEnabledDevice(pInfo->fd);
@@ -1131,6 +1133,39 @@ xf86libinput_init(DeviceIntPtr dev)
return 0;
 }
 
+static bool
+is_libinput_device(InputInfoPtr pInfo)
+{
+   char *driver;
+   BOOL rc;
+
+   driver = xf86CheckStrOption(pInfo->options, "driver", "");
+   rc = strcmp(driver, "libinput") == 0;
+   free(driver);
+
+   return rc;
+}
+
+static void
+swap_registered_device(InputInfoPtr pInfo)
+{
+   InputInfoPtr next;
+
+   if (pInfo != driver_context.registered_InputInfoPtr)
+   return;
+
+   next = xf86FirstLocalDevice();
+   while (next == pInfo || !is_libinput_device(next))
+   next = next->next;
+
+   input_lock();
+   xf86RemoveEnabledDevice(pInfo);
+   if (next) /* shouldn't ever be NULL anyway */
+   xf86AddEnabledDevice(next);
+   driver_context.registered_InputInfoPtr = next;
+   input_unlock();
+}
+
 static void
 xf86libinput_destroy(DeviceIntPtr dev)
 {
@@ -1138,6 +1173,17 @@ xf86libinput_destroy(DeviceIntPtr dev)
struct xf86libinput *driver_data = pInfo->private;
struct xf86libinput_device *shared_device = driver_data->shared_device;
 
+   /* If the device being destroyed is the one we used for
+* xf86AddEnabledDevice(), we need to swap it out for one that is
+* still live. xf86AddEnabledDevice() buffers some data and once the
+* deletes pInfo (when DEVICE_OFF completes) the thread will keep
+* calling that struct's read_input because we never removed it.
+* Avoid this by removing ours and substituting one that's still
+* valid, the fd is the same anyway (libinput's epollfd).
+*/
+   if (driver_context.device_enabled_count > 0)
+   swap_registered_device(pInfo);
+
xorg_list_del(_data->shared_device_link);
 
if (driver_data->tablet_tool)
-- 
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

Re: [PATCH:xserver] Use pthread_setname_np to set thread names if available

2016-10-17 Thread Peter Hutterer 
On Sat, Sep 10, 2016 at 09:14:19PM -0700, Alan Coopersmith wrote:
> Autoconf logic borrowed from glib
> 
> Signed-off-by: Alan Coopersmith 
> ---
>  configure.ac| 20 
>  include/dix-config.h.in |  6 ++
>  os/inputthread.c| 12 
>  3 files changed, 38 insertions(+)
> 
> I have only tested this on Solaris, not MacOS or Linux, but since the
> similar code in glib works on both, hope this will too.
 
[...]

> diff --git a/os/inputthread.c b/os/inputthread.c
> index 1cd1c2a..2ea39e7 100644
> --- a/os/inputthread.c
> +++ b/os/inputthread.c
> @@ -310,6 +310,12 @@ InputThreadDoWork(void *arg)
>  
>  inputThreadInfo->running = TRUE;
>  
> +#if defined(HAVE_PTHREAD_SETNAME_NP_WITH_TID)
> +pthread_setname_np (pthread_self(), "InputThread");
> +#elif defined(HAVE_PTHREAD_SETNAME_NP_WITHOUT_TID)
> +pthread_setname_np ("InputThread");
> +#endif
> +
>  ospoll_add(inputThreadInfo->fds, hotplugPipeRead,
> ospoll_trigger_level,
> InputThreadPipeNotify,
> @@ -411,6 +417,12 @@ InputThreadPreInit(void)
>  fcntl(hotplugPipeRead, F_SETFL, O_NONBLOCK | O_CLOEXEC);
>  hotplugPipeWrite = hotplugPipe[1];
>  
> +#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
> +

this broke a few scripts here, e.g. ps -C Xorg won't work anymore because
the program name is now MainThread. I understand why we'd want to label the
input thread but do we get any benefit out of labelling the main thread? 

Cheers,
   Peter
___
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] Compose: add rouble currency

2016-10-17 Thread Mihail Konev 
v2: fix spelling, commit message, and line order.

Sorry for flood.


From ae1bf2fbd2c3893366198a80aed8743af656ee88 Mon Sep 17 00:00:00 2001
From: Victor Kustov 
Date: Mon, 17 Oct 2016 19:44:36 +
Subject: [PATCH 1/2] Compose: add rouble currency sequence

Signed-off-by: Victor Kustov 
Reviewed-by: Mihail Konev 
---
 nls/en_US.UTF-8/Compose.pre | 4 
 1 file changed, 4 insertions(+)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index adc24fb5b5c2..d7dc74140989 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -190,6 +190,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN
 : "€"   EuroSign # EURO SIGN
 : "€"   EuroSign # EURO SIGN
 : "€"   EuroSign # EURO SIGN
+  : "₽"   U20bd # ROUBLE SIGN
+  : "₽"   U20bd # ROUBLE SIGN
+  : "₽"   U20bd # ROUBLE SIGN
+  : "₽"   U20bd # ROUBLE SIGN
 XCOMM "₭" U20ad KIP SIGN
 XCOMM "₮" U20ae TUGRIK SIGN
 XCOMM "₯" U20af DRACHMA SIGN
-- 
2.9.2


From 88e2d4489be56bfb828cf18c56629ef1b9c1f415 Mon Sep 17 00:00:00 2001
From: Mihail Konev 
Date: Mon, 17 Oct 2016 20:17:31 +
Subject: [PATCH 2/2] Compose: cyrillic rouble sequence

Signed-off-by: Mihail Konev 
---
 nls/en_US.UTF-8/Compose.pre | 4 
 1 file changed, 4 insertions(+)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index d7dc74140989..a25d40446162 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -194,6 +194,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN
   : "₽"   U20bd # ROUBLE SIGN
   : "₽"   U20bd # ROUBLE SIGN
   : "₽"   U20bd # ROUBLE SIGN
+: "₽"   U20bd # ROUBLE SIGN
+: "₽"   U20bd # ROUBLE SIGN
+: "₽"   U20bd # ROUBLE SIGN
+: "₽"   U20bd # ROUBLE SIGN
 XCOMM "₭" U20ad KIP SIGN
 XCOMM "₮" U20ae TUGRIK SIGN
 XCOMM "₯" U20af DRACHMA SIGN
-- 
2.9.2

___
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 2/2] Compose: cyrillic ruble sequence

2016-10-17 Thread Mihail Konev 
Signed-off-by: Mihail Konev 
---
 nls/en_US.UTF-8/Compose.pre | 4 
 1 file changed, 4 insertions(+)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index 041ae0f663a0..2c23928a6f2e 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -194,6 +194,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN
   : "₽"   U20bd # RUBLE-CURRENCY SIGN
   : "₽"   U20bd # RUBLE-CURRENCY SIGN
   : "₽"   U20bd # RUBLE-CURRENCY SIGN
+: "₽"   U20bd # RUBLE SIGN
+: "₽"   U20bd # RUBLE SIGN
+: "₽"   U20bd # RUBLE SIGN
+: "₽"   U20bd # RUBLE SIGN
 XCOMM "₭" U20ad KIP SIGN
 XCOMM "₮" U20ae TUGRIK SIGN
 XCOMM "₯" U20af DRACHMA SIGN
-- 
2.9.2

___
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 1/2] Compose: add ruble currency

2016-10-17 Thread Mihail Konev 
From: Victor Kustov 

Signed-off-by: Victor Kustov 
Reviewed-by: Mihail Konev 
---
 nls/en_US.UTF-8/Compose.pre | 4 
 1 file changed, 4 insertions(+)

diff --git a/nls/en_US.UTF-8/Compose.pre b/nls/en_US.UTF-8/Compose.pre
index adc24fb5b5c2..041ae0f663a0 100644
--- a/nls/en_US.UTF-8/Compose.pre
+++ b/nls/en_US.UTF-8/Compose.pre
@@ -190,6 +190,10 @@ XCOMM "₪" U20aa NEW SHEQEL SIGN
 : "€"   EuroSign # EURO SIGN
 : "€"   EuroSign # EURO SIGN
 : "€"   EuroSign # EURO SIGN
+  : "₽"   U20bd # RUBLE-CURRENCY SIGN
+  : "₽"   U20bd # RUBLE-CURRENCY SIGN
+  : "₽"   U20bd # RUBLE-CURRENCY SIGN
+  : "₽"   U20bd # RUBLE-CURRENCY SIGN
 XCOMM "₭" U20ad KIP SIGN
 XCOMM "₮" U20ae TUGRIK SIGN
 XCOMM "₯" U20af DRACHMA SIGN
-- 
2.9.2

___
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] DRI2: Sync radeonsi_pci_ids.h from Mesa

2016-10-17 Thread Alex Deucher 
On Mon, Oct 17, 2016 at 5:48 AM, Michel Dänzer  wrote:
> From: Michel Dänzer 
>
> Fixes DRI2 client driver name mapping for newer AMD GPUs with the
> modesetting driver, allowing the DRI2 extension to initialize.
>
> Signed-off-by: Michel Dänzer 

Reviewed-by: Alex Deucher 

> ---
>  hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
> b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> index 4df8e9d..20c1583 100644
> --- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> +++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
> @@ -184,12 +184,24 @@ CHIPSET(0x7300, FIJI_, FIJI)
>
>  CHIPSET(0x67E0, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E1, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E3, POLARIS11_, POLARIS11)
> +CHIPSET(0x67E7, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E8, POLARIS11_, POLARIS11)
>  CHIPSET(0x67E9, POLARIS11_, POLARIS11)
>  CHIPSET(0x67EB, POLARIS11_, POLARIS11)
> +CHIPSET(0x67EF, POLARIS11_, POLARIS11)
>  CHIPSET(0x67FF, POLARIS11_, POLARIS11)
>
>  CHIPSET(0x67C0, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C1, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C2, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C4, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C7, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C8, POLARIS10_, POLARIS10)
> +CHIPSET(0x67C9, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CA, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CC, POLARIS10_, POLARIS10)
> +CHIPSET(0x67CF, POLARIS10_, POLARIS10)
>  CHIPSET(0x67DF, POLARIS10_, POLARIS10)
>
>  CHIPSET(0x98E4, STONEY_, STONEY)
> --
> 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 xserver] DRI2: Sync radeonsi_pci_ids.h from Mesa

2016-10-17 Thread Michel Dänzer 
From: Michel Dänzer 

Fixes DRI2 client driver name mapping for newer AMD GPUs with the
modesetting driver, allowing the DRI2 extension to initialize.

Signed-off-by: Michel Dänzer 
---
 hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h 
b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
index 4df8e9d..20c1583 100644
--- a/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
+++ b/hw/xfree86/dri2/pci_ids/radeonsi_pci_ids.h
@@ -184,12 +184,24 @@ CHIPSET(0x7300, FIJI_, FIJI)
 
 CHIPSET(0x67E0, POLARIS11_, POLARIS11)
 CHIPSET(0x67E1, POLARIS11_, POLARIS11)
+CHIPSET(0x67E3, POLARIS11_, POLARIS11)
+CHIPSET(0x67E7, POLARIS11_, POLARIS11)
 CHIPSET(0x67E8, POLARIS11_, POLARIS11)
 CHIPSET(0x67E9, POLARIS11_, POLARIS11)
 CHIPSET(0x67EB, POLARIS11_, POLARIS11)
+CHIPSET(0x67EF, POLARIS11_, POLARIS11)
 CHIPSET(0x67FF, POLARIS11_, POLARIS11)
 
 CHIPSET(0x67C0, POLARIS10_, POLARIS10)
+CHIPSET(0x67C1, POLARIS10_, POLARIS10)
+CHIPSET(0x67C2, POLARIS10_, POLARIS10)
+CHIPSET(0x67C4, POLARIS10_, POLARIS10)
+CHIPSET(0x67C7, POLARIS10_, POLARIS10)
+CHIPSET(0x67C8, POLARIS10_, POLARIS10)
+CHIPSET(0x67C9, POLARIS10_, POLARIS10)
+CHIPSET(0x67CA, POLARIS10_, POLARIS10)
+CHIPSET(0x67CC, POLARIS10_, POLARIS10)
+CHIPSET(0x67CF, POLARIS10_, POLARIS10)
 CHIPSET(0x67DF, POLARIS10_, POLARIS10)
 
 CHIPSET(0x98E4, STONEY_, STONEY)
-- 
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 v2 libXi 2/2] XListInputDevices: don't touch ndevices in case of error

2016-10-17 Thread Nicolas Boichat 
+sadrul

On Mon, Oct 17, 2016 at 1:43 PM, Peter Hutterer
 wrote:
> On Fri, Oct 14, 2016 at 02:28:55PM +0100, Emil Velikov wrote:
>> On 13 October 2016 at 04:58, Peter Hutterer  wrote:
>> > We used to always set *ndevices to the number of devices returned by the
>> > server. This magically worked because we pretty much never returned an 
>> > error
>> > except on faulty server or library implementations. With 19a9cd60 we now 
>> > have
>> > more chances of getting an error, so the polite thing is to just leave 
>> > *ndevices
>> > alone when we error out.
>> >
>> > Document it as such in the man page, just in case someone accidentally 
>> > reads
>> > it.
>> >
>> > Signed-off-by: Peter Hutterer 
>> > CC: Niels Ole Salscheider 
>> > ---
>> > Changes to v1:
>> > - Niels' first patch set ndevices to 0, this one leaves it untouched
>> >
>> Slightly split between "doing the right thing" and "the cat is out of
>> the bag" ;-)
>
> I don't think the cat is out of the bag anyway here. ndevices was *always*
> wrong in case of error. either it was untouched or set to the list of
> devices even though NULL was returned. the only reason this worked is
> because we never had an error. the cat remains thus firmly packaged, if (as
> usual) in an unclear state of vividness.
>
>> I'm leaning towards the former, although we might want to prod
>> Chromium devs and/or send them a patch ?
>
> the chromium code is broken, it cannot handle *any* error case. on the first
> call, the devices list is NULL and count is 0. XListInputDevices is
> fails, we currently get a NULL list but a count of != 0. Which
> will then crash when looping through the list and dereferencing the
> nonexistent members. At least with this fix, count stays on 0 and while
> XListInputDevices will get called every time, everything else
> should simply skip over any loop over the devices then (since count remains
> at 0).
>
> anyway, I just tried to file a bug, but "You need a Google Account
> associated with your email address in order to use the bug system." so there
> goes that idea. so now I'm just CC-ing the three most recent @chromium.org
> addresses from xorg-devel and cross my fingers and hope :)

Filed https://bugs.chromium.org/p/chromium/issues/detail?id=656506,
thanks for reporting!

Best,

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