Re: Two-finger width setting on Dell XPS 15 9650

[Peter Hutterer]

On Tue, Jun 20, 2017 at 05:07:44AM +, Vahe Oughourlian wrote:
> On Mon, Jun 19, 2017 at 5:58 PM Peter Hutterer 
> wrote:
> 
> > On Fri, Jun 16, 2017 at 05:48:31PM +, Vahe Oughourlian wrote:
> > > On Thu, Jun 15, 2017 at 3:23 PM Peter Hutterer  > >
> > > wrote:
> > >
> > > > On Tue, Jun 13, 2017 at 01:46:12AM +, Vahe Oughourlian wrote:
> > > > > I'm working with a Dell XPS 15 9650 using libinput. Using the
> > Synaptics
> > > > > driver, a property is available to set the maximum distance two
> > fingers
> > > > may
> > > > > be apart before a two-finger scroll can be triggered, called
> > "Synaptics
> > > > > Two-Finger Width." At the moment, two fingers anywhere on the
> > touchpad
> > > > will
> > > > > switch it over to a two-finger scroll.
> > > > >
> > > > > I ran across a post from Peter Hutterer (
> > > > >
> > > >
> > https://who-t.blogspot.de/2016/04/why-libinput-doesnt-have-lot-of-config.html
> > > > )
> > > > > discussing the intention to minimize options in libinput, and there
> > > > doesn't
> > > > > seem to be a setting that affects this behavior that I could find.
> > Given
> > > > > that, is the most appropriate thing to file a bug for this particular
> > > > > trackpad to have a reasonable default added for this device, or is
> > this a
> > > > > setting libinput eventually intends to support? Or is this setting
> > > > already
> > > > > available?
> > > >
> > > > it's not an available configuration, no. But the main question is what
> > > > you're actually trying to achive? I'm assuming that any finger distance
> > > > limits are not the issue per se but that there's something else that
> > > > affects
> > > > how you can interact.
> > > >
> > > > Cheers,
> > > >Peter
> > > >
> > > >
> > > There are a couple common cases:
> > >
> > > 1. My left thumb may drift onto the upper left corner of the touchpad (in
> > > the usual home-row typing position) while my right hand is controlling
> > the
> > > touchpad. Despite the 70mm-ish distance between the fingers, the next
> > > cursor motion by the right hand is treated as a two-finger scroll.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=99703
> >
> > > 2. I often use the physical click as part of a drag-and-highlight. While
> > > there are dead zones at the bottom of the mouse for the virtual buttons,
> > if
> > > my thumb isn't quite low enough on the right hand, the moment before
> > > actually clicking the physical button underneath the trackpad will turn
> > > into a two-finger scroll. This also can occur at the end of the click as
> > > I'm lifting the thumb, and the next motion is a scroll.
> >
> > not quite the same but similar to the bug above. I think that's something
> > we'd have to revisit once we manage to get a hand on 99703
> >
> 
> Sure, I'll keep an eye on 99703 and give it a shot when it comes out.

I've just attached a branch for testing to that bug, please give it a shot,
we can revisit the other questions once we get that one sorted

Cheers,
   Peter

