Re: Recursive dispatch (Re: [PATCH v2] server: Calculate remaining data size after a closure is processed)

[Pekka Paalanen]

On Wed, 3 Feb 2016 13:44:27 -0800
Bryce Harrington  wrote:

> On Wed, Feb 03, 2016 at 01:37:21PM +0200, Pekka Paalanen wrote:
> > On Wed, 3 Feb 2016 10:52:07 +
> > Auke Booij  wrote:  
> > > On 3 February 2016 at 09:34, Jonas Ådahl  wrote:  
> > > > On Wed, Feb 03, 2016 at 11:14:54AM +0200, Pekka Paalanen wrote:
> > > >> On Wed, 3 Feb 2016 09:56:20 +0900
> > > >> "Jaeyoon Jung"  wrote:  
> > > >> > > > If someone starts hardening libwayland against programmer errors,
> > > >> > > > I'd expect one thing to be to abort() on recursive dispatch. Can
> > > >> > > > you tell me why we should support recursive dispatch?
> > > >> > >
> > > >> > > IMHO we should either do that immediately (before the 1.10 
> > > >> > > release) or
> > > >> > > revert this patch now.  Not that anything is wrong with the patch 
> > > >> > > - it
> > > >> > > doesn't introduce bugs in libwayland...
> > > >> > >
> > > >> > > Previously recursive dispatch was impossible, with this patch it's
> > > >> > > possible.  The patch was landed to allow recursive dispatch to 
> > > >> > > work,
> > > >> > > and it's obvious someone's about to start using it.

> > > >> > > So, with the release coming so quickly, I think we should either
> > > >> > > decide whether recursive dispatch is legal or illegal before the
> > > >> > > release, or revert the patch (thus re-breaking recursive dispatch) 
> > > >> > > and
> > > >> > > worry about it for 1.11.
> > > >>
> > > >> I would declare recursive dispatch as illegal. Does anyone object?
> > > >
> > > > I don't object declaring it illegal in libwayland-server since it was
> > > > previously broken, but doing so in libwayland-client I don't think we
> > > > should (at least yet) since it is used here and there in various clients
> > > > already.
> > 
> > Ok, let's do it for server since that's what we are looking at right
> > now. (Warnings and aborts would be implemented later.)
> > 
> > Client side is indeed more complicated, since it provably works
> > somewhat, we've had it in some Weston demos even, that were since fixed
> > AFAIK.  
> 
> Is there any chance that a client could make use of this to overload the
> server?  If there is, would that imply some security implications that
> we need to account for?  It is probably wiser to close such holes before
> releasing, even if it might risk delaying it.

Hi,

these issues with libwayland-client usage cannot cause new harm to
compositors.

However, if a compositor is dispatching recursively, does it make it
more vulnerable to maliciously crafted requests? Perhaps, but I would
think the impact is tiny.

Is it worth making those compositors crash right now whether they are
being attacked or not? That's a good question. Before the patch
referenced in this thread, clients would randomly get disconnected, and
right now things would seem to work with recursive dispatch in a
compositor, but we should have the documentation in place to say it's a
bad idea.

In any case, we cannot fix any potential vulnerability on this topic in
libwayland-server (or -client), we can only make the respective
programs crash at most.


Thanks,
pq


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

[server-core] Add signal for creation of clients.

[nicesj]

Using display object, if a new client is created, emit a signal.

In the server-side, we can get the destroy event of a client,
But there is no way to get the client create event.
Of course, we can get the client object from the global registry
binding callbacks.
But it can be called several times with same client object.
And even if A client creates display object,
(so there is a connection), The server could not know that.
There could be more use-cases not only for this.

Please review this and if possible, merge it to the stream.

Signed-off-by: Sung-jae Park 

diff --git a/src/wayland-server-core.h b/src/wayland-server-core.h
index e8e1e9c..cb72981 100644
--- a/src/wayland-server-core.h
+++ b/src/wayland-server-core.h
@@ -156,6 +156,21 @@ void
 wl_display_add_destroy_listener(struct wl_display *display,
struct wl_listener *listener);
 
+/** Add a listener for getting a notification of creation of clients.
+ *  If you add a listener, server will emits a signal if a new client
+ *  is created.
+ *
+ *  \ref wl_client_create
+ *  \ref wl_display
+ *  \ref wl_listener
+ *
+ * \param display The display object
+ * \param listener Signal handler object
+ */
+void
+wl_display_add_create_client_listener(struct wl_display *display,
+   struct wl_listener *listener);
+
 struct wl_listener *
 wl_display_get_destroy_listener(struct wl_display *display,
wl_notify_func_t notify);
diff --git a/src/wayland-server.c b/src/wayland-server.c
index ae9365f..0eff8f6 100644
--- a/src/wayland-server.c
+++ b/src/wayland-server.c
@@ -96,6 +96,7 @@ struct wl_display {
struct wl_list client_list;
 
struct wl_signal destroy_signal;
+   struct wl_signal create_client_signal;
 
struct wl_array additional_shm_formats;
 };
@@ -448,6 +449,8 @@ wl_client_create(struct wl_display *display, int fd)
 
wl_list_insert(display->client_list.prev, >link);
 
+   wl_signal_emit(>create_client_signal, client);
+
return client;
 
 err_map:
@@ -864,6 +867,7 @@ wl_display_create(void)
wl_list_init(>registry_resource_list);
 
wl_signal_init(>destroy_signal);
+   wl_signal_init(>create_client_signal);
 
display->id = 1;
display->serial = 0;
@@ -1353,6 +1357,13 @@ wl_display_add_destroy_listener(struct wl_display 
*display,
wl_signal_add(>destroy_signal, listener);
 }
 
+WL_EXPORT void
+wl_display_add_create_client_listener(struct wl_display *display,
+   struct wl_listener *listener)
+{
+   wl_signal_add(>create_client_signal, listener);
+}
+
 WL_EXPORT struct wl_listener *
 wl_display_get_destroy_listener(struct wl_display *display,
wl_notify_func_t notify)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Using Soft Keys with Weston & Libinput

[Ucan, Emre (ADITG/SW1)]

Hi,

We want to use soft keys with weston.

The use-case is very similar to android that the touch panel is bigger than the 
display.
The out of display touch events should be routed to the clients as key events.

As far as I understood, It is not possible to realize this use-case in current 
weston implementation,
because the coordinates of touch events are scaled to width and height of the 
display with libinput_event_touch_get_x(y)_transformed API.

For example, when I touch a soft key (outside of display), the grab interface 
will still get a touch event in the range of display width and height,
and It will wrongly route this event to a wl_surface which is on the edge of 
the display. Weston cannot recognize that the event happened outside of the 
display.

Is there a way to realize this use-case that I do not know ?

Best regards

Emre Ucan
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

[Daniel Stone]

On 3 February 2016 at 15:14, Rui Matos  wrote:
> The last cursor frame we commited before the pointer left one of our
> surfaces might not have been shown. In that case we'll have a cursor
> surface frame callback pending which we need to clear so that we can
> continue submitting new cursor frames.
>
> Signed-off-by: Rui Matos 

Ah, that explains a lot ... thanks Rui!

Reviewed-by: Daniel Stone 

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] xwm: Don't clear the selection if it has no text type available

[Carlos Garnacho]

Hi!,

On Mon, Feb 1, 2016 at 9:36 PM, Derek Foreman  wrote:
> weston maintains a copy of the most recently selected "thing" - it picks
> the first available type when it copies, and saves that one only.
>
> When an application quits weston will make the saved selection active.
>
> When xwm sees the selection set it will check if any of the offered types
> are text.  If no text type is offered it will clear the selection.
>
> weston then interprets this in the same way as an application exiting and
> causing the selection to be unset, and we get caught in a live lock with
> both weston and xwayland consuming as much cpu as they can.
>
> The simple fix is to just remove the test for text presence.
>
> Signed-off-by: Derek Foreman 
> ---
>
> This is kind of an alternate solution to the problem fixed in
> http://patchwork.freedesktop.org/patch/70435
>
> I don't understand why offers with no text type are cleared here,
> and couldn't find why with git blame either.  Anyone know why
> we've been doing this?

No idea myself, seems a rather arbitrary check. there shouldn't be any
reason this shouldn't work for other mimetypes offered.

>
> With this patch we can get somewhat odd behaviour - if terminology
> exits with a selection it can only be pasted into another terminology
> not a weston-terminal, because text wasn't the first offer and weston
> only saves the first offer.
>
> That seems better than a livelock though.  Maybe we can grab all available
> offers when cloning the selection instead of just the first (but that should
> be done in addition to this patch, I think, because we could have an app that
> doesn't offer text at all exit with a selection set and cause the same lock)

Reviewed-by: Carlos Garnacho 

I agree with the conclusion and the approach in this patch. As you say
the next step is storing all offers, but I guess it depends on how
deep we want weston to get into the clipboard manager role. AFAICS
that'd be most similar to how toolkits/apps used to behave wrt
SAVE_TARGETS as defined in the clipboard manager spec [1], where
simply all mimetypes would be stored (see eg. gtk_clipboard_store())

Cheers,
  Carlos

[1] http://www.freedesktop.org/wiki/ClipboardManager/

>
>
>  xwayland/selection.c | 28 
>  1 file changed, 4 insertions(+), 24 deletions(-)
>
> diff --git a/xwayland/selection.c b/xwayland/selection.c
> index 25ec848..24aa324 100644
> --- a/xwayland/selection.c
> +++ b/xwayland/selection.c
> @@ -655,8 +655,6 @@ weston_wm_set_selection(struct wl_listener *listener, 
> void *data)
> struct weston_wm *wm =
> container_of(listener, struct weston_wm, selection_listener);
> struct weston_data_source *source = seat->selection_data_source;
> -   const char **p, **end;
> -   int has_text_plain = 0;
>
> if (source == NULL) {
> if (wm->selection_owner == wm->selection_window)
> @@ -670,28 +668,10 @@ weston_wm_set_selection(struct wl_listener *listener, 
> void *data)
> if (source->send == data_source_send)
> return;
>
> -   p = source->mime_types.data;
> -   end = (const char **)
> -   ((char *) source->mime_types.data + source->mime_types.size);
> -   while (p < end) {
> -   weston_log("  %s\n", *p);
> -   if (strcmp(*p, "text/plain") == 0 ||
> -   strcmp(*p, "text/plain;charset=utf-8") == 0)
> -   has_text_plain = 1;
> -   p++;
> -   }
> -
> -   if (has_text_plain) {
> -   xcb_set_selection_owner(wm->conn,
> -   wm->selection_window,
> -   wm->atom.clipboard,
> -   XCB_TIME_CURRENT_TIME);
> -   } else {
> -   xcb_set_selection_owner(wm->conn,
> -   XCB_ATOM_NONE,
> -   wm->atom.clipboard,
> -   XCB_TIME_CURRENT_TIME);
> -   }
> +   xcb_set_selection_owner(wm->conn,
> +   wm->selection_window,
> +   wm->atom.clipboard,
> +   XCB_TIME_CURRENT_TIME);
>  }
>
>  void
> --
> 2.7.0
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Regarding shm_pool and buffer.

[nicesj]

Dear all,

I can learn many things from this mailing list, thank you very much.

I have one more doubt about relations between memory pool and buffer.

I read a doc of wayland and it explains a wl_buffer can be created from 
shm-pool.

but in the example code, after creates the buffer from pool, attach it to the 
surface, and then the example destroyes shm pool resources from the client side.

so the server will gets destroy request.

the buffer which is attached to surface, however, still in use.

If I understood correctly, the pool should not be destroyed until all 
wl-buffers are freed.

Am I understood correctly?

or does the server should keep the pool information even though the client 
destroyes it?

Thank you all.

Best regards,
Sung-jae Park.

Sent from my android device.___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

[Jonas Ådahl]

On Feb 5, 2016 12:53 AM, "Rui Matos"  wrote:
>
> The last cursor frame we commited before the pointer left one of our
> surfaces might not have been shown. In that case we'll have a cursor
> surface frame callback pending which we need to clear so that we can
> continue submitting new cursor frames.
>
> Signed-off-by: Rui Matos 
> Reviewed-by: Daniel Stone 

Reviewed-by: Jonas Ådahl 

> ---
>
> v2: as suggested by Jonas, moved the hunk further up to stay close to
> another related hack we already have and also removed the
> xwl_seat_set_cursor() call since CheckMotion() will do that too.
>
> I think Daniel's r-b still stands anyway.
>
>  hw/xwayland/xwayland-input.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index 61ca70b..d6cbf32 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -251,6 +251,15 @@ pointer_handle_enter(void *data, struct wl_pointer
*pointer,
>  mipointer = MIPOINTER(master);
>  mipointer->pSpriteCursor = (CursorPtr) 1;
>
> +/* The last cursor frame we commited before the pointer left one
> + * of our surfaces might not have been shown. In that case we'll
> + * have a cursor surface frame callback pending which we need to
> + * clear so that we can continue submitting new cursor frames. */
> +if (xwl_seat->cursor_frame_cb) {
> +wl_callback_destroy(xwl_seat->cursor_frame_cb);
> +xwl_seat->cursor_frame_cb = NULL;
> +}
> +
>  CheckMotion(NULL, master);
>
>  /* Ideally, X clients shouldn't see these button releases.  When
> --
> 2.5.0
>
> ___
> xorg-de...@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] xwm: Don't clear the selection if it has no text type available

[Bryce Harrington]

On Thu, Feb 04, 2016 at 11:37:36PM +0100, Carlos Garnacho wrote:
> Hi!,
> 
> On Mon, Feb 1, 2016 at 9:36 PM, Derek Foreman  wrote:
> > weston maintains a copy of the most recently selected "thing" - it picks
> > the first available type when it copies, and saves that one only.
> >
> > When an application quits weston will make the saved selection active.
> >
> > When xwm sees the selection set it will check if any of the offered types
> > are text.  If no text type is offered it will clear the selection.
> >
> > weston then interprets this in the same way as an application exiting and
> > causing the selection to be unset, and we get caught in a live lock with
> > both weston and xwayland consuming as much cpu as they can.
> >
> > The simple fix is to just remove the test for text presence.
> >
> > Signed-off-by: Derek Foreman 
> > ---
> >
> > This is kind of an alternate solution to the problem fixed in
> > http://patchwork.freedesktop.org/patch/70435
> >
> > I don't understand why offers with no text type are cleared here,
> > and couldn't find why with git blame either.  Anyone know why
> > we've been doing this?
> 
> No idea myself, seems a rather arbitrary check. there shouldn't be any
> reason this shouldn't work for other mimetypes offered.
> 
> >
> > With this patch we can get somewhat odd behaviour - if terminology
> > exits with a selection it can only be pasted into another terminology
> > not a weston-terminal, because text wasn't the first offer and weston
> > only saves the first offer.
> >
> > That seems better than a livelock though.  Maybe we can grab all available
> > offers when cloning the selection instead of just the first (but that should
> > be done in addition to this patch, I think, because we could have an app 
> > that
> > doesn't offer text at all exit with a selection set and cause the same lock)
> 
> Reviewed-by: Carlos Garnacho 
> 
> I agree with the conclusion and the approach in this patch. As you say
> the next step is storing all offers, but I guess it depends on how
> deep we want weston to get into the clipboard manager role. AFAICS
> that'd be most similar to how toolkits/apps used to behave wrt
> SAVE_TARGETS as defined in the clipboard manager spec [1], where
> simply all mimetypes would be stored (see eg. gtk_clipboard_store())
> 
> Cheers,
>   Carlos
> 
> [1] http://www.freedesktop.org/wiki/ClipboardManager/

Thanks, pushed:

To ssh://git.freedesktop.org/git/wayland/weston
   22b1f93..4e18448  master -> master

From the discussion I'm a little worried that there might be side
effects, or at least that this may need some follow on work, but since
the scope is limited to xwm the risk level here seems acceptable.

Bryce

> >  xwayland/selection.c | 28 
> >  1 file changed, 4 insertions(+), 24 deletions(-)
> >
> > diff --git a/xwayland/selection.c b/xwayland/selection.c
> > index 25ec848..24aa324 100644
> > --- a/xwayland/selection.c
> > +++ b/xwayland/selection.c
> > @@ -655,8 +655,6 @@ weston_wm_set_selection(struct wl_listener *listener, 
> > void *data)
> > struct weston_wm *wm =
> > container_of(listener, struct weston_wm, 
> > selection_listener);
> > struct weston_data_source *source = seat->selection_data_source;
> > -   const char **p, **end;
> > -   int has_text_plain = 0;
> >
> > if (source == NULL) {
> > if (wm->selection_owner == wm->selection_window)
> > @@ -670,28 +668,10 @@ weston_wm_set_selection(struct wl_listener *listener, 
> > void *data)
> > if (source->send == data_source_send)
> > return;
> >
> > -   p = source->mime_types.data;
> > -   end = (const char **)
> > -   ((char *) source->mime_types.data + 
> > source->mime_types.size);
> > -   while (p < end) {
> > -   weston_log("  %s\n", *p);
> > -   if (strcmp(*p, "text/plain") == 0 ||
> > -   strcmp(*p, "text/plain;charset=utf-8") == 0)
> > -   has_text_plain = 1;
> > -   p++;
> > -   }
> > -
> > -   if (has_text_plain) {
> > -   xcb_set_selection_owner(wm->conn,
> > -   wm->selection_window,
> > -   wm->atom.clipboard,
> > -   XCB_TIME_CURRENT_TIME);
> > -   } else {
> > -   xcb_set_selection_owner(wm->conn,
> > -   XCB_ATOM_NONE,
> > -   wm->atom.clipboard,
> > -   XCB_TIME_CURRENT_TIME);
> > -   }
> > +   xcb_set_selection_owner(wm->conn,
> > +   wm->selection_window,
> > +   wm->atom.clipboard,
> > +   XCB_TIME_CURRENT_TIME);
> >  }
> >
> >  void
> > --
> > 2.7.0
> >
> > 

Re: [PATCH] cosmetic: add an space after if

[Bryce Harrington]

On Thu, Feb 04, 2016 at 09:48:21PM +0100, Sergi Granell wrote:
> ---
>  src/wayland-shm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Hi Sergi,

Thanks, pushed both this and the other whitespace fix:

To ssh://git.freedesktop.org/git/wayland/wayland
   369b646..d335143  master -> master

 
> diff --git a/src/wayland-shm.c b/src/wayland-shm.c
> index 8e7adc9..a4343a4 100644
> --- a/src/wayland-shm.c
> +++ b/src/wayland-shm.c
> @@ -117,7 +117,7 @@ format_is_supported(struct wl_client *client, uint32_t 
> format)
>   default:
>   formats = wl_display_get_additional_shm_formats(display);
>   wl_array_for_each(p, formats)
> - if(*p == format)
> + if (*p == format)
>   return true;
>   }
>  
> -- 
> 2.7.0
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] touchpad: if we have a serio keyboard, override any previous dwt pairing

[Hans de Goede]

Hi,

On 04-02-16 08:23, Peter Hutterer wrote:

If a USB keyboard like the YubiKey is found before the internal keyboard, it
will be paired with the touchpad when it is seen. The internal keyboard is
seen later but ignored because we already have a keyboard paired with the
touchpad.

This is obviously wrong. For now, give priority to serio keyboards, and
override existing dwt pairings with the new keyboard.

https://bugs.freedesktop.org/show_bug.cgi?id=93983

Signed-off-by: Peter Hutterer 


Patch looks good to me: Reviewed-by: Hans de Goede 

Regards.

Hans


---
  src/evdev-mt-touchpad.c|  48 ---
  test/Makefile.am   |   2 +
  test/litest-device-synaptics-i2c.c | 102 ++
  test/litest-device-yubikey.c   | 169 +
  test/litest.c  |   4 +
  test/litest.h  |   2 +
  test/touchpad.c| 103 ++
  7 files changed, 416 insertions(+), 14 deletions(-)
  create mode 100644 test/litest-device-synaptics-i2c.c
  create mode 100644 test/litest-device-yubikey.c

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index d0d1ddd..2be9d40 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1336,6 +1336,38 @@ tp_want_dwt(struct evdev_device *touchpad,
  }

  static void
+tp_dwt_pair_keyboard(struct evdev_device *touchpad,
+struct evdev_device *keyboard)
+{
+   struct tp_dispatch *tp = (struct tp_dispatch*)touchpad->dispatch;
+   unsigned int bus_kbd = libevdev_get_id_bustype(keyboard->evdev);
+
+   if (!tp_want_dwt(touchpad, keyboard))
+   return;
+
+   /* If we already have a keyboard paired, override it if the new one
+* is a serio device. Otherwise keep the current one */
+   if (tp->dwt.keyboard) {
+   if (bus_kbd != BUS_I8042)
+   return;
+
+   memset(tp->dwt.key_mask, 0, sizeof(tp->dwt.key_mask));
+   
libinput_device_remove_event_listener(>dwt.keyboard_listener);
+   }
+
+   libinput_device_add_event_listener(>base,
+   >dwt.keyboard_listener,
+   tp_keyboard_event, tp);
+   tp->dwt.keyboard = keyboard;
+   tp->dwt.keyboard_active = false;
+
+   log_debug(touchpad->base.seat->libinput,
+ "palm: dwt activated with %s<->%s\n",
+ touchpad->devname,
+ keyboard->devname);
+}
+
+static void
  tp_interface_device_added(struct evdev_device *device,
  struct evdev_device *added_device)
  {
@@ -1359,20 +1391,8 @@ tp_interface_device_added(struct evdev_device *device,
tp_trackpoint_event, tp);
}

-   if (added_device->tags & EVDEV_TAG_KEYBOARD &&
-   tp->dwt.keyboard == NULL &&
-   tp_want_dwt(device, added_device)) {
-   log_debug(tp_libinput_context(tp),
- "palm: dwt activated with %s<->%s\n",
- device->devname,
- added_device->devname);
-
-   libinput_device_add_event_listener(_device->base,
-   >dwt.keyboard_listener,
-   tp_keyboard_event, tp);
-   tp->dwt.keyboard = added_device;
-   tp->dwt.keyboard_active = false;
-   }
+   if (added_device->tags & EVDEV_TAG_KEYBOARD)
+   tp_dwt_pair_keyboard(device, added_device);

if (tp->sendevents.current_mode !=
LIBINPUT_CONFIG_SEND_EVENTS_DISABLED_ON_EXTERNAL_MOUSE)
diff --git a/test/Makefile.am b/test/Makefile.am
index 27a2a36..c7e68ef 100644
--- a/test/Makefile.am
+++ b/test/Makefile.am
@@ -38,6 +38,7 @@ liblitest_la_SOURCES = \
litest-device-qemu-usb-tablet.c \
litest-device-synaptics.c \
litest-device-synaptics-hover.c \
+   litest-device-synaptics-i2c.c \
litest-device-synaptics-st.c \
litest-device-synaptics-t440.c \
litest-device-synaptics-x1-carbon-3rd.c \
@@ -53,6 +54,7 @@ liblitest_la_SOURCES = \
litest-device-wheel-only.c \
litest-device-xen-virtual-pointer.c \
litest-device-vmware-virtual-usb-mouse.c \
+   litest-device-yubikey.c \
litest.c
  liblitest_la_LIBADD = $(top_builddir)/src/libinput-util.la
  liblitest_la_CFLAGS = $(AM_CFLAGS) \
diff --git a/test/litest-device-synaptics-i2c.c 
b/test/litest-device-synaptics-i2c.c
new file mode 100644
index 000..b6b632b
--- /dev/null
+++ b/test/litest-device-synaptics-i2c.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright © 2015 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, 

[ANNOUNCE] libinput 1.1.6

[Peter Hutterer]

libinput 1.1.6 is now available. 

This release has a couple of noticable changes over the last one.

The calculation of finger motion for multifinger gestures (including
two-finger scrolling) was buggy. A slow two-finger motion could double the
effective speed under some circumstances, causing scroll jumps. This has
been fixed now.

The touchpad motion hysteresis is now deactivated by default. This may
negatively affect some (especially older) touchpads, and we'll have to
re-enable the hysteresis on those. If you notice pointer wobbles when
hold the finger still please file a bug so we can address this. Everyone
else should see a smoother motion especially on small and tiny motions
making single-pixel elements much easier to target.

Disable-while-typing now works when a key is held down. And the pairing
algorithm has been improved to avoid cases where the touchpad was paired
with an external USB keyboard, despite there being a internal keyboard.

Last: the mode button on the Cyborg RAT 5 is now disabled. This button is
special, on each press it cycles through 3 'modes', sending a release
event for the current button and a down event for the next event code. This  
causes stuck buttons, since we have nothing in userspace that would handle
that button as intended, disabling it is the current solution.

Peter Hutterer (10):
  test: fix compiler warning
  test: run pinch gesture tests for 2-slot touchpads
  test: exclude semi-mt devices from the normal 2fg scroll test
  gestures: average motion by active touches, not moved touches
  evdev: disable the mode button on the Cyborg RAT 5
  test: fix leaking libevdev fd
  touchpad: drop motion hysteresis by default
  touchpad: while a key is held down, don't disable dwt
  touchpad: if we have a serio keyboard, override any previous dwt pairing
  configure.ac: libinput 1.1.6

git tag: 1.1.6

http://www.freedesktop.org/software/libinput/libinput-1.1.6.tar.xz
MD5:  7ae03d6c4176537cb588b8d2a23cb297  libinput-1.1.6.tar.xz
SHA1: edec84db6d67618d882df22ef54ca5113c3243a8  libinput-1.1.6.tar.xz
SHA256: f26f5e02c4942775cfa5f143562cf4ed9fc3be8bc2c3c461acc8de1b114a1c63  
libinput-1.1.6.tar.xz
PGP:  http://www.freedesktop.org/software/libinput/libinput-1.1.6.tar.xz.sig



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

Re: Using Soft Keys with Weston & Libinput

[Peter Hutterer]

On Thu, Feb 04, 2016 at 10:38:18AM +, Ucan, Emre (ADITG/SW1) wrote:
> Hi,
> 
> We want to use soft keys with weston.
> 
> The use-case is very similar to android that the touch panel is bigger than 
> the display.
> The out of display touch events should be routed to the clients as key events.
> 
> As far as I understood, It is not possible to realize this use-case in 
> current weston implementation,
> because the coordinates of touch events are scaled to width and height of the 
> display with libinput_event_touch_get_x(y)_transformed API.
> 
> For example, when I touch a soft key (outside of display), the grab interface 
> will still get a touch event in the range of display width and height,
> and It will wrongly route this event to a wl_surface which is on the edge of 
> the display. Weston cannot recognize that the event happened outside of the 
> display.
> 
> Is there a way to realize this use-case that I do not know ?

short answer: you'll need code in weston to handle this. 

libinput doesn't care about the display, it merely takes the touch
coordinates, the API then tells libinput to scale the range into that
coordinate set. If you screen has an offset, you need to detect that and
handle it separately but that is not something weston currently does.

with the current APIs what you'll need to do is check the mm value for the
display, calculate if it is outside the boundary you want and handle it
accordingly. if it is within the display boundary, then you can pass it on
normally.

Cheers,
   Peter
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] scanner: Fix oddities in copyright printing

[Bryce Harrington]

On Tue, Feb 02, 2016 at 02:56:57PM -0600, Derek Foreman wrote:
> Some copyright strings could result in broken generated header files with
> unmatched */
> 
> This change:
> Runs the loop long enough so the copyright[i] == 0 test can actually
> happen. (if there was no \n no copyright text was printed, */ still was)
> 
> Prints the opening /* even if there was whitespace at the start of
> the very first line.
> 
> Only emits a */ if a /* was printed.
> 
> Signed-off-by: Derek Foreman 
Reviewed-by: Bryce Harrington 

> ---
>  src/scanner.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/src/scanner.c b/src/scanner.c
> index dda5473..d3e2328 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -1284,25 +1284,29 @@ emit_structs(struct wl_list *message_list, struct 
> interface *interface, enum sid
>  static void
>  format_copyright(const char *copyright)
>  {
> - int bol = 1, start = 0, i;
> + int bol = 1, start = 0, i, length;
> + bool comment_started = false;
>  
> - for (i = 0; copyright[i]; i++) {
> + length = strlen(copyright);
> + for (i = 0; i <= length; i++) {
>   if (bol && (copyright[i] == ' ' || copyright[i] == '\t')) {
>   continue;
>   } else if (bol) {
>   bol = 0;
>   start = i;
>   }
> -
> - if (copyright[i] == '\n' || copyright[i] == '\0') {
> + if (copyright[i] == '\n' ||
> + (copyright[i] == '\0' && !(start == i))) {
>   printf("%s%s%.*s\n",
> -i == 0 ? "/*" : " *",
> +comment_started ? " *" : "/*",
>  i > start ? " " : "",
>  i - start, copyright + start);
>   bol = 1;
> + comment_started = true;
>   }
>   }
> - printf(" */\n\n");
> + if (comment_started)
> + printf(" */\n\n");
>  }
>  
>  static void
> -- 
> 2.7.0
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] scanner: Fix oddities in copyright printing

[Bryce Harrington]

On Tue, Feb 02, 2016 at 01:23:01PM -0800, Jon A. Cruz wrote:
> On 02/02/2016 12:56 PM, Derek Foreman wrote:
> >Some copyright strings could result in broken generated header files with
> >unmatched */
> >
> >This change:
> >Runs the loop long enough so the copyright[i] == 0 test can actually
> >happen. (if there was no \n no copyright text was printed, */ still was)
> >
> >Prints the opening /* even if there was whitespace at the start of
> >the very first line.
> >
> >Only emits a */ if a /* was printed.
> >
> >Signed-off-by: Derek Foreman 
> 
> Looks good to me:
> Reviewed-by: Jon A. Cruz 
 
Thanks, pushed:
To ssh://git.freedesktop.org/git/wayland/wayland
   816a0ae..369b646  master -> master



> >---
> >  src/scanner.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> >diff --git a/src/scanner.c b/src/scanner.c
> >index dda5473..d3e2328 100644
> >--- a/src/scanner.c
> >+++ b/src/scanner.c
> >@@ -1284,25 +1284,29 @@ emit_structs(struct wl_list *message_list, struct 
> >interface *interface, enum sid
> >  static void
> >  format_copyright(const char *copyright)
> >  {
> >-int bol = 1, start = 0, i;
> >+int bol = 1, start = 0, i, length;
> >+bool comment_started = false;
> >-for (i = 0; copyright[i]; i++) {
> >+length = strlen(copyright);
> >+for (i = 0; i <= length; i++) {
> > if (bol && (copyright[i] == ' ' || copyright[i] == '\t')) {
> > continue;
> > } else if (bol) {
> > bol = 0;
> > start = i;
> > }
> >-
> >-if (copyright[i] == '\n' || copyright[i] == '\0') {
> >+if (copyright[i] == '\n' ||
> >+(copyright[i] == '\0' && !(start == i))) {
> > printf("%s%s%.*s\n",
> >-   i == 0 ? "/*" : " *",
> >+   comment_started ? " *" : "/*",
> >i > start ? " " : "",
> >i - start, copyright + start);
> > bol = 1;
> >+comment_started = true;
> > }
> > }
> >-printf(" */\n\n");
> >+if (comment_started)
> >+printf(" */\n\n");
> >  }
> >  static void
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

[Rui Matos]

The last cursor frame we commited before the pointer left one of our
surfaces might not have been shown. In that case we'll have a cursor
surface frame callback pending which we need to clear so that we can
continue submitting new cursor frames.

Signed-off-by: Rui Matos 
Reviewed-by: Daniel Stone 
---

v2: as suggested by Jonas, moved the hunk further up to stay close to
another related hack we already have and also removed the
xwl_seat_set_cursor() call since CheckMotion() will do that too.

I think Daniel's r-b still stands anyway.

 hw/xwayland/xwayland-input.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
index 61ca70b..d6cbf32 100644
--- a/hw/xwayland/xwayland-input.c
+++ b/hw/xwayland/xwayland-input.c
@@ -251,6 +251,15 @@ pointer_handle_enter(void *data, struct wl_pointer 
*pointer,
 mipointer = MIPOINTER(master);
 mipointer->pSpriteCursor = (CursorPtr) 1;
 
+/* The last cursor frame we commited before the pointer left one
+ * of our surfaces might not have been shown. In that case we'll
+ * have a cursor surface frame callback pending which we need to
+ * clear so that we can continue submitting new cursor frames. */
+if (xwl_seat->cursor_frame_cb) {
+wl_callback_destroy(xwl_seat->cursor_frame_cb);
+xwl_seat->cursor_frame_cb = NULL;
+}
+
 CheckMotion(NULL, master);
 
 /* Ideally, X clients shouldn't see these button releases.  When
-- 
2.5.0

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

Re: [PATCH libinput] touchpad: while a key is held down, don't disable dwt

[Hans de Goede]

Hi,

On 04-02-16 01:33, Peter Hutterer wrote:

If a key enables dwt and is held down when the timeout expires, re-issue the
timeout.

There is a corner case where dwt may not work as expected:
1. key down and held down
2. dwt timer expires, dwt is re-issued
3. touch starts
4. key is released
5. dwt timer expires
6. touch now starts moving the pointer

This is an effect of the smart touch detection. A touch starting after the
last key press is released for pointer motion once dwt turns off again. This
is what happens in the above case, the dwt timer expiring is the last virtual
key press. This is a corner case and likely hard to trigger by a real user.

https://bugs.freedesktop.org/show_bug.cgi?id=93984

Signed-off-by: Peter Hutterer 


Patch looks good to me: Reviewed-by: Hans de Goede 

Regards.

Hans



---
  src/evdev-mt-touchpad.c |  18 +-
  src/evdev-mt-touchpad.h |   1 +
  src/libinput-util.h |  14 +
  test/touchpad.c | 142 
  4 files changed, 173 insertions(+), 2 deletions(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index f249116..d0d1ddd 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1196,6 +1196,15 @@ tp_keyboard_timeout(uint64_t now, void *data)
  {
struct tp_dispatch *tp = data;

+   if (long_any_bit_set(tp->dwt.key_mask,
+ARRAY_LENGTH(tp->dwt.key_mask))) {
+   libinput_timer_set(>dwt.keyboard_timer,
+  now + DEFAULT_KEYBOARD_ACTIVITY_TIMEOUT_2);
+   tp->dwt.keyboard_last_press_time = now;
+   log_debug(tp_libinput_context(tp), "palm: keyboard timeout 
refresh\n");
+   return;
+   }
+
tp_tap_resume(tp, now);

tp->dwt.keyboard_active = false;
@@ -1240,6 +1249,7 @@ tp_keyboard_event(uint64_t time, struct libinput_event 
*event, void *data)
struct tp_dispatch *tp = data;
struct libinput_event_keyboard *kbdev;
unsigned int timeout;
+   unsigned int key;

if (!tp->dwt.dwt_enabled)
return;
@@ -1248,15 +1258,18 @@ tp_keyboard_event(uint64_t time, struct libinput_event 
*event, void *data)
return;

kbdev = libinput_event_get_keyboard_event(event);
+   key = libinput_event_keyboard_get_key(kbdev);

/* Only trigger the timer on key down. */
if (libinput_event_keyboard_get_key_state(kbdev) !=
-   LIBINPUT_KEY_STATE_PRESSED)
+   LIBINPUT_KEY_STATE_PRESSED) {
+   long_clear_bit(tp->dwt.key_mask, key);
return;
+   }

/* modifier keys don't trigger disable-while-typing so things like
 * ctrl+zoom or ctrl+click are possible */
-   if (tp_key_ignore_for_dwt(libinput_event_keyboard_get_key(kbdev)))
+   if (tp_key_ignore_for_dwt(key))
return;

if (!tp->dwt.keyboard_active) {
@@ -1270,6 +1283,7 @@ tp_keyboard_event(uint64_t time, struct libinput_event 
*event, void *data)
}

tp->dwt.keyboard_last_press_time = time;
+   long_set_bit(tp->dwt.key_mask, key);
libinput_timer_set(>dwt.keyboard_timer,
   time + timeout);
  }
diff --git a/src/evdev-mt-touchpad.h b/src/evdev-mt-touchpad.h
index 0053122..87d34b2 100644
--- a/src/evdev-mt-touchpad.h
+++ b/src/evdev-mt-touchpad.h
@@ -343,6 +343,7 @@ struct tp_dispatch {
struct libinput_event_listener keyboard_listener;
struct libinput_timer keyboard_timer;
struct evdev_device *keyboard;
+   unsigned long key_mask[NLONGS(KEY_CNT)];

uint64_t keyboard_last_press_time;
} dwt;
diff --git a/src/libinput-util.h b/src/libinput-util.h
index 6adbbc9..522c19c 100644
--- a/src/libinput-util.h
+++ b/src/libinput-util.h
@@ -25,6 +25,7 @@
  #ifndef LIBINPUT_UTIL_H
  #define LIBINPUT_UTIL_H

+#include 
  #include 
  #include 
  #include 
@@ -171,6 +172,19 @@ long_set_bit_state(unsigned long *array, int bit, int 
state)
long_clear_bit(array, bit);
  }

+static inline int
+long_any_bit_set(unsigned long *array, size_t size)
+{
+   unsigned long i;
+
+   assert(size > 0);
+
+   for (i = 0; i < size; i++)
+   if (array[i] != 0)
+   return 1;
+   return 0;
+}
+
  struct matrix {
float val[3][3]; /* [row][col] */
  };
diff --git a/test/touchpad.c b/test/touchpad.c
index 9376cd5..0d3aa03 100644
--- a/test/touchpad.c
+++ b/test/touchpad.c
@@ -2438,6 +2438,145 @@ START_TEST(touchpad_dwt_key_hold)
  }
  END_TEST

+START_TEST(touchpad_dwt_key_hold_timeout)
+{
+   struct litest_device *touchpad = litest_current_device();
+   struct litest_device *keyboard;
+   struct libinput *li = touchpad->libinput;
+
+   if (!has_disable_while_typing(touchpad))
+   return;
+
+   keyboard = 

Re: [PATCH libinput] evdev: disable the mode button on the Cyborg RAT 5

[Joel Duncan]

Thanks for clearing that up, Can confirm the patch works.

udev rules were put in /usr/local/lib/udev by make command, moved to
/usr/lib/udev then devadm hwdb --update.

Looking forward to seeing this in upstream Fedora one day.

Thanks,

Joel


On Wed, Feb 3, 2016 at 9:30 PM, Peter Hutterer 
wrote:
>
> On Wed, Feb 03, 2016 at 06:47:01PM +, Joel Duncan wrote:
> >
> > Hi guys,
> >
> > Not being a libinput dev I was looking for advice on using this patch.
> > I noticed that a lot of the RAT config was in /test. After compiling the
> > driver
> > and installing it the problem still persists.
> >
> > I'm assuming it's due to needing a flag when compiling to include /test
> > components?
>
> anything in test are libinput-internal tests, you don't need them to use
> libinput.
>
> This fix relies on a udev tag applied to the mouse. So my best guess is
> that you either didn't install the udev rule/hwdb entry correctly, or that
> you didn't run sudo udevadm hwdb --update afterwards.
>
> run udevadm info /sys/class/input/eventX for whatever event node your
mouse
> has and check if the LIBINPUT_MODEL_CYBORG_RAT variable is set on the
> device. I not, then you need to check the udev rule/hwdb install.
> if it's set and it still doesn't work, the patch is buggy.
>
> Cheers,
>Peter
>
> > Any advice would be great!
> >
> > Thanks,
> >
> > Joel
> >
> > On Fri, Jan 29, 2016 at 12:48 AM, Peter Hutterer <
peter.hutte...@who-t.net>
> > wrote:
> >
> > > This button sends a release N, press N+1 on each press, cycling
through the
> > > three event codes supported. This causes a stuck button since the
current
> > > mode
> > > is never released.
> > >
> > > Long-term this better served by a set of switches that toggle
accordingly,
> > > for
> > > now disable the button codes.
> > >
> > > https://bugs.freedesktop.org/show_bug.cgi?id=92127
> > >
> > > Signed-off-by: Peter Hutterer 
> > > ---
> > >  src/evdev.c| 36 +
> > >  src/evdev.h|  1 +
> > >  test/Makefile.am   |  1 +
> > >  test/device.c  | 33 
> > >  test/litest-device-cyborg-rat-5.c  | 71
> > > ++
> > >  test/litest.c  |  2 +
> > >  test/litest.h  |  1 +
> > >  udev/90-libinput-model-quirks.hwdb |  7 
> > >  udev/90-libinput-model-quirks.rules.in |  4 ++
> > >  9 files changed, 156 insertions(+)
> > >  create mode 100644 test/litest-device-cyborg-rat-5.c
> > >
> > > diff --git a/src/evdev.c b/src/evdev.c
> > > index 8f0a607..66673a8 100644
> > > --- a/src/evdev.c
> > > +++ b/src/evdev.c
> > > @@ -1677,6 +1677,7 @@ evdev_read_model_flags(struct evdev_device
*device)
> > > { "LIBINPUT_MODEL_JUMPING_SEMI_MT",
> > > EVDEV_MODEL_JUMPING_SEMI_MT },
> > > { "LIBINPUT_MODEL_ELANTECH_TOUCHPAD",
> > > EVDEV_MODEL_ELANTECH_TOUCHPAD },
> > > { "LIBINPUT_MODEL_APPLE_INTERNAL_KEYBOARD",
> > > EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD },
> > > +   { "LIBINPUT_MODEL_CYBORG_RAT", EVDEV_MODEL_CYBORG_RAT
},
> > > { NULL, EVDEV_MODEL_DEFAULT },
> > > };
> > > const struct model_map *m = model_map;
> > > @@ -2249,6 +2250,39 @@ evdev_drain_fd(int fd)
> > > }
> > >  }
> > >
> > > +static inline void
> > > +evdev_pre_configure_model_quirks(struct evdev_device *device)
> > > +{
> > > +   /* The Cyborg RAT has a mode button that cycles through event
> > > codes.
> > > +* On press, we get a release for the current mode and a
press for
> > > the
> > > +* next mode:
> > > +* E: 0.01 0004 0004 589833 # EV_MSC / MSC_SCAN
> > >  589833
> > > +* E: 0.01 0001 0118    # EV_KEY / (null)
  0
> > > +* E: 0.01 0004 0004 589834 # EV_MSC / MSC_SCAN
> > >  589834
> > > +* E: 0.01 0001 0119 0001   # EV_KEY / (null)
  1
> > > +* E: 0.01      #  SYN_REPORT (0)
> > > -- +0ms
> > > +* E: 0.705000 0004 0004 589834 # EV_MSC / MSC_SCAN
> > >  589834
> > > +* E: 0.705000 0001 0119    # EV_KEY / (null)
  0
> > > +* E: 0.705000 0004 0004 589835 # EV_MSC / MSC_SCAN
> > >  589835
> > > +* E: 0.705000 0001 011a 0001   # EV_KEY / (null)
  1
> > > +* E: 0.705000      #  SYN_REPORT (0)
> > > -- +705ms
> > > +* E: 1.496995 0004 0004 589833 # EV_MSC / MSC_SCAN
> > >  589833
> > > +* E: 1.496995 0001 0118 0001   # EV_KEY / (null)
  1
> > > +* E: 1.496995 0004 0004 589835 # EV_MSC / MSC_SCAN
> > >  589835
> > > +* E: 1.496995 0001 011a    # EV_KEY / (null)
  0
> > > +* E: 1.496995      #  SYN_REPORT (0)
> > > -- +791ms
> > > +*
> > > +* 

Re: [PATCH libinput] evdev: disable the mode button on the Cyborg RAT 5

[Joel Duncan]

​​
Hi guys,

Not being a libinput dev I was looking for advice on using this patch.
I noticed that a lot of the RAT config was in /test. After compiling the
driver
and installing it the problem still persists.

I'm assuming it's due to needing a flag when compiling to include /test
components?

Any advice would be great!

Thanks,

Joel

On Fri, Jan 29, 2016 at 12:48 AM, Peter Hutterer 
wrote:

> This button sends a release N, press N+1 on each press, cycling through the
> three event codes supported. This causes a stuck button since the current
> mode
> is never released.
>
> Long-term this better served by a set of switches that toggle accordingly,
> for
> now disable the button codes.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=92127
>
> Signed-off-by: Peter Hutterer 
> ---
>  src/evdev.c| 36 +
>  src/evdev.h|  1 +
>  test/Makefile.am   |  1 +
>  test/device.c  | 33 
>  test/litest-device-cyborg-rat-5.c  | 71
> ++
>  test/litest.c  |  2 +
>  test/litest.h  |  1 +
>  udev/90-libinput-model-quirks.hwdb |  7 
>  udev/90-libinput-model-quirks.rules.in |  4 ++
>  9 files changed, 156 insertions(+)
>  create mode 100644 test/litest-device-cyborg-rat-5.c
>
> diff --git a/src/evdev.c b/src/evdev.c
> index 8f0a607..66673a8 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -1677,6 +1677,7 @@ evdev_read_model_flags(struct evdev_device *device)
> { "LIBINPUT_MODEL_JUMPING_SEMI_MT",
> EVDEV_MODEL_JUMPING_SEMI_MT },
> { "LIBINPUT_MODEL_ELANTECH_TOUCHPAD",
> EVDEV_MODEL_ELANTECH_TOUCHPAD },
> { "LIBINPUT_MODEL_APPLE_INTERNAL_KEYBOARD",
> EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD },
> +   { "LIBINPUT_MODEL_CYBORG_RAT", EVDEV_MODEL_CYBORG_RAT },
> { NULL, EVDEV_MODEL_DEFAULT },
> };
> const struct model_map *m = model_map;
> @@ -2249,6 +2250,39 @@ evdev_drain_fd(int fd)
> }
>  }
>
> +static inline void
> +evdev_pre_configure_model_quirks(struct evdev_device *device)
> +{
> +   /* The Cyborg RAT has a mode button that cycles through event
> codes.
> +* On press, we get a release for the current mode and a press for
> the
> +* next mode:
> +* E: 0.01 0004 0004 589833 # EV_MSC / MSC_SCAN
>  589833
> +* E: 0.01 0001 0118    # EV_KEY / (null)   0
> +* E: 0.01 0004 0004 589834 # EV_MSC / MSC_SCAN
>  589834
> +* E: 0.01 0001 0119 0001   # EV_KEY / (null)   1
> +* E: 0.01      #  SYN_REPORT (0)
> -- +0ms
> +* E: 0.705000 0004 0004 589834 # EV_MSC / MSC_SCAN
>  589834
> +* E: 0.705000 0001 0119    # EV_KEY / (null)   0
> +* E: 0.705000 0004 0004 589835 # EV_MSC / MSC_SCAN
>  589835
> +* E: 0.705000 0001 011a 0001   # EV_KEY / (null)   1
> +* E: 0.705000      #  SYN_REPORT (0)
> -- +705ms
> +* E: 1.496995 0004 0004 589833 # EV_MSC / MSC_SCAN
>  589833
> +* E: 1.496995 0001 0118 0001   # EV_KEY / (null)   1
> +* E: 1.496995 0004 0004 589835 # EV_MSC / MSC_SCAN
>  589835
> +* E: 1.496995 0001 011a    # EV_KEY / (null)   0
> +* E: 1.496995      #  SYN_REPORT (0)
> -- +791ms
> +*
> +* https://bugs.freedesktop.org/show_bug.cgi?id=92127
> +*
> +* Disable the event codes to avoid stuck buttons.
> +*/
> +   if(device->model_flags & EVDEV_MODEL_CYBORG_RAT) {
> +   libevdev_disable_event_code(device->evdev, EV_KEY, 0x118);
> +   libevdev_disable_event_code(device->evdev, EV_KEY, 0x119);
> +   libevdev_disable_event_code(device->evdev, EV_KEY, 0x11a);
> +   }
> +}
> +
>  struct evdev_device *
>  evdev_device_create(struct libinput_seat *seat,
> struct udev_device *udev_device)
> @@ -2318,6 +2352,8 @@ evdev_device_create(struct libinput_seat *seat,
> matrix_init_identity(>abs.usermatrix);
> matrix_init_identity(>abs.default_calibration);
>
> +   evdev_pre_configure_model_quirks(device);
> +
> if (evdev_configure_device(device) == -1)
> goto err;
>
> diff --git a/src/evdev.h b/src/evdev.h
> index 02b5112..8b567a8 100644
> --- a/src/evdev.h
> +++ b/src/evdev.h
> @@ -110,6 +110,7 @@ enum evdev_device_model {
> EVDEV_MODEL_ELANTECH_TOUCHPAD = (1 << 11),
> EVDEV_MODEL_LENOVO_X220_TOUCHPAD_FW81 = (1 << 12),
> EVDEV_MODEL_APPLE_INTERNAL_KEYBOARD = (1 << 13),
> +   EVDEV_MODEL_CYBORG_RAT = (1 << 14),
>  };
>
>  struct mt_slot {
> diff --git a/test/Makefile.am 

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

[Bill Spitzak]

On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre 
wrote:

> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
> perhaps it's not. This does mean that a tooltip's parent can never
> change, and a popup's parent can never change. That can help for
> getting grab semantics right, though it might be an idea if we say
> that set_parent on a popup / tooltip simply emit error if a parent is
> already set. I'm -1 to that, though.
>

xdg_toplevel *must* support the ability to change the parent. It is
impossible to get correct floating windows unless the parent can be set to
a surface that may not exist at the moment the floating surface is first
created (imagine a surface that must float above all opened documents, and
the user can create/destroy documents at will without closing the floating
surface).

Less importantly, setting the parent will avoid the need for a complex
directed acyclic graph api with multiple parents per surface, and avoid
more api to determine whether a parent's mapping controls the mapping of
the child. The client can keep track of which parent is the highest and
only tell the compositor about that, changing as necessary before any
request that will change the stacking order.

I think it is ok if some roles, like tooltip, do not allow the parent to be
changed. But the basic class must.


> Some think that wl_surface.attach's coordinates are confusing and
> built poorly, and I am inclined to agree, however, when I wrote the
> original get_xdg_popup, I simply forgot about them. It might be that
> we do positioning on first-attach, and we say that the tooltip is
> defined to be 0,0 relative to the surface. That is an idea, though I'm
> +0 on it.
>

The toolkits will hide this. I would agree that defining the delta to be
from 0,0 for the initial attach, in cases where the position is usable on
first attach, is a good idea.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v3 wayland-protocols] Add the tablet protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 2:37 PM, Jason Gerecke  wrote:

>
> > I think a lot of software treats the tilt information as actually the
> > position of a point some distance up the pen relative to the tip. I would
>
> That's certainly true for GIMP and Krita at least (see [1] and [2]).
> Its incorrect, but its "close enough" that nobody seems to complain
> (though I've been tempted to in the past ;))
>
> > guess the hardware produces this directly (by reusing the proximity
> hardware
> > for a different point higher up in the pen). To get a projection of the
> pen
> > onto the tablet surface, these values can be fed to atan2.
> >
> > If they were actual angles, they must be the angle of the projection of
> the
> > pen onto the two vertical planes of the x and y axis. This is really
> noisy
> > when the pen is near one of the axis, and I would think the
> hardware/driver
> > could not produce this except by calculating atan2 of a more linear
> value.
> >
> > Therefore I would be very suspicious of any claim that the values being
> > produced are angles. The current api reporting them as normalized values
> > seems better.
> >
>
> I've been down this road before a few years back. Does the hardware
> measure and report true angles or does it measure a projection? If its
> a projection, does it report them directly, or does it calculate
> sin^-1 to transform it into an angle?
>
> In the end, the specs from the firmware guys say to interpret the data
> as measured in degrees, so that's what we do.
>
> [1]:
> https://git.gnome.org/browse/gimp/tree/app/core/gimpdynamicsoutput.c#n548
> [2]:
> https://github.com/KDE/krita/blob/master/libs/image/brushengine/kis_paint_information.cc#L507


 Actually it certainly cannot be any angle of a plane the pen is in, as the
atan2 data would not work and get quite incorrect when the pen is tilted
close to a horizontal axis. Though if Gimp is producing very strange angles
when the pen is nearly horizontal along one axis this may indicate that it
really is an angle. For instance if tilting the pen parallel to the x axis
produces angles more like 45 degrees.

Say some point on the pen is at x,y,z relative to the tip.

Possible values for the y tilt are (in order from best to worst imho):

y/D (where D == |x,y,z|). This goes to 1.0 as the pen is tilted horizontal.
atan2(ytilt, xtilt) == atan2(y/D, x/D) == atan2(y, x) and produces the
correct angle.

y/z: This value goes to infinity as the pen is tilted horizontal.
atan2(ytilt, xtilt) == atan2(y/z, x/z) == atan2(y, x) and thus gets the xy
angle exactly right.

atan(y/z): This would be the actual angle of the plane containing the pen
and x axis projected onto the yz plane. The correct xy angle is then
atan2(sin(ytilt),sin(xtilt)) == atan2(y/z, x/z) == atan2(y, x).
atan2(ytilt,xtilt) would have significant errors if the magnitude of xtilt
and ytilt are different.

asin(y/D) could be produced by somebody thinking they know how to convert y
to an angle, but it does not correspond to any actual angle of the pen. The
correct xy angle is again produced by atan2(sin(ytilt),sin(xtilt)) ==
atan2(y/D, x/D) == atan2(y, x), and doing atan2(ytilt,xtilt) would have the
same errors.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 4:58 AM, Jan Arne Petersen  wrote:

>
>
> On 29/01/16 00:33, Bill Spitzak wrote:
> >
> >
> > On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen  > > wrote:
> >
> >
> > +  Text is generally UTF-8 encoded, indices and lengths are in
> > bytes.
> >
> >
> > Remove the word "generally". *All* text in your api's are UTF-8.
>
> Done
>
> > +
> > +  
> > +   Requests to activate a surface for text input (typically
> when a
> > +   text entry in it gets focus).
> > +
> > +   There can only be one active surface per client and seat.
> > When surface is
> > +   null all surfaces of the client get deactivated.
> > +  
> >
> >
> > I think clients should be allowed to send activate more than once per
> > surface, it is to indicate the input focus switching between widgets.
> > This removes the need for another api to indicate the widget is
> > switching. Sending null for the surface, or a different event, would
> > indicate that the keyboard focus is no longer on a text input widget.
>
> We use enable/disable request now. That should be a bit easier to handle
> from client side.
>
> > +
> > +  
> > +   Should be called by an editor widget when the input state
> > should be
> > +   reset, for example after the text was changed outside of the
> > normal
> > +   input method flow.
> > +  
> > +
> >
> >
> > I believe this request can be replaced by redundant activate requests.
>
> It got integrated into update_state.
>
> > +
> > +  
> > +   Sets the plain surrounding text around the input position.
> > Text is
> > +   UTF-8 encoded. Cursor is the byte offset within the
> > +   surrounding text. Anchor is the byte offset of the
> > +   selection anchor within the surrounding text. If there is no
> > selected
> > +   text anchor is the same as cursor.
> > +  
> > +  
> > +  
> > +  
> > +
> >
> >
> > The anchor could be very far away from the cursor, much farther than any
> > small limit on the request size. I think this means the anchor position
> > could be negative or larger than the text length. Sending this without
> > clamping would be a good idea, the input method would then have a hint
> > where the anchor is, and it can clamp the value itself.
> >
> > If the client wants new text to replace the selected text, the text
> > between anchor+cursor will be deleted, and any input method decisions
> > would depend on the text outside the anchor..cursor range. This may be
> > larger than the allowed buffer size, so I think clients have to send the
> > text as though the selection was deleted.
> >
> > A client that does not want to replace the selected text could still
> > send an anchor, but then I am not clear if the input method can take
> > advantage of knowing what characters are selected to modify the results.
> > So it is possible the anchor is not needed at all.
>
> Ok I use an int for anchor now. It still make sense for an input method
> to know what is in the selection even when it gets replaced by new
> entered text.
>

I am unclear whether it is the input method's job to decide whether
characters replace the selection, or the client's job.

My concern is this:

- The input method has rules so that if the text before the cursor is "A"
and the user types 'x', you get "Ay". If the text is any other letter such
as "C" you get "Cx".

- Assume the text before the cursor is "An" where all the 'n' are
selected, and the length of the selection exceeds the size allowed by the
surrounding text request. Therefore the input method cannot know there is
an 'A' there.

- The user types 'x'. The input method cannot be aware that there is an A
there and the result will be "Ax", not the correct "Ay".

My proposed solution is that the client decides whether input replaces the
selection or is appended to it. If it replaces the selection, the text it
sends the input method is with the selection already deleted.

Other solution is that the above situation does not happen in real input
methods.

>
> > I think you might want non-zero bits to *disable* features. This allows
> > zero to be the default, and means that if some new correction is
> > invented in the future then they can default to on without you having to
> > modify the numerical value of default.
>
> Toolkits need to handle default on client side now.
>

I'm concerned that the value of "default" should not change. Assuming most
toolkits choose default, it should not vary depending on when the toolkit
was compiled.


> Yes you do not want to show already typed text on a virtual keyboard in
> a password field. Usually the keyboard would show nothing then, no
> reason to show dots/stars on the virtual keyboard.
>

I would assume it is considered 

Re: [PATCH v2 weston 05/13] tablet: handle tablet cursors in the compositor

[Bill Spitzak]

I don't understand this, it seems very redundant with what you propose to
put into the compositor. As far as I can tell, you already require the
compositor to hide the cursor when the tool leaves proximity and to choose
the last-set cursor when a tool enters proximity.

Seems to me your proximity_out handler therefore does not have to do
anything, and toytoolkit does not have to remember any cursors. The client,
if it wants, can set the cursor on proximity-in. Or not set it. Whatever.

It this is wrong them I am very confused as to why you had to add so much
code to the compositor to manager per-tool cursors. You could instead just
reuse the seat cursor, since you seem to have the client setting the cursor
on every proximity-in and out.

On Tue, Feb 2, 2016 at 9:28 PM, Peter Hutterer 
wrote:

> From: Stephen Chandler Paul 
>
> The tablet is given a separate cursor. Most tablet interaction is an
> absolute
> interaction and shouldn't need a cursor at all, but usually the cursor is
> used
> to indicate the type of virtual tool currently assigned.
>
> Co-authored-by: Peter Hutterer 
> Signed-off-by: Stephen Chandler Paul 
> Signed-off-by: Peter Hutterer 
> ---
>  src/compositor.c |   6 +++
>  src/compositor.h |  13 +
>  src/input.c  | 157
> ++-
>  3 files changed, 175 insertions(+), 1 deletion(-)
>
> diff --git a/src/compositor.c b/src/compositor.c
> index cbdb14c..f419818 100644
> --- a/src/compositor.c
> +++ b/src/compositor.c
> @@ -1866,6 +1866,7 @@ weston_view_unmap(struct weston_view *view)
> struct weston_pointer *pointer =
> weston_seat_get_pointer(seat);
> struct weston_keyboard *keyboard =
> weston_seat_get_keyboard(seat);
> +   struct weston_tablet_tool *tool;
>
> if (keyboard && keyboard->focus == view->surface)
> weston_keyboard_set_focus(keyboard, NULL);
> @@ -1873,6 +1874,11 @@ weston_view_unmap(struct weston_view *view)
> weston_pointer_clear_focus(pointer);
> if (touch && touch->focus == view)
> weston_touch_set_focus(touch, NULL);
> +
> +   wl_list_for_each(tool, >tablet_tool_list, link) {
> +   if (tool->focus == view)
> +   weston_tablet_tool_set_focus(tool, NULL,
> 0);
> +   }
> }
>  }
>
> diff --git a/src/compositor.h b/src/compositor.h
> index 784a70d..7960325 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -470,6 +470,12 @@ struct weston_tablet_tool {
>
> int button_count;
> bool tip_is_down;
> +
> +   int32_t hotspot_x, hotspot_y;
> +   struct weston_view *sprite;
> +   struct wl_listener sprite_destroy_listener;
> +
> +   wl_fixed_t x, y;
>  };
>
>  struct weston_tablet {
> @@ -580,6 +586,13 @@ void
>  weston_tablet_tool_end_grab(struct weston_tablet_tool *tool);
>
>  void
> +weston_tablet_tool_clamp(struct weston_tablet_tool *tool,
> +wl_fixed_t *fx, wl_fixed_t *fy);
> +void
> +weston_tablet_tool_cursor_move(struct weston_tablet_tool *tool,
> +  wl_fixed_t x, wl_fixed_t y);
> +
> +void
>  wl_data_device_set_keyboard_focus(struct weston_seat *seat);
>
>  int
> diff --git a/src/input.c b/src/input.c
> index 006ab5a..fc74856 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -974,7 +974,13 @@ static void
>  default_grab_tablet_tool_proximity_out(struct weston_tablet_tool_grab
> *grab,
>uint32_t time)
>  {
> -   weston_tablet_tool_set_focus(grab->tool, NULL, time);
> +   struct weston_tablet_tool *tool = grab->tool;
> +
> +   weston_tablet_tool_set_focus(tool, NULL, time);
> +
> +   /* Hide the cursor */
> +   if (weston_surface_is_mapped(tool->sprite->surface))
> +   weston_surface_unmap(tool->sprite->surface);
>  }
>
>  static void
> @@ -989,6 +995,8 @@ default_grab_tablet_tool_motion(struct
> weston_tablet_tool_grab *grab,
> struct wl_resource *resource;
> struct wl_list *resource_list = >focus_resource_list;
>
> +   weston_tablet_tool_cursor_move(tool, x, y);
> +
> current_view = weston_compositor_pick_view(tool->seat->compositor,
>x, y, , );
> if (current_view != tool->focus)
> @@ -1126,6 +1134,29 @@ static struct weston_tablet_tool_grab_interface
> default_tablet_tool_grab_interfa
> default_grab_tablet_tool_cancel,
>  };
>
> +static void
> +tablet_tool_unmap_sprite(struct weston_tablet_tool *tool)
> +{
> +   if (weston_surface_is_mapped(tool->sprite->surface))
> +   weston_surface_unmap(tool->sprite->surface);
> +
> +   wl_list_remove(>sprite_destroy_listener.link);
> + 

RE: [PATCH weston] hmi-controller: remove duplicate commit_changes in random mode

[Ucan, Emre (ADITG/SW1)]

Hi Pekka,

I am for removing the remaining bits of code which is wrongly assuming that a 
surface can be shown in multiple layers.

 Afterwards we have to redesign a big part of ivi_layout API to support this 
feauture.

My ideas for the redesign so far:
The most basic approach would be that an ivi_surface would have a weston_view 
for every layer/screen combination.
But ivi_layout API does not make much sense than. Because when controller calls 
ivi_layout_surface_set_destination_rectangle,
should we scale all views ? I think it does not make sense to scale all views. 
Therefore, the set APIs should be changed to get ivi_views and not ivi_surfaces.
This would mean:

- Modifying every ivi_layout_surface_set* API
- Implementing new APIs to get layer/screen specific ivi_views for a given 
ivi_surface
- ivi-layers should list ivi_views and not ivi_surfaces
- The implementation of commit_changes should be updated accordingly.

I am planning to do all these changes, but at first we can remove old code. 
Because it is very unlikely that we can reuse.

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Pekka Paalanen
Sent: Dienstag, 2. Februar 2016 16:43
To: Nobuhiko Tanibata
Cc: securitych...@denso.co.jp; Natsume, Wataru (ADITJ/SWG); 
wayland-devel@lists.freedesktop.org
Subject: Re: [PATCH weston] hmi-controller: remove duplicate commit_changes in 
random mode

Hi,

I don't think this patch is ready to be merged, more below.

TL;DR: It would probably be best to just ignore which ivilayer an ivisurface is 
currently on, and always just remove and add. That would be the simplest 
solution, if the ivilayout API just allows it.

Specifically, do not clear the layer's surface list in advance. Just go over 
each surface and reassign the layer for it. Then doing a single
commit_changes() in the end will ensure that ivisurfaces get atomically moved 
from layer to layer as appropriate, and there won't be any multiple assignments.


On Fri, 25 Dec 2015 13:47:15 +0900
Nobuhiko Tanibata  wrote:

> From: Nobuhiko Tanibata 
> 
> Previous code cleaned up surfaces in layer once and then added 
> surfaces to a layer in random. In this flow, two commitchanges are required.
> 
> This patch proposes that it avoids calling add_surface if a surface is 
> already added to a layer in random. In this flow, cleaning up surfaces 
> is not required.
> 
> Signed-off-by: Nobuhiko Tanibata 
> ---
>  ivi-shell/hmi-controller.c | 25 -
>  1 file changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c 
> index 77426bc..8a81f5c 100644
> --- a/ivi-shell/hmi-controller.c
> +++ b/ivi-shell/hmi-controller.c
> @@ -418,24 +418,18 @@ mode_random_replace(struct hmi_controller *hmi_ctrl,
>   struct ivi_layout_surface *ivisurf  = NULL;
>   const uint32_t duration = hmi_ctrl->hmi_setting->transition_duration;
>   int32_t i = 0;
> + int32_t j = 0;
>   int32_t layer_idx = 0;
> + int32_t surface_len_on_layer = 0;
> + struct ivi_layout_surface **ivisurfs = NULL;
>  
>   layers = MEM_ALLOC(sizeof(*layers) * hmi_ctrl->screen_num);
>  
>   wl_list_for_each(application_layer, layer_list, link) {
>   layers[layer_idx] = application_layer;
> - 
> ivi_layout_interface->layer_set_render_order(layers[layer_idx]->ivilayer,
> - NULL, 0);
>   layer_idx++;
>   }
>  
> - /*
> -  * This commit change is needed because ivisurface can not belongs to 
> several layers
> -  * at the same time. So ivisurfaces shall be removed from layers once 
> and then set them
> -  * to layers randomly.
> -  */
> - ivi_layout_interface->commit_changes();

This is a lengthy side-comment that came to my mind while looking at the code:

An ivisurface indeed cannot belong to several layers at the same time, but I 
don't think that would happen (break anything) even if you literally removed 
only this commit_changes() call.

That is because the staging list (ivi_layout_surface::pending) and the current 
list (ivi_layout_surface::order) are separate. I believe it is fine to have an 
ivi_layout_surface on one layer in the current list and on a different layer in 
the staging list. You have to make that work anyway, because it is the only way 
to move an ivisurface from one layer to another without potentially causing it 
to disappear from the screen in between.

When the connecting structures, that were meant to allow an ivisurface to be on 
several layers, were removed, the code automatically became such that it 
naturally avoids attempting to have an ivisurface on multiple layers, even if 
you tried to do that from the 

Re: [PATCH wayland-protocols] text: Create second version of text input protocol

[Bill Spitzak]

On Tue, Feb 2, 2016 at 5:02 AM, Jan Arne Petersen  wrote:

>
> > Besides allowing the user to return to a misspelled word, it may make
> > sense to return to a preedit. I'm not sure as I have no experience with
> > Asian input methods. But it does seem possible.
>
> Sorry no toolkit supports that. While the current proposed protocol can
> be implemented with current Qt, Gtk+ and EFL. Androids input method API
> is also quite similar to what is proposed here.
>

I'm sorry but I am familiar toolkits that allow the user to return to a
previously misspelled word and invoke the spelling corrector. My browser is
right now drawing squiqqly red lines under "toolkits" and "squiggly".

This means that the "incorrect" highlighting has to be preserved from the
preedit string. I think the easiest way to do this is to merge the commit
and preedit apis, so an input method can commit highlighting. This means it
can commit any preedit string. I guess the client can leave the
highlighting or remove it depending on the client limitations. Returning to
preedit can only work if the preedit state can be determined from the
characters alone, as there is no method for the client to send the
highlighting or previous preedit range to the input method.

I find it difficult to imagine an implementation that is capable of showing
the preedit string yet unable to commit it, so I don't see how any toolkit
could not support this, unless it cannot show spelling error highlight
unless the cursor is right next to them.

I may be misunderstanding how you intend spelling correction / completion
to work, however.

Delete surrounding text also works for pre-edit, i fixed the documentation.
>

I was curious how you intend for it to indicate a misspelling when the
input method is adding a space after a word that may have been typed
previously. Two methods I can think of are to have it delete the entire
word and replace it with the same word with the incorrect highlighting, or
to allow the incorrect highlighting range to be outside the preedit string
and include bytes already in the buffer.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 weston 07/13] client: Add tablet cursor support into libtoytoolkit

[Bill Spitzak]

Does toytoolkit really need to support animated cursors?

If so it would be nice to animate the normal cursor, too, and perhaps
demonstrate code reuse for this.


On Tue, Feb 2, 2016 at 9:28 PM, Peter Hutterer 
wrote:

> From: Stephen Chandler Paul 
>
> Again, a lot of this is code that has been reused from the cursor code
> for pointers.
>
> Co-authored-by: Peter Hutterer 
> Signed-off-by: Stephen Chandler Paul 
> Signed-off-by: Peter Hutterer 
> ---
>  clients/window.c | 138
> ++-
>  clients/window.h |  13 --
>  2 files changed, 145 insertions(+), 6 deletions(-)
>
> diff --git a/clients/window.c b/clients/window.c
> index 37c703b..26c2593 100644
> --- a/clients/window.c
> +++ b/clients/window.c
> @@ -159,6 +159,12 @@ struct tablet_tool {
> struct tablet *current_tablet;
> struct window *focus;
> struct widget *focus_widget;
> +   uint32_t enter_serial;
> +   uint32_t cursor_serial;
> +   int current_cursor;
> +   struct wl_surface *cursor_surface;
> +   uint32_t cursor_anim_start;
> +   struct wl_callback *cursor_frame_cb;
>
> enum zwp_tablet_tool_v1_type type;
> uint64_t serial;
> @@ -332,6 +338,7 @@ struct widget {
> int opaque;
> int tooltip_count;
> int default_cursor;
> +   int default_tablet_cursor;
> /* If this is set to false then no cairo surface will be
>  * created before redrawing the surface. This is useful if the
>  * redraw handler is going to do completely custom rendering
> @@ -1676,6 +1683,7 @@ widget_create(struct window *window, struct surface
> *surface, void *data)
> widget->tooltip = NULL;
> widget->tooltip_count = 0;
> widget->default_cursor = CURSOR_LEFT_PTR;
> +   widget->default_tablet_cursor = CURSOR_LEFT_PTR;
> widget->use_cairo = 1;
>
> return widget;
> @@ -1734,6 +1742,12 @@ widget_set_default_cursor(struct widget *widget,
> int cursor)
>  }
>
>  void
> +widget_set_default_tablet_cursor(struct widget *widget, int cursor)
> +{
> +   widget->default_tablet_cursor = cursor;
> +}
> +
> +void
>  widget_get_allocation(struct widget *widget, struct rectangle *allocation)
>  {
> *allocation = widget->allocation;
> @@ -5667,6 +5681,117 @@ tablet_tool_handle_removed(void *data, struct
> zwp_tablet_tool_v1 *zwp_tablet_too
> zwp_tablet_tool_v1_destroy(zwp_tablet_tool_v1);
>  }
>
> +static const struct wl_callback_listener
> tablet_tool_cursor_surface_listener;
> +
> +static void
> +tablet_tool_set_cursor_image_index(struct tablet_tool *tool, int index)
> +{
> +   struct wl_buffer *buffer;
> +   struct wl_cursor *cursor;
> +   struct wl_cursor_image *image;
> +
> +   cursor = tool->input->display->cursors[tool->current_cursor];
> +   if (index >= (int)cursor->image_count) {
> +   fprintf(stderr, "cursor index out of range\n");
> +   return;
> +   }
> +
> +   image = cursor->images[index];
> +   buffer = wl_cursor_image_get_buffer(image);
> +   if (!buffer)
> +   return;
> +
> +   wl_surface_attach(tool->cursor_surface, buffer, 0, 0);
> +   wl_surface_damage(tool->cursor_surface, 0, 0,
> + image->width, image->height);
> +   wl_surface_commit(tool->cursor_surface);
> +   zwp_tablet_tool_v1_set_cursor(tool->tool, tool->enter_serial,
> + tool->cursor_surface,
> + image->hotspot_x, image->hotspot_y);
> +}
> +
> +static void
> +tablet_tool_surface_frame_callback(void *data, struct wl_callback
> *callback,
> +  uint32_t time)
> +{
> +   struct tablet_tool *tool = data;
> +   struct wl_cursor *cursor;
> +   int i;
> +
> +   if (callback) {
> +   assert(callback == tool->cursor_frame_cb);
> +   wl_callback_destroy(callback);
> +   tool->cursor_frame_cb = NULL;
> +   }
> +
> +   if (tool->current_cursor == CURSOR_BLANK) {
> +   zwp_tablet_tool_v1_set_cursor(tool->tool,
> tool->enter_serial,
> + NULL, 0, 0);
> +   return;
> +   }
> +
> +   if (tool->current_cursor == CURSOR_UNSET)
> +   return;
> +
> +   cursor = tool->input->display->cursors[tool->current_cursor];
> +   if (!cursor)
> +   return;
> +
> +   /* FIXME We don't have the current time on the first call so we set
> +* the animation start to the time of the first frame callback. */
> +   if (time == 0)
> +   tool->cursor_anim_start = 0;
> +   else if (tool->cursor_anim_start == 0)
> +   tool->cursor_anim_start = time;
> +
> +   if (time == 0 || 

Re: [PATCH wayland-protocols v2] xdg-shell: Introduce xdg_tooltip

[Bill Spitzak]

On Wed, Feb 3, 2016 at 1:05 PM, Jasper St. Pierre 
wrote:

> On Wed, Feb 3, 2016 at 1:00 PM, Bill Spitzak  wrote:
> >
> >
> > On Wed, Feb 3, 2016 at 11:36 AM, Jasper St. Pierre <
> jstpie...@mecheye.net>
> > wrote:
> >>
> >> set_parent was moved to xdg_toplevel. Perhaps that's a good idea,
> >> perhaps it's not. This does mean that a tooltip's parent can never
> >> change, and a popup's parent can never change. That can help for
> >> getting grab semantics right, though it might be an idea if we say
> >> that set_parent on a popup / tooltip simply emit error if a parent is
> >> already set. I'm -1 to that, though.
> >
> >
> > xdg_toplevel *must* support the ability to change the parent.
>
> Somehow I get the feeling you're not even reading the words I'm
> writing. xdg_toplevel still has a set_parent method, I said it was
> moved *to* xdg_toplevel.
>

Sorry I am confused then as to what the text "This does mean that a
tooltip's parent can never change, and a popup's parent can never change".
I think I misread it as "if we use xdg_surface set_parent, you cannot
change the parent", thus implying that xdg_surface set_parent cannot change
it. I think what you actually meant was "the current scheme does not allow
you to change the parent, this proposal *does* allow the parent to change".

If there are problems with making the grabs work, I think it is ok if
attempting to change the parent is either an error or ignored for surfaces
with the popup role.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols V3] Add Primary Selection Protocol Version 1

[Carlos Garnacho]

Hi!,

Chiming in late...

On Thu, Jan 7, 2016 at 3:50 AM, Lyude  wrote:
> Signed-off-by: Lyude 
> ---
>
> Notes:
> Changes since V2
> * Bunch of grammatical/wording fixes from whot
> * Addition of wp_primary_selection_offer::end_offers, for marking the end 
> of a
>   list of mime type offers
> * selection_offers are no longer sent before an input event, and are sent 
> at the
>   first opportunity a client has to do a primary selection paste. This 
> decision
>   comes from a discussion with Jasper, where a couple of clients (such as 
> emacs)
>   were brought up that have their own bindings for primary selection 
> pasting.
>   Eventually I will probably work on adding some sort of paste_hint event 
> to
>   this so that the compositor can decide what keybinding triggers a 
> primary
>   selection paste, I agree with Jasper that it would be best to solve the 
> issue
>   of rebinding primary selection pastes after we have the basic protocol 
> for
>   primary selection worked out.
>
>  Makefile.am|   1 +
>  unstable/primary-selection/README  |   4 +
>  .../primary-selection-unstable-v1.xml  | 176 
> +
>  3 files changed, 181 insertions(+)
>  create mode 100644 unstable/primary-selection/README
>  create mode 100644 
> unstable/primary-selection/primary-selection-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..582a49e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols =  
>   \
> unstable/text-input/text-input-unstable-v1.xml
>   \
> unstable/input-method/input-method-unstable-v1.xml
>   \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml  
>   \
> +   unstable/primary-selection/primary-selection-unstable-v1.xml  
>   \
> $(NULL)
>
>  nobase_dist_pkgdata_DATA =   
>   \
> diff --git a/unstable/primary-selection/README 
> b/unstable/primary-selection/README
> new file mode 100644
> index 000..2dfce3d
> --- /dev/null
> +++ b/unstable/primary-selection/README
> @@ -0,0 +1,4 @@
> +Primary selection protocol
> +
> +Maintainers:
> +Lyude 
> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml 
> b/unstable/primary-selection/primary-selection-unstable-v1.xml
> new file mode 100644
> index 000..057ba38
> --- /dev/null
> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml
> @@ -0,0 +1,176 @@
> +
> +
> +
> +  
> +Copyright © 2015 Red Hat
> +
> +Permission is hereby granted, free of charge, to any person obtaining a
> +copy of this software and associated documentation files (the 
> "Software"),
> +to deal in the Software without restriction, including without limitation
> +the rights to use, copy, modify, merge, publish, distribute, sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the next
> +paragraph) shall be included in all copies or substantial portions of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
> OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR 
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  Provides the ability to have a primary selection device to match that 
> of
> +  the X server. This allows users to select bodies of text, and then 
> paste
> +  them in another buffer without having to do the initial copy.
> +
> +  The primary selection device manager is also in charge of handling
> +  client's requests to indicate that text has been selected, along with
> +  handling clients access to selected text.
> +
> +
> +
> +  
> +Create a new primary selection source.
> +  
> +   interface="zwp_primary_selection_source_v1"/>
> +
> +
> +
> +  
> +Singleton global object that manages the 
> zwp_primary_selection_device_v1
> +objects for each wl_seat.
> +  
> +   interface="zwp_primary_selection_device_v1"/>
> +  
> +

The name of these two requests feel a bit redundant, they end up in:

[PATCH] cosmetic: use tabs instead of spaces

[Sergi Granell]

---
 src/wayland-util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wayland-util.c b/src/wayland-util.c
index 3f95877..748476a 100644
--- a/src/wayland-util.c
+++ b/src/wayland-util.c
@@ -123,7 +123,7 @@ wl_array_add(struct wl_array *array, size_t size)
if (array->alloc < alloc) {
if (array->alloc > 0)
data = realloc(array->data, alloc);
-   else
+   else
data = malloc(alloc);
 
if (data == NULL)
-- 
2.7.0

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

[PATCH] cosmetic: add an space after if

[Sergi Granell]

---
 src/wayland-shm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/wayland-shm.c b/src/wayland-shm.c
index 8e7adc9..a4343a4 100644
--- a/src/wayland-shm.c
+++ b/src/wayland-shm.c
@@ -117,7 +117,7 @@ format_is_supported(struct wl_client *client, uint32_t 
format)
default:
formats = wl_display_get_additional_shm_formats(display);
wl_array_for_each(p, formats)
-   if(*p == format)
+   if (*p == format)
return true;
}
 
-- 
2.7.0

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

Re: [PATCH] xwayland: Clear pending cursor frame callbacks on pointer enter

[Pekka Paalanen]

On Wed,  3 Feb 2016 16:14:09 +0100
Rui Matos  wrote:

> The last cursor frame we commited before the pointer left one of our
> surfaces might not have been shown. In that case we'll have a cursor
> surface frame callback pending which we need to clear so that we can
> continue submitting new cursor frames.
> 
> Signed-off-by: Rui Matos 
> ---
> 
> On Wed, Feb 3, 2016 at 9:30 AM, Pekka Paalanen  wrote:
> > Xwayland commits a wl_buffer to a cursor wl_surface with a frame
> > callback, and the frame callback may never be emitted by the
> > compositor, right?
> >
> > Is Xwayland waiting for any previous frame callback to be signalled
> > before it commits a buffer or re-sets the cursor role on the
> > wl_surface? Even if the commit and re-set is caused by wl_pointer.enter?
> >
> > Would it be a better fix to destroy any pending frame callback and
> > commit and re-set the role unconditionally on wl_pointer.enter?  
> 
> Yes, this seems like the proper fix indeed. Thanks,
> 
> Rui
> 
>  hw/xwayland/xwayland-input.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c
> index 61ca70b..f9e3255 100644
> --- a/hw/xwayland/xwayland-input.c
> +++ b/hw/xwayland/xwayland-input.c
> @@ -267,6 +267,16 @@ pointer_handle_enter(void *data, struct wl_pointer 
> *pointer,
>  for (i = 0; i < dev->button->numButtons; i++)
>  if (BitIsOn(dev->button->down, i))
>  QueuePointerEvents(dev, ButtonRelease, i, 0, );
> +
> +/* The last cursor frame we commited before the pointer left one
> + * of our surfaces might not have been shown. In that case we'll
> + * have a cursor surface frame callback pending which we need to
> + * clear so that we can continue submitting new cursor frames. */
> +if (xwl_seat->cursor_frame_cb) {
> +wl_callback_destroy(xwl_seat->cursor_frame_cb);
> +xwl_seat->cursor_frame_cb = NULL;
> +xwl_seat_set_cursor(xwl_seat);
> +}
>  }

Hi,

this idea looks fine to me, so consider this:
Acked-by: Pekka Paalanen 

I have to leave the actual review of xserver code for others.


Thanks,
pq


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