[ANNOUNCE] libinput 1.10.2

[Peter Hutterer]

libinput 1.10.2 is now available. Three important fixes, all
touchpad-related.

The first set of patches fixes an assertion that triggered when the tapping
code lost track of the finger count. This was triggered by palm detection,
but only by specific event sequences. 

The second fix affects all touchpads. libinput 1.10 was released with a new
hysteresis code that disabled the hysteresis when the touchpad events
appeared stable for long enough (i.e. no jitter/wobble with a finger down).
Turns out this isn't trustworthy and plenty of touchpads pause the pointer
jitter for long enough to trigger the hysteresis disabling code before
continuing to jitter like a caffeinated monkey on a sugar high.

The new code now works the opposite way: hysteresis is disabled by default
but if we detect pointer jitter/wobble, the hysteresis is enabled for the
rest of the session.

The third major fix is that the hysteresis, once enabled, now works across
both axes simultaneously. Previously the hysteresis looked at x and y
separately, causing axis snapping on small movements and turning tiny
circles into tiny rectangles. This is now fixed and the hysteresis works
along the movement vector.

Finally, a small fix to fix the pressure thresholds for the Apple Magic
Trackpad, the previously used catch-all thresholds caused some touches to be
dropped.

Daniel van Vugt (1):
  Introduce omnidirectional (elliptical) hysteresis

Konstantin Kharlamov (2):
  touchpad: remove the code for disabling hysteresis
  touchpad: add wobbling detection

Mario Di Raimondo (1):
  Fix Apple Magic Trackpad sensitivity

Peter Hutterer (9):
  meson: add the 221 version to the libsystemd dependency
  touchpad: don't do speed-based thumb detection on single-touch or semi-mts
  touchpad: move the hysteresis into its own substruct
  test: don't run the MT pressure test on devices without MT pressure
  test: don't run the 2fg pressure test on single-touch touchpads
  touchpad: add the pressure thresholds to the debugging output
  touchpad: don't end below-threshold pressure touches if nfake_fingers > 
nslots
  touchpad: add a TOUCH_MAYBE_END state
  libinput 1.10.2

git tag: 1.10.2

https://www.freedesktop.org/software/libinput/libinput-1.10.2.tar.xz
MD5:  f188d826de5b958cc561eec2b0c3d254  libinput-1.10.2.tar.xz
SHA1: 0c3214ab1cae791b390bc1562dbbf7712ee16780  libinput-1.10.2.tar.xz
SHA256: 1509766d348efe8c6da4285efad3acff4a4c955defb43309e3e4851849197bb9  
libinput-1.10.2.tar.xz
SHA512: 
c0418b2e0919fe085839a9ce7d4f155ea7a76f5395f5ed0ab7ab2f2226a2085b10ada5006bfb64c65d98a5fcc19395f722de379f0977a6c52a3630a9c0ad556e
  libinput-1.10.2.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.10.2.tar.xz.sig



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

[PATCH wayland] client: Don't inappropriatly close fds for zombie objects

[Derek Foreman]

commit 239ba39331420f953de35c337ae57db35573f9cb which was intended
to stop leaking fds in events for zombie objects didn't notice that
passing 0 to wl_connection_close_fds_in() would still close fds.

Test the fd count before calling.

Signed-off-by: Derek Foreman 
---
 src/wayland-client.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wayland-client.c b/src/wayland-client.c