> > > My intention was to set the distance between two fingers such that they'd
> > > have to be much closer together (within 20mm, for example) to avoid these
> > > accidental scroll events.
> >
> > tbh, I don't think that's the right solution and that's also why there's no
> > config option for it. Any distance-based guessing of intentions should
> > always be internal to libinput because once we expose the option we'll have
> > to keep it around forever. And exposing an option promises behaviour.
> >
> 
> Completely agree. Mostly this is me working backwards from an existing
> option in the old version to find a possible solution.
> 
> 
> >
> > I think fixing 99703 will remove most of your issues.
> >
> 
> I'm not sure in this case. While it looks like 99703 will solve the case
> mid-movement, it doesn't really address the cases at the start of the
> movement when two fingers are on the pad.
> 
> 
> >
> > > One thing I have also noticed on other trackpads (on other OSes,
> > > admittedly) is that both fingers seem to have to be in motion to trigger
> > a
> > > two finger scroll, whereas I seem to be able to trigger a two-finger
> > scroll
> > > on the Dell's trackpad by moving one finger while two fingers are on the
> > > trackpad at a time. Perhaps that's the solution here?
> >
> > yeah, that's been a long-standing feature of the 2fg scroll on linux. not
> > sure we can/should get rid of that.
> >
> 
> I'm entirely sympathetic to your perspective here about changing existing
> and expected behavior, and no doubt you'd hear from a cadre of unhappy
> users if the behavior were to change. However, I'd like to push back here.
> I think two fingers moving gives significantly more intention to the
> gesture, and as I'm seeing in my experience, it's happening enough
> unintentionally to me to raise the question. I don't think it makes sense
> from a user perspective to have any two touch points anywhere 

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Tue, Jun 20, 2017 at 06:54:34PM +0100, David Edmundson wrote:
> You missed a line in "xdg-shell/positioner: Allow empty anchor_rect"
> You might want to squash this with that.

> From 0a21378302d63a83a10723b41adf35e605fb35f5 Mon Sep 17 00:00:00 2001
> From: David Edmundson 
> Date: Tue, 20 Jun 2017 18:29:59 +0100
> Subject: [PATCH 1/2] Fix xdg-shell/positioner: Allow empty anchor_rect
> 
> ---
>  stable/xdg-shell/xdg-shell.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index 2e845fa..ffba86d 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -165,7 +165,7 @@
>   Specify the anchor rectangle within the parent surface that the child
>   surface will be placed relative to. The rectangle is relative to the
>   window geometry as defined by xdg_surface.set_window_geometry of the
> - parent surface. The rectangle must be at least 1x1 large.
> + parent surface.

Thanks, i'll squash this the commit that missed this change.


Jonas

>  
>   When the xdg_positioner object is used to position a child surface, the
>   anchor rectangle may not extend outside the window geometry of the
> -- 
> 2.12.0
> 

> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Tue, Jun 20, 2017 at 06:55:41PM +0100, David Edmundson wrote:
> ​

> From 093ed1a17a483792e316f932e15a566ab2653838 Mon Sep 17 00:00:00 2001
> From: David Edmundson 
> Date: Tue, 20 Jun 2017 18:51:45 +0100
> Subject: [PATCH 2/2] xdg-shell/positioner: Replace edge bitfield with extended
>  enum
> 
> Bitfields allowed for impossible combinations of anchor edges, such as
> being on the left and right edge. Use of explicit enumerations means we
> don't need to handle that case.

Although it is not a requirement, we usually add Signed-off-by here. Do
you want to add it?

> ---
>  stable/xdg-shell/xdg-shell.xml | 71 
> ++
>  1 file changed, 30 insertions(+), 41 deletions(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index ffba86d..020af9e 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -179,63 +179,52 @@
>
>  
>  
> -
> -   -  summary="the center of the anchor rectangle"/>
> -   -  summary="the top edge of the anchor rectangle"/>
> -   -  summary="the bottom edge of the anchor rectangle"/>
> -   -  summary="the left edge of the anchor rectangle"/>
> -   -  summary="the right edge of the anchor rectangle"/>
> +

nit: extra newline

> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
>  
>  
>  
>
>   Defines a set of edges for the anchor rectangle. These are used to
>   derive an anchor point that the child surface will be positioned
> - relative to. If two orthogonal edges are specified (e.g. 'top' and
> - 'left'), then the anchor point will be the intersection of the edges
> - (e.g. the top left position of the rectangle); otherwise, the derived
> - anchor point will be centered on the specified edge, or in the center of
> - the anchor rectangle if no edge is specified.
> -
> - If two parallel anchor edges are specified (e.g. 'left' and 'right'),
> - the invalid_input error is raised.
> + relative to. The anchor point will be in the specified corner, in the 
> center
> +of a specified edge, or in the center of the anchor rectangle if no edge
> +is specified.

We don't define a set of "edges" anymore, so I suggest changing that
too. We still derive the resulting point however, so we should still
include that.

I suggest this wording, which tries to minimize the change:

Defines the anchor point for the anchor rectangle. The are used
to derive an anchor point that the child surface will be
positioned relative to. If a corner anchor is set (e.g.
'top_left' or 'bottom_right'), the anchor point will be at the
specified corner; otherwise, the derived anchor point will be
centered on the specified edge, or in the center of the anchor
rectangle if no edge is specified.


>
> -summary="bit mask of anchor edges"/>
> +summary="anchor edge"/>

Not really an 'edge' anymore either, so maybe just "anchor" is better
here.

>  
>  
> -
> -   -  summary="center over the anchor edge"/>
> -   -  summary="position above the anchor edge"/>
> -   -  summary="position below the anchor edge"/>
> -   -  summary="position to the left of the anchor edge"/>
> -   -  summary="position to the right of the anchor edge"/>
> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
>  
>  
>  
>
> - Defines in what direction a surface should be positioned, relative to
> - the anchor point of the parent surface. If two orthogonal gravities are
> - specified (e.g. 'bottom' and 'right'), then the child surface will be
> - placed in the specified direction; otherwise, the child surface will be
> - centered over the anchor point on any axis that had no gravity
> - specified.
> -
> - If two parallel gravities are specified (e.g. 'left' and 'right'), the
> - invalid_input error is raised.
> + Defines which edge of the surface should be positioned relative to
> + the anchor of the parent surface. The anchor point will be in the 
> specified corner,
> +in the center of a specified edge, or in the center of the anchor 
> rectangle if no edge
> +is specified.

I suggest continuing talking about "direction" here. An alternative to
the above could be, changing the original text just a bit:

Defines in what direction a surface should be positioned,
relative to the anchor point of the parent surface. If a corner
gravity is specified (e.g. 'bottom_right' or 'top_left'), then
the child surface will be placed in the specified direction;
otherwise, the child surface will be centered over the anchor
point on any axis that had no 

[PATCH libinput] meson: restore the SELinux context for our .so file on install

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
A temporary workaround until the meson bit is fixed.

 meson.build |  6 ++
 src/Makefile.am |  2 +-
 src/libinput-restore-selinux-context.sh | 10 ++
 3 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 src/libinput-restore-selinux-context.sh

diff --git a/meson.build b/meson.build
index 217bf82a..e77f7d13 100644
--- a/meson.build
+++ b/meson.build
@@ -220,6 +220,12 @@ pkgconfig.generate(
libraries: lib_libinput
 )
 
+# Restore the SELinux context for the libinput.so.a.b.c on install
+# meson bug https://github.com/mesonbuild/meson/issues/1967
+meson.add_install_script('src/libinput-restore-selinux-context.sh',
+get_option('libdir'),
+lib_libinput.full_path())
+
  documentation 
 
 if get_option('documentation')
diff --git a/src/Makefile.am b/src/Makefile.am
index 08e6aa1e..6723d5ae 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -77,4 +77,4 @@ pkgconfig_DATA = libinput.pc
 AM_CFLAGS = $(GCC_CFLAGS)
 
 DISTCLEANFILES = libinput-version.h
-EXTRA_DIST = libinput-version.h.in libinput.sym
+EXTRA_DIST = libinput-version.h.in libinput.sym 
libinput-restore-selinux-context.sh
diff --git a/src/libinput-restore-selinux-context.sh 
b/src/libinput-restore-selinux-context.sh
new file mode 100644
index ..7fd8fad0
--- /dev/null
+++ b/src/libinput-restore-selinux-context.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+#
+# $1: abs path to libdir
+# $2: abs path to .so file
+
+libdir="$1"
+sofile=$(basename "$2")
+
+echo "Restoring SELinux context on 
$MESON_INSTALL_DESTDIR_PREFIX/$libdir/$sofile"
+restorecon "$MESON_INSTALL_DESTDIR_PREFIX/$libdir/$sofile"
-- 
2.13.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] doc: update build instructions for Arch

[Peter Hutterer]

On Tue, Jun 20, 2017 at 02:06:08PM +0100, Eric Engestrom wrote:
> `abs` has been deprecated, and shut down last month. [1]
> `asp` replaces it, so rewrite the instructions to use this instead.
> 
> Also, add `--noextract` to the makepkg command, as there is no point
> downloading and extracting the sources since they're not going to be
> built here.
> 
> [1] https://www.archlinux.org/news/deprecation-of-abs/
> 
> Signed-off-by: Eric Engestrom 

thanks, pushed

Cheers,
   Peter
> ---
>  doc/building.dox | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/building.dox b/doc/building.dox
> index 5ce2146..355c535 100644
> --- a/doc/building.dox
> +++ b/doc/building.dox
> @@ -124,10 +124,11 @@ $> sudo zypper modifyrepo --disable `zypper repos | 
> grep source | awk '{print $5
>  
>  Arch:
>  
> -$> abs extra/libinput
> +$> sudo pacman -S asp
>  $> cd $(mktemp -d)
> +$> asp export libinput
> -$> cp /var/abs/extra/libinput/PKGBUILD .
> +$> cd libinput
> -$> makepkg --syncdeps --nobuild
> +$> makepkg --syncdeps --nobuild --noextract
>  
>  
>  
> -- 
> Cheers,
>   Eric
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] doc: add instructions for handling SELinux denials

[Peter Hutterer]

On Tue, Jun 20, 2017 at 01:41:50PM +0100, Eric Engestrom wrote:
> On Tuesday, 2017-06-20 12:45:15 +1000, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer 
> > ---
> >  doc/building.dox | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/doc/building.dox b/doc/building.dox
> > index 5ce21463..25594da8 100644
> > --- a/doc/building.dox
> > +++ b/doc/building.dox
> > @@ -102,6 +102,33 @@ overwriting manually installed files.
> >  Arch: ```sudo packman -S libinput```
> >  
> >  
> > +@subsection building_selinux SELinux adjustments
> > +
> > +On systems with SELinux, overwriting the distribution-provided package with
> > +a manually built libinput may cause SELinux denials. This usually manifests
> > +when gdm does not start because it is denied access to libinput. The 
> > journal
> > +shows a log message in the form of:
> > +
> > +
> > +May 25 15:28:42 localhost.localdomain audit[23268]: AVC avc:  denied  { 
> > execute } for  pid=23268 comm="gnome-shell" 
> > path="/usr/lib64/libinput.so.10.12.2" dev="dm-0" ino=1709093 
> > scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 
> > tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
> > +May 25 15:28:42 localhost.localdomain org.gnome.Shell.desktop[23270]: 
> > /usr/bin/gnome-shell: error while loading shared libraries: libinput.so.10: 
> > failed to map segment from shared object
> > +
> > +
> > +The summary of this error message is that gdm's gnome-shell runs in the
> > +```system_u:system_r:xdm_t``` context but libinput is installed with the
> > +context ```unconfined_u:object_r:user_home_t```.
> > +
> > +To avoid this issue, restore the SELinux context for any system files.
> > +
> > +
> > +$> sudo restorecon /usr/lib/libinput.so.*
> > +$> sudo restorecon /usr/lib64/libinput.so.*
> > +
> > +
> > +Pick whichever one is your libdir.
> 
> You don't need this note if you give that command instead :)
> 
> $> sudo restorecon /usr/lib*/libinput.so.*

good point, fixed locally, thanks for the review!

Cheers,
   Peter

> 
> Reviewed-by: Eric Engestrom 
> 
> > +
> > +This issue is tracked in https://github.com/mesonbuild/meson/issues/1967.
> > +
> >  @subsection building_dependencies Build dependencies
> >  
> >  libinput has a few build-time dependencies that must be installed prior to
> > -- 
> > 2.13.0
> > 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[David Edmundson]

​
From 093ed1a17a483792e316f932e15a566ab2653838 Mon Sep 17 00:00:00 2001
From: David Edmundson 
Date: Tue, 20 Jun 2017 18:51:45 +0100
Subject: [PATCH 2/2] xdg-shell/positioner: Replace edge bitfield with extended
 enum

Bitfields allowed for impossible combinations of anchor edges, such as
being on the left and right edge. Use of explicit enumerations means we
don't need to handle that case.
---
 stable/xdg-shell/xdg-shell.xml | 71 ++
 1 file changed, 30 insertions(+), 41 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index ffba86d..020af9e 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -179,63 +179,52 @@
   
 
 
-
-  
-  
-  
-  
-  
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
 
 
 
   
 	Defines a set of edges for the anchor rectangle. These are used to
 	derive an anchor point that the child surface will be positioned
-	relative to. If two orthogonal edges are specified (e.g. 'top' and
-	'left'), then the anchor point will be the intersection of the edges
-	(e.g. the top left position of the rectangle); otherwise, the derived
-	anchor point will be centered on the specified edge, or in the center of
-	the anchor rectangle if no edge is specified.
-
-	If two parallel anchor edges are specified (e.g. 'left' and 'right'),
-	the invalid_input error is raised.
+	relative to. The anchor point will be in the specified corner, in the center
+of a specified edge, or in the center of the anchor rectangle if no edge
+is specified.
   
   
+	   summary="anchor edge"/>
 
 
-
-  
-  
-  
-  
-  
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
 
 
 
   
-	Defines in what direction a surface should be positioned, relative to
-	the anchor point of the parent surface. If two orthogonal gravities are
-	specified (e.g. 'bottom' and 'right'), then the child surface will be
-	placed in the specified direction; otherwise, the child surface will be
-	centered over the anchor point on any axis that had no gravity
-	specified.
-
-	If two parallel gravities are specified (e.g. 'left' and 'right'), the
-	invalid_input error is raised.
+	Defines which edge of the surface should be positioned relative to
+	the anchor of the parent surface. The anchor point will be in the specified corner,
+in the center of a specified edge, or in the center of the anchor rectangle if no edge
+is specified.
   
   
+	   summary="gravity direction"/>
 
 
 
-- 
2.12.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[David Edmundson]

You missed a line in "xdg-shell/positioner: Allow empty anchor_rect"
You might want to squash this with that.
From 0a21378302d63a83a10723b41adf35e605fb35f5 Mon Sep 17 00:00:00 2001
From: David Edmundson 
Date: Tue, 20 Jun 2017 18:29:59 +0100
Subject: [PATCH 1/2] Fix xdg-shell/positioner: Allow empty anchor_rect

---
 stable/xdg-shell/xdg-shell.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 2e845fa..ffba86d 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -165,7 +165,7 @@
 	Specify the anchor rectangle within the parent surface that the child
 	surface will be placed relative to. The rectangle is relative to the
 	window geometry as defined by xdg_surface.set_window_geometry of the
-	parent surface. The rectangle must be at least 1x1 large.
+	parent surface.
 
 	When the xdg_positioner object is used to position a child surface, the
 	anchor rectangle may not extend outside the window geometry of the
-- 
2.12.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] doc: update build instructions for Arch

[Eric Engestrom]

`abs` has been deprecated, and shut down last month. [1]
`asp` replaces it, so rewrite the instructions to use this instead.

Also, add `--noextract` to the makepkg command, as there is no point
downloading and extracting the sources since they're not going to be
built here.

[1] https://www.archlinux.org/news/deprecation-of-abs/

Signed-off-by: Eric Engestrom 
---
 doc/building.dox | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/doc/building.dox b/doc/building.dox
index 5ce2146..355c535 100644
--- a/doc/building.dox
+++ b/doc/building.dox
@@ -124,10 +124,11 @@ $> sudo zypper modifyrepo --disable `zypper repos | grep 
source | awk '{print $5
 
 Arch:
 
-$> abs extra/libinput
+$> sudo pacman -S asp
 $> cd $(mktemp -d)
+$> asp export libinput
-$> cp /var/abs/extra/libinput/PKGBUILD .
+$> cd libinput
-$> makepkg --syncdeps --nobuild
+$> makepkg --syncdeps --nobuild --noextract
 
 
 
-- 
Cheers,
  Eric

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] doc: add instructions for handling SELinux denials

[Eric Engestrom]

On Tuesday, 2017-06-20 12:45:15 +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
>  doc/building.dox | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/doc/building.dox b/doc/building.dox
> index 5ce21463..25594da8 100644
> --- a/doc/building.dox
> +++ b/doc/building.dox
> @@ -102,6 +102,33 @@ overwriting manually installed files.
>  Arch: ```sudo packman -S libinput```
>  
>  
> +@subsection building_selinux SELinux adjustments
> +
> +On systems with SELinux, overwriting the distribution-provided package with
> +a manually built libinput may cause SELinux denials. This usually manifests
> +when gdm does not start because it is denied access to libinput. The journal
> +shows a log message in the form of:
> +
> +
> +May 25 15:28:42 localhost.localdomain audit[23268]: AVC avc:  denied  { 
> execute } for  pid=23268 comm="gnome-shell" 
> path="/usr/lib64/libinput.so.10.12.2" dev="dm-0" ino=1709093 
> scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 
> tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0
> +May 25 15:28:42 localhost.localdomain org.gnome.Shell.desktop[23270]: 
> /usr/bin/gnome-shell: error while loading shared libraries: libinput.so.10: 
> failed to map segment from shared object
> +
> +
> +The summary of this error message is that gdm's gnome-shell runs in the
> +```system_u:system_r:xdm_t``` context but libinput is installed with the
> +context ```unconfined_u:object_r:user_home_t```.
> +
> +To avoid this issue, restore the SELinux context for any system files.
> +
> +
> +$> sudo restorecon /usr/lib/libinput.so.*
> +$> sudo restorecon /usr/lib64/libinput.so.*
> +
> +
> +Pick whichever one is your libdir.

You don't need this note if you give that command instead :)

$> sudo restorecon /usr/lib*/libinput.so.*

Reviewed-by: Eric Engestrom 

> +
> +This issue is tracked in https://github.com/mesonbuild/meson/issues/1967.
> +
>  @subsection building_dependencies Build dependencies
>  
>  libinput has a few build-time dependencies that must be installed prior to
> -- 
> 2.13.0
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput 1/3] meson: rename 'enable-tests' option to just 'tests'

[Eric Engestrom]

On Tuesday, 2017-06-20 12:26:24 +1000, Peter Hutterer wrote:
> All the other config options have a simple true/false as well.
> 
> Signed-off-by: Peter Hutterer 

All 3 patches are:
Reviewed-by: Eric Engestrom 

> ---
>  meson.build   | 2 +-
>  meson_options.txt | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meson.build b/meson.build
> index 9df35341..aba7f48c 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -436,7 +436,7 @@ executable('ptraccel-debug',
>  
>   tests 
>  
> -if get_option('enable-tests')
> +if get_option('tests')
>   dep_check = dependency('check', version : '>= 0.9.10')
>   valgrind = find_program('valgrind')
>   addr2line = find_program('addr2line')
> diff --git a/meson_options.txt b/meson_options.txt
> index f432e7ea..ad3095e3 100644
> --- a/meson_options.txt
> +++ b/meson_options.txt
> @@ -10,7 +10,7 @@ option('debug-gui',
> type: 'boolean',
> default: true,
> description: 'Enable the "debug-gui" feature in the libinput tool 
> [default=true]')
> -option('enable-tests',
> +option('tests',
> type: 'boolean',
> default: true,
> description: 'Build the tests [default=true]')
> -- 
> 2.13.0
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel