[ANNOUNCE] libinput 1.10.3

[Peter Hutterer]

libinput 1.10.3 is now available. Only two patches, the first one to fix a
crasher triggered by a specific event sequence during 3-finger gestures
(and on some touchpads 2-finger gestures). The second one fixes the new
pointer jitter detection, a bitmask got lost and we compared 32 bits instead
of only the 3 we cared about.

Peter Hutterer (3):
  touchpad: end hovering touches in maybe_end_touch
  touchpad: make sure we compare only the last 3 events for wobble
  libinput 1.10.3

git tag: 1.10.3

https://www.freedesktop.org/software/libinput/libinput-1.10.3.tar.xz
MD5:  ffcf71ec913988c1c1a79a2169d71651  libinput-1.10.3.tar.xz
SHA1: 164c2463a34d0e39f55741fbf607d6dcdce873a7  libinput-1.10.3.tar.xz
SHA256: 0d52909584027ff6fcaba865c4454b77e91a2dba3c6cf520cdf87eccd2ec0200  
libinput-1.10.3.tar.xz
SHA512: 
4c73673e138a7aff9d6f2d189b8afdfb51c868eca0487c8c487ffd3bb48849994a9095fbd4c5c725ee17fafc2a85298106e0cc7b59b4a8cd13ec28f65d15c01d
  libinput-1.10.3.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.10.3.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 v2] xwm: Update input region on resize

[Scott Moreau]

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.

---

Changed in v2:

- Bail in shape function if (window->override_redirect || !window->frame)
- Call shape function from send_configure()

 xwayland/window-manager.c | 53 +--
 1 file changed, 33 insertions(+), 20 deletions(-)

diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
index c307e19..cd72a59 100644
--- a/xwayland/window-manager.c
+++ b/xwayland/window-manager.c
@@ -659,6 +659,33 @@ 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;
+
+   if (window->override_redirect || !window->frame)
+   return;
+
+   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 +816,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 +1012,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,26 +1068,9 @@ 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,
-);
-
hash_table_insert(wm->window_hash, window->frame_id, window);
+
+   weston_wm_window_shape(window);
 }
 
 /*
@@ -2726,6 +2737,8 @@ send_configure(struct weston_surface *surface, int32_t 
width, int32_t height)
window->configure_source =
wl_event_loop_add_idle(wm->server->loop,
   weston_wm_window_configure, window);
+
+   weston_wm_window_shape(window);
 }
 
 static void
-- 
2.7.4

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

Re: [PATCH weston] libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer at creation

[Quentin Glidic]

On 3/13/18 5:34 PM, Derek Foreman wrote:

When a surface has a buffer at creation time we send an error, which results
in a disconnection and all resources being destroyed.

Since we send that error and return before performing the configure_list init
weston_desktop_xdg_surface_destroy() will walk an uninitialized list and
dereference a NULL pointer.

Initializing the list earlier prevents this from happening.

Signed-off-by: Derek Foreman 


Good catch:
Reviewed-by: Quentin Glidic 

Thanks,


---
  libweston-desktop/xdg-shell-v6.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v6.c b/libweston-desktop/xdg-shell-v6.c
index f9902ff0..8fa01a32 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -1370,6 +1370,7 @@ weston_desktop_xdg_shell_protocol_get_xdg_surface(struct 
wl_client *wl_client,
  
  	surface->desktop = weston_desktop_client_get_desktop(client);

surface->surface = wsurface;
+   wl_list_init(>configure_list);
  
  	surface->desktop_surface =

weston_desktop_surface_create(surface->desktop, client,
@@ -1395,8 +1396,6 @@ weston_desktop_xdg_shell_protocol_get_xdg_surface(struct 
wl_client *wl_client,
   "xdg_surface must not have a buffer at 
creation");
return;
}
-
-   wl_list_init(>configure_list);
  }
  
  static void





--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH weston] libweston-desktop/xdg-shell-v6: Fix crash when surface has buffer at creation

[Derek Foreman]

When a surface has a buffer at creation time we send an error, which results
in a disconnection and all resources being destroyed.

Since we send that error and return before performing the configure_list init
weston_desktop_xdg_surface_destroy() will walk an uninitialized list and
dereference a NULL pointer.

Initializing the list earlier prevents this from happening.

Signed-off-by: Derek Foreman 
---
 libweston-desktop/xdg-shell-v6.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston-desktop/xdg-shell-v6.c b/libweston-desktop/xdg-shell-v6.c
index f9902ff0..8fa01a32 100644
--- a/libweston-desktop/xdg-shell-v6.c
+++ b/libweston-desktop/xdg-shell-v6.c
@@ -1370,6 +1370,7 @@ weston_desktop_xdg_shell_protocol_get_xdg_surface(struct 
wl_client *wl_client,
 
surface->desktop = weston_desktop_client_get_desktop(client);
surface->surface = wsurface;
+   wl_list_init(>configure_list);
 
surface->desktop_surface =
weston_desktop_surface_create(surface->desktop, client,
@@ -1395,8 +1396,6 @@ weston_desktop_xdg_shell_protocol_get_xdg_surface(struct 
wl_client *wl_client,
   "xdg_surface must not have a buffer at 
creation");
return;
}
-
-   wl_list_init(>configure_list);
 }
 
 static void
-- 
2.14.3

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

Re: wl_buffer is not released for long time.

[Sichem Zhou]

Dear Matt,

I just checked my compiled version, indeed I was using a version without
this patch. I patched my local weston but it didn't seem that my problem is
gone. So I guess there could be other problems with my code, but thanks for
your assistance. Now I can insert the callback in weston to do some
inspection.

Regards,
XZ

Le lun. 12 mars 2018 19 h 22, Matt Hoosier  a
écrit :

> Here's the discussion and patch that addressed the issue I was mentioning:
>
>
> https://lists.freedesktop.org/archives/wayland-devel/2017-September/035191.html
>
> On Mon, Mar 12, 2018 at 3:51 PM, Matt Hoosier 
> wrote:
> > Hi,
> >
> > Unless you're using an unreleased version of Weston, I think you're
> > probably running into a bug that we fixed a few months ago in which
> > wl_buffer::release() events were prone to sit undispatched in the
> > server's outgoing queue until some other event happened to need
> > transmitted.
> >
> > -Matt
> >
> > On Mon, Mar 12, 2018 at 1:23 PM, Sichem Zhou 
> wrote:
> >> Hi all,
> >>
> >> Dear wayland devs, I have a question regarding to double `wl_buffer`
> >> management. I don't seem to have wl_buffer released untill some other
> events
> >> triggered (for example, the  inputs). My current environment is under
> >> `X11-backend` and a libweston based compositor.
> >>
> >> My pipeline follows: (frame, attach, damage, commit) -> buffer switch ->
> >> wait until one buffer available -> redraw. The `done` event is handled
> >> differently since it only signals if ready to draw.
> >>
> >> Through my experiments, I found out at I wouldn't get either of the
> >> `release` of `frame done` event if I wasn't using the compositor (moving
> >> cursor or typing). In this case I guess there is something wrong with my
> >> pipeline but I couldn't figure out which. I wish to know if there is
> obvious
> >> mistakes in my pipeline or the problem lies in the compositor.
> >>
> >>  Very appreciate any answers.
> >>
> >> SZ
> >>
> >>
> >>
> >> ___
> >> 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 v2 1/4] Revert "wayland-egl-symbols-check: pass the DSO name via the build system"

[Emil Velikov]

On 12 March 2018 at 11:25, Daniel Stone  wrote:
> Hi,
>
> On 12 March 2018 at 11:21, Emil Velikov  wrote:
>> On 9 March 2018 at 11:09, Daniel Stone  wrote:
>>> On 9 March 2018 at 10:59, Emil Velikov  wrote:
  - above all, the internal path is a 'dummy' fallback. anyone can
 provide the binary name as an argument
 $ .../wayland-egl-symbols-check .../libwayland-egl.so
  - since we have a fallback - a plain .../wayland-egl-symbols-check
 will work most of the time
>>>
>>> That makes sense, running it from the build root. Is that just because
>>> 'make check' is slow, or? (sanity-test is really slow.)
>>>
>> Short back story: I was playing with OBS and getting the build
>> artefacts (the contents of a failing test) was a pain.
>> Admittedly, there may be another way to handle that, although in general:
>>
>> Passing the file as argument makes debugging a lot quicker/easier.
>
> Sure, that makes sense. I have a suggestion though: why don't we try
> argv[1] first, then fall back to $WAYLAND_EGL_LIB, and error out if
> neither are set? That way we don't hardcode internal autotools
> implementation details into our own scripts (remove fallback
> definition), allow autotools tests to run easily (environment
> variable), and allow people to use it manually for debugging
> (command-line argument). For the latter, I think being explicit is
> better: it means you can't accidentally forget to set an environment
> variable and end up testing the wrong thing.
>
In all honesty keeping things simple was my priority.
I was hoping for some compromise, but it seems like my allowance is out :-(

Modulo any objections, I'll just respin the series to drop this patch
all together.
People are open to hack things up when they hit a problem.

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

[PATCH wayland] configure.ac: don't install the static libraries

[Emil Velikov]

From: Emil Velikov 

One should always be using the shared libraries.

Spotted while going through the Debian packaing.

Signed-off-by: Emil Velikov 
---
Can we have this in the 1.5 release, please?
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index a53b6cc..26e517a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,7 @@ AM_CONDITIONAL(ENABLE_CPP_TEST, test "x$have_cpp_compiler" = 
"xyes")
 
 # Initialize libtool
 LT_PREREQ([2.2])
-LT_INIT
+LT_INIT([disable-static])
 
 PKG_PROG_PKG_CONFIG()
 
-- 
2.16.0

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

Proposal: use of xdg-shell popups outside of xdg-shell

[Drew DeVault]

Hi there! Over at the wlroots project we're thinking about repurposing
xdg-shell popups for use in another protocol that needs popups. The
popup interface is somewhat complex and duplicating it for each protocol
that might want to support popups is less than ideal.

From an API perspective, both xdg positioner and xdg popup look easily
reused with parents other than xdg toplevel. Everything is cleanly
separated in xdg shell to accomodate for this. The only real issue is
this line:

https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml#L1010

I propose simply dropping this comment from the protocol description.
It's a backwards- and forwards-compatible change, and there's no
compelling API-driven reason not to permit the reuse of xdg popups
elsewhere. Would definitely simplify the implementation of our new
protocol and future protocols that could use them.

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