index c1369b8..1ffa1f0 100644
--- a/src/wayland-client.c
+++ b/src/wayland-client.c
@@ -1359,7 +1359,7 @@ queue_event(struct wl_display *display, int len)
if (!proxy || wl_object_is_zombie(>objects, id)) {
struct wl_zombie *zombie = wl_map_lookup(>objects, id);
 
-   if (zombie)
+   if (zombie && zombie->fd_count[opcode]) {
wl_connection_close_fds_in(display->connection,
   zombie->fd_count[opcode]);
 
-- 
2.14.3

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

Re: [PATCH] xwm: Update input region on resize

[Emmanuel Gil Peyrot]

On Mon, Feb 19, 2018 at 12:18:51PM -0700, Scott Moreau wrote:
> Commit 332d1892 introduced a bug because the window was
> shaped only when the frame was created, leaving the input
> region unchanged regardless if the window was resized.
> This patch updates the input region shape on resize,
> fixing the problem.

This fixes the issue I had with Firefox, thanks!

Reviewed-by: Emmanuel Gil Peyrot 
Tested-by: Emmanuel Gil Peyrot 

> ---
>  xwayland/window-manager.c | 46 +++---
>  1 file changed, 27 insertions(+), 19 deletions(-)
> 
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index c307e19..5588166 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -659,6 +659,30 @@ weston_wm_window_get_input_rect(struct weston_wm_window 
> *window,
>  }
>  
>  static void
> +weston_wm_window_shape(struct weston_wm_window *window)
> +{
> + struct weston_wm *wm = window->wm;
> + xcb_rectangle_t rect;
> + int x, y, width, height;
> +
> + weston_wm_window_get_input_rect(window, , , , );
> +
> + rect.x = x;
> + rect.y = y;
> + rect.width = width;
> + rect.height = height;
> +
> + /* The window frame was created with position and size which include
> +  * an offset for margins and shadow. Set the input region to ignore
> +  * shadow. */
> + xcb_shape_rectangles(wm->conn,
> +  XCB_SHAPE_SO_SET,
> +  XCB_SHAPE_SK_INPUT,
> +  0, window->frame_id,
> +  0, 0, 1, );
> +}
> +
> +static void
>  weston_wm_window_send_configure_notify(struct weston_wm_window *window)
>  {
>   xcb_configure_notify_event_t configure_notify;
> @@ -789,6 +813,8 @@ weston_wm_handle_configure_notify(struct weston_wm *wm, 
> xcb_generic_event_t *eve
>   xwayland_api->set_xwayland(window->shsurf,
>  window->x, window->y);
>   }
> +
> + weston_wm_window_shape(window);
>  }
>  
>  static void
> @@ -983,7 +1009,6 @@ weston_wm_window_create_frame(struct weston_wm_window 
> *window)
>  {
>   struct weston_wm *wm = window->wm;
>   uint32_t values[3];
> - xcb_rectangle_t rect;
>   int x, y, width, height;
>   int buttons = FRAME_BUTTON_CLOSE;
>  
> @@ -1040,24 +1065,7 @@ weston_wm_window_create_frame(struct weston_wm_window 
> *window)
>>format_rgba,
>width, height);
>  
> - weston_wm_window_get_input_rect(window, , , , );
> - rect.x = x;
> - rect.y = y;
> - rect.width = width;
> - rect.height = height;
> -
> - /* The window frame was created with position and size which include
> -  * an offset for margins and shadow. Set the input region to ignore
> -  * shadow. */
> - xcb_shape_rectangles(wm->conn,
> -  XCB_SHAPE_SO_SET,
> -  XCB_SHAPE_SK_INPUT,
> -  0,
> -  window->frame_id,
> -  0,
> -  0,
> -  1,
> -  );
> + weston_wm_window_shape(window);
>  
>   hash_table_insert(wm->window_hash, window->frame_id, window);
>  }
> -- 
> 2.7.4
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-- 
Emmanuel Gil Peyrot


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

[RFC weston v2] libweston: Commit subsurfaces before committing root surface

[Philipp Kerling]

Committing the root surface triggers a commit of the xdg_surface state,
which might require the subsurface state already being applied (e.g.
when an xdg_toplevel needs to follow size constraints, the subsurfaces
must be in the right position and size at the time this is verified).
---
 libweston/compositor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index aec937bb..8589e390 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -3191,12 +3191,12 @@ surface_commit(struct wl_client *client, struct 
wl_resource *resource)
return;
}
 
-   weston_surface_commit(surface);
-
wl_list_for_each(sub, >subsurface_list, parent_link) {
if (sub->surface != surface)
weston_subsurface_parent_commit(sub, 0);
}
+
+   weston_surface_commit(surface);
 }
 
 static void
-- 
2.16.2

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

Re: How shall we start weston under systemd?

[Pekka Paalanen]

On Tue, 6 Mar 2018 09:58:50 +0100
Adam Trhon  wrote:

> > On Fri, 23 Feb 2018 16:00:22 +0100
> > Adam Trhon  wrote:
> >   

> > > This used to work well, but after a systemd update a couple months ago
> > > stopped working with:
> > > 
> > >   weston.service: Unit entered failed state.
> > >   weston.service: Failed with result 'protocol'
> > > 
> > > When we remove the `Type=notify` line, Weston starts fine, but other
> > > apps, which are dependent on it, start too early and fail. The behavior
> > > is consistent across multiple platforms. I checked Weston git history
> > > for changes in compositor/systemd-notify.c, also the bug tracker, but
> > > failed to find any recent changes. 

> 
> The problem was that we use systemd v234 and it contains a bug (fixed in
> v235) that breaks combination of Type=notify and PAMname=login.
> 
> It is fixed here: https://github.com/systemd/systemd/pull/6932

Oh, that's very good to know!


Thanks,
pq


pgpSAh2H2Keoq.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston refresh rate?

[Marius-cristian Vlad]

On Wed, 2018-02-28 at 16:24 +, Vanhauwaert Wouter wrote:
> Hello all,
> 
> I seem to have an issue, but don't really know what/who to address.
> Whatever I try to run on my weston installation, I never seem to
> exceed +- 40fps. 
> That can also be seen by running the weston-simple-egl test.
> When I run weston-simple-egl -f, so fullscreen, I get upto 27 fps.
> But, when I add -b, so weston-simple-egl -f -b (Don't sync to
> compositor redraw (eglSwapInterval 0)), I get a stunning 175 fps!
> So what is limiting the weston refresh rate? I'm running on a NXP
> IMX6D, industrial grade, morty yocto, weston/wayland 1.11. 
> 
> My fb settings are:
>  
> mode "1920x1080-60"
> # D: 148.500 MHz, H: 67.500 kHz, V: 60.000 Hz
> geometry 1920 1080 1920 2160 16
> timings 6734 148 88 36 4 44 5
> accel false
> rgba 5/11,6/5,5/0,0/0
> endmode
> 
> EGL is provided by vivante
> 
> Any thaughts?

People pointed to this patch [1]. It's for weston-2.0 so I don't knowif still 
applies.  

[1] https://source.codeaurora.org/external/imx/weston-imx/commit/?h=wes
ton-imx-2.0=3c51b529bd7d177bbb8b0c88df96636967075499

> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
> sts.freedesktop.org%2Fmailman%2Flistinfo%2Fwayland-
> devel=02%7C01%7Cmarius-
> cristian.vlad%40nxp.com%7C8073acdc2385433e273108d5827bf050%7C686ea1d3
> bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636558391180394327=DCEn4L%2B
> KD1cqohFDyf8s2pQ%2BRYkmIJEje%2B8iHbZUhr8%3D=0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How shall we start weston under systemd?

[Adam Trhon]

On Tue, 6 Mar 2018 10:15:53 +0200
Pekka Paalanen  wrote:

> On Fri, 23 Feb 2018 16:00:22 +0100
> Adam Trhon  wrote:
> 
> > Hello,
> > 
> > I would like to ask about the preferred way (now and in the future)
> > of starting Weston from systemd.
> > 
> > In our devices we start it by a custom .service file:
> > 
> >   [Unit]
> >   Description=Weston Wayland Compositor (on tty7)
> >   RequiresMountsFor=/run
> >   Conflicts=getty@tty7.service plymouth-quit.service
> >   After=systemd-user-sessions.service getty@tty7.service 
> > plymouth-quit-wait.service
> > 
> >   [Service]
> >   Type=notify
> >   User=root
> >   PermissionsStartOnly=true  
> >   PAMName=login
> > 
> >   # Grab tty7
> >   UtmpIdentifier=tty7
> >   TTYPath=/dev/tty7
> >   TTYReset=yes
> >   TTYVHangup=yes
> >   TTYVTDisallocate=yes
> >
> >   EnvironmentFile=-/etc/default/weston
> > 
> >   ExecStartPre=/usr/bin/chvt 7   
> >   ExecStart=/usr/bin/weston --modules=systemd-notify.so --log=/dev/null 
> > $OPTARGS  
> > 
> >   IgnoreSIGPIPE=no
> >   
> >   [Install]
> >   WantedBy=graphical.target
> > 
> > This used to work well, but after a systemd update a couple months ago
> > stopped working with:
> > 
> >   weston.service: Unit entered failed state.
> >   weston.service: Failed with result 'protocol'
> > 
> > When we remove the `Type=notify` line, Weston starts fine, but other
> > apps, which are dependent on it, start too early and fail. The behavior
> > is consistent across multiple platforms. I checked Weston git history
> > for changes in compositor/systemd-notify.c, also the bug tracker, but
> > failed to find any recent changes. 
> > 
> > How to proceed with this? Either it works for everyone else, or this is
> > not the right way to start Weston. Could you please check that our
> > unit file is correct? If yes and there is nothing to fix, shall we
> > revert back to using weston-launch, or start filling a bug report of
> > systemd-notify module not working?  
> 
> Hi,
> 
> have you compared your file and experience with the example and
> discussion at https://patchwork.freedesktop.org/patch/190638/ ?
> 
> Currently I have no knowledge beyond that. Would be good to not throw
> the weston log away and instead check if there is anything unusual.
> "Failed with result 'protocol'" sounds like systemd didn't like the
> communication, but I'm not sure.
> 
> Why would you run it as root?
> 
> (I assume your email was in the moderation queue, it arrived just now.)
> 
> 
> Thanks,
> pq

Hello,

thank you for the answer. Yes, my e-mail ended up in moderation queue and we
got it resolved before it got out :)

The problem was that we use systemd v234 and it contains a bug (fixed in
v235) that breaks combination of Type=notify and PAMname=login.

It is fixed here: https://github.com/systemd/systemd/pull/6932

We run it as root because it is in an embedded device and root is the
only user we have there.

Best regards
Adam

-- 
Ing. Adam Trhoň, Software Engineer
Touchless Biometric Systems s.r.o. | 
Palackého třída 180/44 | 61200 Brno | CZECH REPUBLIC | 
Mobile: +42(0) 721 565 113 | tbs-biometrics.cz


pgpdvfHwTSiaq.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: How shall we start weston under systemd?

[Pekka Paalanen]

On Fri, 23 Feb 2018 16:00:22 +0100
Adam Trhon  wrote:

> Hello,
> 
> I would like to ask about the preferred way (now and in the future)
> of starting Weston from systemd.
> 
> In our devices we start it by a custom .service file:
> 
>   [Unit]
>   Description=Weston Wayland Compositor (on tty7)
>   RequiresMountsFor=/run
>   Conflicts=getty@tty7.service plymouth-quit.service
>   After=systemd-user-sessions.service getty@tty7.service 
> plymouth-quit-wait.service
> 
>   [Service]
>   Type=notify
>   User=root
>   PermissionsStartOnly=true  
>   PAMName=login
> 
>   # Grab tty7
>   UtmpIdentifier=tty7
>   TTYPath=/dev/tty7
>   TTYReset=yes
>   TTYVHangup=yes
>   TTYVTDisallocate=yes
>
>   EnvironmentFile=-/etc/default/weston
> 
>   ExecStartPre=/usr/bin/chvt 7   
>   ExecStart=/usr/bin/weston --modules=systemd-notify.so --log=/dev/null 
> $OPTARGS  
> 
>   IgnoreSIGPIPE=no
>   
>   [Install]
>   WantedBy=graphical.target
> 
> This used to work well, but after a systemd update a couple months ago
> stopped working with:
> 
>   weston.service: Unit entered failed state.
>   weston.service: Failed with result 'protocol'
> 
> When we remove the `Type=notify` line, Weston starts fine, but other
> apps, which are dependent on it, start too early and fail. The behavior
> is consistent across multiple platforms. I checked Weston git history
> for changes in compositor/systemd-notify.c, also the bug tracker, but
> failed to find any recent changes. 
> 
> How to proceed with this? Either it works for everyone else, or this is
> not the right way to start Weston. Could you please check that our
> unit file is correct? If yes and there is nothing to fix, shall we
> revert back to using weston-launch, or start filling a bug report of
> systemd-notify module not working?

Hi,

have you compared your file and experience with the example and
discussion at https://patchwork.freedesktop.org/patch/190638/ ?

Currently I have no knowledge beyond that. Would be good to not throw
the weston log away and instead check if there is anything unusual.
"Failed with result 'protocol'" sounds like systemd didn't like the
communication, but I'm not sure.

Why would you run it as root?

(I assume your email was in the moderation queue, it arrived just now.)


Thanks,
pq


pgpS7Wc1ts7qo.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston refresh rate?

[Pekka Paalanen]

On Wed, 28 Feb 2018 16:24:58 +
Vanhauwaert Wouter  wrote:

> Hello all,
> 
> I seem to have an issue, but don't really know what/who to address.
> Whatever I try to run on my weston installation, I never seem to exceed +- 
> 40fps. 
> That can also be seen by running the weston-simple-egl test.
> When I run weston-simple-egl -f, so fullscreen, I get upto 27 fps.
> But, when I add -b, so weston-simple-egl -f -b (Don't sync to compositor 
> redraw (eglSwapInterval 0)), I get a stunning 175 fps!
> So what is limiting the weston refresh rate? I'm running on a NXP IMX6D, 
> industrial grade, morty yocto, weston/wayland 1.11. 
> 
> My fb settings are:
>  
> mode "1920x1080-60"
> # D: 148.500 MHz, H: 67.500 kHz, V: 60.000 Hz
> geometry 1920 1080 1920 2160 16
> timings 6734 148 88 36 4 44 5
> accel false
> rgba 5/11,6/5,5/0,0/0
> endmode
> 
> EGL is provided by vivante
> 
> Any thaughts?

Hi,

I would blame the proprietary graphics driver stack. I hope you will
have a better experience with a recent upstream kernel and Mesa etnaviv.

(I assume your email was in the moderation queue, it arrived just now.)


Thanks,
pq


pgpx8JYtSpuqR.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC weston] libweston: Do not include subsurfaces with NULL buffer in bounding box

[Pekka Paalanen]

On Mon, 05 Mar 2018 13:27:27 +0100
Philipp Kerling  wrote:

> Hi,
> 
> thanks for resurrecting this :-) reply below
> 
> 2017-12-04 (月) の 21:37 + に Daniel Stone さんは書きました:
> > Hi Philipp,
> > 
> > On 28 July 2017 at 15:41, Philipp Kerling  wrote:  
> > > I was pondering how to remove the window decorations of my
> > > application
> > > (which live in subsurfaces) when going full screen without
> > > flickering.
> > > 
> > > At first I just destroyed the surfaces, but that lead to flicker
> > > (window without decoration will appear for one frame before the
> > > full
> > > screen application is displayed) since subsurface destruction is
> > > not
> > > specified to be synchronized to the commit of the main surface.
> > > 
> > > Then I tried attaching a NULL wl_buffer to the surfaces. This works
> > > and
> > > does not flicker, but it has the problem that weston will
> > > disconnect my
> > > application when going to full screen for violating the configured
> > > xdg_shell buffer size. The reason seems to be that attaching a NULL
> > > wl_buffer does not reset the surface size and
> > > weston_surface_get_bounding_box still thinks that the surface has
> > > the
> > > prior size.
> > > 
> > > The patch fixes this by checking explicitly for the buffer and is
> > > confirmed to fix the issue, but I am not sure whether this is the
> > > right
> > > solution. Maybe surface->width and surface->height should be set to
> > > 0
> > > anyway?  
> > 
> > Hm. Yes, it does seem like the width/height should be 0, which is
> > undefined but not disallowed by the subsurface spec. I have no idea
> > if
> > this would work with Mutter in particular, which had problems
> > implementing that for top-levels.
> > 
> > In any case, perhaps one way you could do it would be to stack the
> > decoration subsurfaces below your primary surface before committing
> > your fullscreen buffer. It's ugly, but does seem like it should work
> > ...  
> I already did solve the problem for my application by attaching a NULL
> buffer and explicitly setting the window geometry on my xdg toplevel -
> then the bounding box calculation code in weston is not executed (think
> that was discussed in IRC).
> Still, it would be nice to get this right in weston, which is what the
> patch was about.
> 
> With "setting width/height to 0" I was referring to the variables in
> the weston code (subsurface->surface->width and ...->height), which I
> think may be better set to 0 if no buffer is attached to the
> subsurface. Currently, they seem to retain the size of the last
> attached buffer if you attach a NULL buffer.

Hi,

I didn't actually look at the code, so this comment is a vague
recollection from years ago: if the role interface (here wl_subsurface)
allows a NULL buffer to be committed, then by the general rule it will
cause that wl_surface to be unmapped, and it should also reset the
weston_surface size to zero. I do not recall any reason for not doing
that.

I actually have some hazy recollection of designing the hiding of a
sub-surface to intentionally need attaching a NULL wl_buffer to the
wl_surface, exactly for the synchronization reasons.


Thanks,
pq


pgpHM9mzRH9MQ.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel