[PATCH libinput] touchpad: remove software middle button when emulation is enabled

[Peter Hutterer]

Expose the middle button emulation on software buttons as proper config
option. When enabled, remove the middle button software button area.

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

Signed-off-by: Peter Hutterer 
---
 doc/clickpad-softbuttons.dox|   4 +
 src/evdev-middle-button.c   |   6 +-
 src/evdev-mt-touchpad-buttons.c |  92 +++-
 src/evdev-mt-touchpad.c |   2 +
 src/evdev-mt-touchpad.h |   3 +
 src/evdev.h |   9 ++
 src/libinput.h  |   4 +
 test/litest.h   |  26 +
 test/pointer.c  |  16 +--
 test/touchpad-buttons.c | 233 
 10 files changed, 382 insertions(+), 13 deletions(-)

diff --git a/doc/clickpad-softbuttons.dox b/doc/clickpad-softbuttons.dox
index cf4c8c9..ec0381e 100644
--- a/doc/clickpad-softbuttons.dox
+++ b/doc/clickpad-softbuttons.dox
@@ -37,6 +37,10 @@ location of the button is not visibly obvious.
 
 @image html software-buttons.svg "Left, right and middle-button click with 
software button areas"
 
+@note If middle button emulation is enabled on a clickpad, only left and right
+button areas are available. For more details, see
+libinput_device_config_middle_emulation_set_enabled().
+
 If fingers are down in the main area in addition to fingers in the
 left or right button area, those fingers are are ignored.
 A release event always releases the buttons logically down, regardless of
diff --git a/src/evdev-middle-button.c b/src/evdev-middle-button.c
index 48650a4..09f77de 100644
--- a/src/evdev-middle-button.c
+++ b/src/evdev-middle-button.c
@@ -643,7 +643,7 @@ evdev_middlebutton_handle_timeout(uint64_t now, void *data)
evdev_middlebutton_handle_event(device, now, 
MIDDLEBUTTON_EVENT_TIMEOUT);
 }
 
-static int
+int
 evdev_middlebutton_is_available(struct libinput_device *device)
 {
return 1;
@@ -671,7 +671,7 @@ evdev_middlebutton_set(struct libinput_device *device,
return LIBINPUT_CONFIG_STATUS_SUCCESS;
 }
 
-static enum libinput_config_middle_emulation_state
+enum libinput_config_middle_emulation_state
 evdev_middlebutton_get(struct libinput_device *device)
 {
struct evdev_device *evdev = (struct evdev_device*)device;
@@ -681,7 +681,7 @@ evdev_middlebutton_get(struct libinput_device *device)
LIBINPUT_CONFIG_MIDDLE_EMULATION_DISABLED;
 }
 
-static enum libinput_config_middle_emulation_state
+enum libinput_config_middle_emulation_state
 evdev_middlebutton_get_default(struct libinput_device *device)
 {
struct evdev_device *evdev = (struct evdev_device*)device;
diff --git a/src/evdev-mt-touchpad-buttons.c b/src/evdev-mt-touchpad-buttons.c
index a9b7521..a2f3121 100644
--- a/src/evdev-mt-touchpad-buttons.c
+++ b/src/evdev-mt-touchpad-buttons.c
@@ -564,6 +564,13 @@ tp_init_softbuttons(struct tp_dispatch *tp,
tp->buttons.bottom_area.top_edge = height * .85 + yoffset;
}
 
+   tp->buttons.bottom_area.middlebutton_left_edge = INT_MAX;
+   tp->buttons.bottom_area.rightbutton_left_edge = width/2 + xoffset;
+
+   /* if middlebutton emulation is enabled, don't init a software area */
+   if (device->middlebutton.want_enabled)
+   return;
+
/* The middle button is 25% of the touchpad and centered. Many
 * touchpads don't have markings for the middle button at all so we
 * need to make it big enough to reliably hit it but not too big so
@@ -699,6 +706,80 @@ tp_button_config_click_get_default_method(struct 
libinput_device *device)
return tp_click_get_default_method(tp);
 }
 
+void
+tp_clickpad_middlebutton_apply_config(struct evdev_device *device)
+{
+   struct tp_dispatch *tp = (struct tp_dispatch*)device->dispatch;
+
+   if (!tp->buttons.is_clickpad ||
+   tp->buttons.state != 0)
+   return;
+
+   if (device->middlebutton.want_enabled ==
+   device->middlebutton.enabled)
+   return;
+
+   device->middlebutton.enabled = device->middlebutton.want_enabled;
+   if (tp->buttons.click_method ==
+   LIBINPUT_CONFIG_CLICK_METHOD_BUTTON_AREAS)
+   tp_init_softbuttons(tp, device);
+}
+
+static int
+tp_clickpad_middlebutton_is_available(struct libinput_device *device)
+{
+   return evdev_middlebutton_is_available(device);
+}
+
+static enum libinput_config_status
+tp_clickpad_middlebutton_set(struct libinput_device *device,
+enum libinput_config_middle_emulation_state enable)
+{
+   struct evdev_device *evdev = (struct evdev_device*)device;
+
+   switch (enable) {
+   case LIBINPUT_CONFIG_MIDDLE_EMULATION_ENABLED:
+   evdev->middlebutton.want_enabled = true;
+   break;
+   case LIBINPUT_CONFIG_MIDDLE_EMULATION_DISABLED:
+   evdev->middlebutton.want_enabled = false;
+   break;
+   default:
+   

Re: [PATCH wayland-web 1/1] html: Remove trailing whitespace

[Jonas Ådahl]

On Thu, Jun 30, 2016 at 03:38:44PM -0700, Yong Bakos wrote:
> On Jun 30, 2016, at 3:12 AM, Pekka Paalanen  wrote:
> > 
> > On Tue, 28 Jun 2016 08:52:33 -0500
> > Yong Bakos  wrote:
> > 
> >> From: Yong Bakos 
> >> 
> >> The html files contain trailing whitespace, which is an annoyance when 
> >> making
> >> a change: editors configured to remove trailing whitespace upon save end up
> >> cluttering the diff beyond the intent of the author.
> >> 
> >> Remove trailing whitespace from all html files, so the annoyance described
> >> above no longer occurs.
> >> 
> >> Signed-off-by: Yong Bakos 
> >> ---
> >> architecture.html | 12 +-
> >> building.html | 12 +-
> >> efl.html  | 10 
> >> extras.html   | 14 +--
> >> faq.html  | 10 
> >> index.html| 12 +-
> >> mesa-configure.html   | 18 +++---
> >> qt5.html  | 10 
> >> releases-archive.html | 14 +--
> >> releases.html | 10 
> >> reviewing.html| 66 
> >> +--
> >> screenshots.html  | 12 +-
> >> toolkits.html | 10 
> >> ubuntu12.04.html  |  2 +-
> >> xserver.html  | 12 +-
> >> 15 files changed, 112 insertions(+), 112 deletions(-)
> >> 
> > 
> > Hi Yong,
> > 
> > I have trouble applying this patch:
> 
> Hmm, sorry for the inconvenience. But it applies cleanly
> to master/HEAD for me. Using:
> 
> git am 0001-html-Remove-trailing-whitespace.patch
> 
> Also `git apply-patch` successfully adds the diffs without issue.
> 
> Were you sure that your local wayland-web repo was up to date?
> 
> I'll follow up on irc.

After doubting both git, math and SMTP admins, we eventually figured out
what had gone wrong: subject editing of .patch file in an editor that
automatically strips whitespace can sometimes cause funny issues.

Pushed (with Bryce's RB) and depolyed.

   47348ac..d03d14c  master -> master


Jonas

> 
> Thank you,
> yong
> 
> 
> > Applying: html: Remove trailing whitespace
> > Using index info to reconstruct a base tree...
> > error: patch failed: architecture.html:1
> > error: architecture.html: patch does not apply
> > error: patch failed: building.html:1
> > error: building.html: patch does not apply
> > error: patch failed: efl.html:1
> > error: efl.html: patch does not apply
> > error: patch failed: extras.html:1
> > error: extras.html: patch does not apply
> > error: patch failed: faq.html:1
> > error: faq.html: patch does not apply
> > error: patch failed: index.html:1
> > error: index.html: patch does not apply
> > error: patch failed: mesa-configure.html:1
> > error: mesa-configure.html: patch does not apply
> > error: patch failed: qt5.html:1
> > error: qt5.html: patch does not apply
> > error: patch failed: releases-archive.html:1
> > error: releases-archive.html: patch does not apply
> > error: patch failed: releases.html:1
> > error: releases.html: patch does not apply
> > error: patch failed: reviewing.html:1
> > error: reviewing.html: patch does not apply
> > error: patch failed: screenshots.html:1
> > error: screenshots.html: patch does not apply
> > error: patch failed: toolkits.html:1
> > error: toolkits.html: patch does not apply
> > error: patch failed: ubuntu12.04.html:303
> > error: ubuntu12.04.html: patch does not apply
> > error: patch failed: xserver.html:1
> > error: xserver.html: patch does not apply
> > error: Did you hand edit your patch?
> > It does not apply to blobs recorded in its index.
> > Patch failed at 0001 html: Remove trailing whitespace
> > 
> > When I look at the very first hunk in your patch, which I assume is
> > removing a trailing space, the removed line has no trailing space. The
> > file in git master does have a trailing space. It seems like something
> > mangled the patch, but I have no idea what, you seemed to have used
> > git-send-email.
> > 
> > I think it's the same way in Patchwork too.
> > 
> > Could you check what happened?
> > 
> > Otherwise I would've just pushed this one with Bryce's R-b.
> > 
> > 
> > Thanks,
> > pq
> > ___
> > 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

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

Re: Free software license of weston1.9

[Bryce Harrington]

On Thu, Jun 30, 2016 at 11:59:58AM +0800, Jonas Ådahl wrote:
> On Thu, Jun 30, 2016 at 04:43:29AM +0200, Armin Krezović wrote:
> > On 30.06.2016 04:19, 袁嘉伟 wrote:
> > > Hi, All:
> > > 
> > > 
> > > Who does know that the free software license of weston 1.9 is GPL or 
> > > LGPL?
> > > Thanks.
> > > 
> > > Best regards,
> > > Anthenony
> > > 
> > > 
> > > 
> > > ___
> > > wayland-devel mailing list
> > > wayland-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > 
> > 
> > It's neither of those. It's "MIT Expat" license
> > 
> > https://cgit.freedesktop.org/wayland/weston/tree/COPYING
> > 
> 
> While the source code is distributed under the MIT Expat license, be
> aware that the content of the data/ folder (a set of PNG files) have the
> Creative Commons Attribution-Share Alike 3.0 license.

No, only some cursors and one of the terminal icons are CC-SA-3.0, the
rest are either explicitly MIT Expat or a close variant; the SVG icons
are dual licensed so can be used flexibly either way.

Also despite the license diversity of the data dir, none of the licenses
impose restrictions on distribution or work combination like the GPL
does, just for modification+redistribution of the images themselves, so
I would be surprised any of this would create any sort of problem for
anyone trying to use weston for any purpose.

Bryce

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

[PATCH weston v3 3/3] compositor-x11: remove manual mouse button grab/ungrab

[Benoit Gschwind]

In current compositor-x11, the mouse buttons are grabbed and ungrabbed
manually that cause bugs, in particular when release event is received.
For example starting a move of a window with the left mouse button then
while holding it clicking the right mouse button release the grab. That
allow the mouse to go out the compositor window, while the compositor
still thinking that the mouse is inside. After that, if you release the
mouse outside the compositor window, the compositor never release the
mouse. There is several example of issues starting from this example.

The patch avoid the issue by using the simpler passive button grab, that
automatically grab buttons as soon as they occur. The passive grab
include an automatic ungrab when all mouse button are released. Another
way to fix the issue is to implement this later behavior manually,
which require a lot more code.

Signed-off-by: Benoit Gschwind 
---
 libweston/compositor-x11.c | 27 +--
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/libweston/compositor-x11.c b/libweston/compositor-x11.c
index b6acccd..5d063b5 100644
--- a/libweston/compositor-x11.c
+++ b/libweston/compositor-x11.c
@@ -892,6 +892,19 @@ x11_backend_create_output(struct x11_backend *b, int x, 
int y,
 
x11_output_set_wm_protocols(b, output);
 
+   /* Automatically grab and ungrab mouse buttons */
+   xcb_grab_button(b->conn, 0, output->window,
+   XCB_EVENT_MASK_BUTTON_PRESS |
+   XCB_EVENT_MASK_BUTTON_RELEASE |
+   XCB_EVENT_MASK_POINTER_MOTION |
+   XCB_EVENT_MASK_ENTER_WINDOW |
+   XCB_EVENT_MASK_LEAVE_WINDOW,
+   XCB_GRAB_MODE_ASYNC,
+   XCB_GRAB_MODE_ASYNC,
+   output->window, XCB_CURSOR_NONE,
+   XCB_BUTTON_INDEX_ANY,
+   XCB_MOD_MASK_ANY);
+
xcb_map_window(b->conn, output->window);
 
if (fullscreen)
@@ -1063,20 +1076,6 @@ x11_backend_deliver_button_event(struct x11_backend *b,
if (!output)
return;
 
-   if (is_button_pressed)
-   xcb_grab_pointer(b->conn, 0, output->window,
-XCB_EVENT_MASK_BUTTON_PRESS |
-XCB_EVENT_MASK_BUTTON_RELEASE |
-XCB_EVENT_MASK_POINTER_MOTION |
-XCB_EVENT_MASK_ENTER_WINDOW |
-XCB_EVENT_MASK_LEAVE_WINDOW,
-XCB_GRAB_MODE_ASYNC,
-XCB_GRAB_MODE_ASYNC,
-output->window, XCB_CURSOR_NONE,
-button_event->time);
-   else
-   xcb_ungrab_pointer(b->conn, button_event->time);
-
if (!b->has_xkb)
update_xkb_state_from_core(b, button_event->state);
 
-- 
2.7.3

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

[PATCH weston v3 2/3] compositor-x11: remove redundant state arg of x11_backend_deliver_button_event

[Benoit Gschwind]

The "state" variable in x11_backend_deliver_button_event is basically the
same as (event->response_type == XCB_BUTTON_PRESS), thus update the code
to use the last one.

Signed-off-by: Benoit Gschwind 
---
 libweston/compositor-x11.c | 21 ++---
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/libweston/compositor-x11.c b/libweston/compositor-x11.c
index b934e09..b6acccd 100644
--- a/libweston/compositor-x11.c
+++ b/libweston/compositor-x11.c
@@ -1047,13 +1047,14 @@ update_xkb_state_from_core(struct x11_backend *b, 
uint16_t x11_mask)
 
 static void
 x11_backend_deliver_button_event(struct x11_backend *b,
-xcb_generic_event_t *event, int state)
+xcb_generic_event_t *event)
 {
xcb_button_press_event_t *button_event =
(xcb_button_press_event_t *) event;
uint32_t button;
struct x11_output *output;
struct weston_pointer_axis_event weston_event;
+   bool is_button_pressed = event->response_type == XCB_BUTTON_PRESS;
 
assert(event->response_type == XCB_BUTTON_PRESS ||
   event->response_type == XCB_BUTTON_RELEASE);
@@ -1062,7 +1063,7 @@ x11_backend_deliver_button_event(struct x11_backend *b,
if (!output)
return;
 
-   if (state)
+   if (is_button_pressed)
xcb_grab_pointer(b->conn, 0, output->window,
 XCB_EVENT_MASK_BUTTON_PRESS |
 XCB_EVENT_MASK_BUTTON_RELEASE |
@@ -1092,7 +1093,7 @@ x11_backend_deliver_button_event(struct x11_backend *b,
case 4:
/* Axis are measured in pixels, but the xcb events are discrete
 * steps. Therefore move the axis by some pixels every step. */
-   if (state) {
+   if (is_button_pressed) {
weston_event.value = -DEFAULT_AXIS_STEP_DISTANCE;
weston_event.discrete = -1;
weston_event.has_discrete = true;
@@ -1105,7 +1106,7 @@ x11_backend_deliver_button_event(struct x11_backend *b,
}
return;
case 5:
-   if (state) {
+   if (is_button_pressed) {
weston_event.value = DEFAULT_AXIS_STEP_DISTANCE;
weston_event.discrete = 1;
weston_event.has_discrete = true;
@@ -1118,7 +1119,7 @@ x11_backend_deliver_button_event(struct x11_backend *b,
}
return;
case 6:
-   if (state) {
+   if (is_button_pressed) {
weston_event.value = -DEFAULT_AXIS_STEP_DISTANCE;
weston_event.discrete = -1;
weston_event.has_discrete = true;
@@ -1131,7 +1132,7 @@ x11_backend_deliver_button_event(struct x11_backend *b,
}
return;
case 7:
-   if (state) {
+   if (is_button_pressed) {
weston_event.value = DEFAULT_AXIS_STEP_DISTANCE;
weston_event.discrete = 1;
weston_event.has_discrete = true;
@@ -1150,8 +1151,8 @@ x11_backend_deliver_button_event(struct x11_backend *b,
 
notify_button(>core_seat,
  weston_compositor_get_time(), button,
- state ? WL_POINTER_BUTTON_STATE_PRESSED :
- WL_POINTER_BUTTON_STATE_RELEASED);
+ is_button_pressed ? WL_POINTER_BUTTON_STATE_PRESSED :
+ WL_POINTER_BUTTON_STATE_RELEASED);
notify_pointer_frame(>core_seat);
 }
 
@@ -1344,10 +1345,8 @@ x11_backend_handle_event(int fd, uint32_t mask, void 
*data)
   STATE_UPDATE_NONE);
break;
case XCB_BUTTON_PRESS:
-   x11_backend_deliver_button_event(b, event, 1);
-   break;
case XCB_BUTTON_RELEASE:
-   x11_backend_deliver_button_event(b, event, 0);
+   x11_backend_deliver_button_event(b, event);
break;
case XCB_MOTION_NOTIFY:
x11_backend_deliver_motion_event(b, event);
-- 
2.7.3

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

[PATCH weston v3 0/3] compositor-x11: improving handling of mouse events

[Benoit Gschwind]

v3:
 - change the patch log of patch 3

v2: 
 - fix assert to comply weston coding style.

v1:
 - add some sanity checking,
 - remove redundant viarable,
 - use a better X11 passive grab

Benoit Gschwind (3):
  compositor-x11: add assert to avoid misuse of
x11_backend_deliver_button_event
  compositor-x11: remove redundant state arg of
x11_backend_deliver_button_event
  compositor-x11: remove manual mouse button grab/ungrab

 libweston/compositor-x11.c | 49 +++---
 1 file changed, 25 insertions(+), 24 deletions(-)

-- 
2.7.3

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

[PATCH weston v3 1/3] compositor-x11: add assert to avoid misuse of x11_backend_deliver_button_event

[Benoit Gschwind]

The x11_backend_deliver_button_event can be called with any
xcb_generic_event. The assert check if the call is done with the
expected events.

Signed-off-by: Benoit Gschwind 
---
 libweston/compositor-x11.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libweston/compositor-x11.c b/libweston/compositor-x11.c
index a3319b4..b934e09 100644
--- a/libweston/compositor-x11.c
+++ b/libweston/compositor-x11.c
@@ -1055,6 +1055,9 @@ x11_backend_deliver_button_event(struct x11_backend *b,
struct x11_output *output;
struct weston_pointer_axis_event weston_event;
 
+   assert(event->response_type == XCB_BUTTON_PRESS ||
+  event->response_type == XCB_BUTTON_RELEASE);
+
output = x11_backend_find_output(b, button_event->event);
if (!output)
return;
-- 
2.7.3

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

[PATCH] fullscreen-shell: Remap surface when attaching primary output

[Armin Krezović]

When a surface gets created and no outputs are present,
it won't get properly configured. This happens because
call to configure_presented_surface() depends on a call
to fs_output_set_surface() which requires a valid output.

This patch makes the code save the surface when no
outputs are present and reconfigure it when an output
gets attached, so it gets properly displayed.

Signed-off-by: Armin Krezović 
---
 fullscreen-shell/fullscreen-shell.c | 31 ++-
 1 file changed, 30 insertions(+), 1 deletion(-)

diff --git a/fullscreen-shell/fullscreen-shell.c 
b/fullscreen-shell/fullscreen-shell.c
index 9716dc5..f58df2f 100644
--- a/fullscreen-shell/fullscreen-shell.c
+++ b/fullscreen-shell/fullscreen-shell.c
@@ -46,6 +46,8 @@ struct fullscreen_shell {
struct wl_listener output_created_listener;
 
struct wl_listener seat_created_listener;
+
+   struct wl_list unmapped_surfaces;
 };
 
 struct fs_output {
@@ -83,6 +85,12 @@ struct pointer_focus_listener {
struct wl_listener seat_destroyed;
 };
 
+struct fs_surface_list {
+   struct weston_surface *surface;
+   enum zwp_fullscreen_shell_v1_present_method method;
+   struct wl_list link;
+};
+
 static void
 pointer_focus_changed(struct wl_listener *listener, void *data)
 {
@@ -245,10 +253,15 @@ pending_surface_destroyed(struct wl_listener *listener, 
void *data)
fsout->pending.surface = NULL;
 }
 
+static void
+configure_presented_surface(struct weston_surface *surface, int32_t sx,
+   int32_t sy);
+
 static struct fs_output *
 fs_output_create(struct fullscreen_shell *shell, struct weston_output *output)
 {
struct fs_output *fsout;
+   struct fs_surface_list *surf, *next;
 
fsout = zalloc(sizeof *fsout);
if (!fsout)
@@ -271,6 +284,14 @@ fs_output_create(struct fullscreen_shell *shell, struct 
weston_output *output)
weston_layer_entry_insert(>layer.view_list,
   >black_view->layer_link);
wl_list_init(>transform.link);
+
+   wl_list_for_each_safe(surf, next, >unmapped_surfaces, link) {
+   fs_output_set_surface(fsout, surf->surface, surf->method, 0, 0);
+   configure_presented_surface(surf->surface, 0, 0);
+   wl_list_remove(>link);
+   free(surf);
+   }
+
return fsout;
 }
 
@@ -676,6 +697,7 @@ fullscreen_shell_present_surface(struct wl_client *client,
struct weston_surface *surface;
struct weston_seat *seat;
struct fs_output *fsout;
+   struct fs_surface_list *surf;
 
surface = surface_res ? wl_resource_get_user_data(surface_res) : NULL;
 
@@ -692,7 +714,13 @@ fullscreen_shell_present_surface(struct wl_client *client,
   "Invalid presentation method");
}
 
-   if (output_res) {
+   if (wl_list_empty(>output_list)) {
+   surf = zalloc(sizeof *surf);
+   surf->surface = surface;
+   surf->method = method;
+   wl_list_init(>link);
+   wl_list_insert(shell->unmapped_surfaces.prev, >link);
+   } else if (output_res) {
output = wl_resource_get_user_data(output_res);
fsout = fs_output_for_output(output);
fs_output_set_surface(fsout, surface, method, 0, 0);
@@ -831,6 +859,7 @@ module_init(struct weston_compositor *compositor,
return -1;
 
shell->compositor = compositor;
+   wl_list_init(>unmapped_surfaces);
 
shell->client_destroyed.notify = client_destroyed;
 
-- 
2.9.0

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

[PATCH weston 1/2] input: Update keyboard serial on press and release

[Olivier Fourdan]

Other compositors such as mutter update the keyboard serial for both key
press and key release, unlike weston which updates it only on key press.

When dealing with popup windows which require a match in serials, if the
event that caused the popup to be shown is a key release, then the popup
would be dismissed.

This occurs when navigating gtk+ sub-menus using the keyboard.

Signed-off-by: Olivier Fourdan 
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=768017
---
 libweston/input.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libweston/input.c b/libweston/input.c
index 8f46698..18c4c1f 100644
--- a/libweston/input.c
+++ b/libweston/input.c
@@ -1661,9 +1661,8 @@ notify_key(struct weston_seat *seat, uint32_t time, 
uint32_t key,
  state);
}
 
+   keyboard->grab_serial = wl_display_get_serial(compositor->wl_display);
if (state == WL_KEYBOARD_KEY_STATE_PRESSED) {
-   keyboard->grab_serial =
-   wl_display_get_serial(compositor->wl_display);
keyboard->grab_time = time;
keyboard->grab_key = key;
}
-- 
2.7.4

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

[PATCH weston 2/2] shell: Check for keyboard driven popup as well

[Olivier Fourdan]

xdh-shell's xdg-popup takes a serial, if the serial doesn't match the
compositor would dismiss the popup.

Currently, weston checks for pointer and touch serials, but popups can
also be triggered by keyboard shortcuts.

If a user activates a menu without any previous pointer ineraction with
the client, weston would dismiss the xdg-popup because the keyboard
serial would not match the popup serial.

Signed-off-by: Olivier Fourdan 
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=768017
---
 desktop-shell/shell.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index c125d55..fdab394 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -230,7 +230,7 @@ struct shell_seat {
struct wl_list surfaces_list;
struct wl_client *client;
int32_t initial_up;
-   enum { POINTER, TOUCH } type;
+   enum { KEYBOARD, POINTER, TOUCH } type;
} popup_grab;
 };
 
@@ -3467,12 +3467,15 @@ add_popup_grab(struct shell_surface *shsurf,
} else if (type == TOUCH) {
shseat->popup_grab.touch_grab.interface =
_popup_grab_interface;
+   } else if (type == KEYBOARD) {
+   shseat->popup_grab.grab.interface =
+   _grab_interface;
}
 
wl_list_insert(>popup_grab.surfaces_list,
   >popup.grab_link);
 
-   if (type == POINTER) {
+   if (type == POINTER || type == KEYBOARD) {
weston_pointer_start_grab(pointer,
  >popup_grab.grab);
} else if (type == TOUCH) {
@@ -3504,7 +3507,7 @@ remove_popup_grab(struct shell_surface *shsurf)
wl_list_remove(>popup.grab_link);
wl_list_init(>popup.grab_link);
if (wl_list_empty(>popup_grab.surfaces_list)) {
-   if (shseat->popup_grab.type == POINTER) {
+   if (shseat->popup_grab.type == POINTER || 
shseat->popup_grab.type == KEYBOARD) {

weston_pointer_end_grab(shseat->popup_grab.grab.pointer);
shseat->popup_grab.grab.interface = NULL;
} else if (shseat->popup_grab.type == TOUCH) {
@@ -3521,6 +3524,7 @@ shell_map_popup(struct shell_surface *shsurf)
struct weston_view *parent_view = get_default_view(shsurf->parent);
struct weston_pointer *pointer = weston_seat_get_pointer(shseat->seat);
struct weston_touch *touch = weston_seat_get_touch(shseat->seat);
+   struct weston_keyboard *keyboard = 
weston_seat_get_keyboard(shseat->seat);
 
shsurf->surface->output = parent_view->output;
shsurf->view->output = parent_view->output;
@@ -3537,6 +3541,10 @@ shell_map_popup(struct shell_surface *shsurf)
   touch->grab_serial == shsurf->popup.serial) {
if (add_popup_grab(shsurf, shseat, TOUCH) != 0)
return -1;
+   } else if (keyboard &&
+  keyboard->grab_serial == shsurf->popup.serial) {
+   if (add_popup_grab(shsurf, shseat, KEYBOARD) != 0)
+   return -1;
} else {
shell_surface_send_popup_done(shsurf);
shseat->popup_grab.client = NULL;
-- 
2.7.4

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

Re: [PATCH libinput] gestures: make the gesture movement threshold depending on finger count

[Eric Engestrom]

On Thu, Jun 30, 2016 at 02:10:24PM +0100, Eric Engestrom wrote:
> The threshold now becomes 0 for 1 finger, which I assume was not the

Sorry for the noise, I just realized this code only applies to >2
fingers, so you can just ignore my previous message :)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] gestures: make the gesture movement threshold depending on finger count

[Eric Engestrom]

On Thu, Jun 30, 2016 at 12:22:10PM +1000, Peter Hutterer wrote:
> Increase the mm move threshold for 3 and 4 finger gestures to 2 and 3 mm,
> respectively. In multi-finger gestures it's common to have minor movement
> while all fingers are being put down or before the conscious movement starts.
> This can trigger invalid gesture detection (e.g. a pinch instead of a swipe).
> Increase the movement threshold to make sure we have sufficient input data.
> 
> No changes to 2-finger movements.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=96687
> 
> Signed-off-by: Peter Hutterer 
> ---
>  src/evdev-mt-touchpad-gestures.c |  9 ++---
>  test/gestures.c  | 10 +-
>  2 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/src/evdev-mt-touchpad-gestures.c 
> b/src/evdev-mt-touchpad-gestures.c
> index e4e465a..a910bec 100644
> --- a/src/evdev-mt-touchpad-gestures.c
> +++ b/src/evdev-mt-touchpad-gestures.c
> @@ -182,12 +182,15 @@ tp_gesture_get_active_touches(const struct tp_dispatch 
> *tp,
>  }
>  
>  static int
> -tp_gesture_get_direction(struct tp_dispatch *tp, struct tp_touch *touch)
> +tp_gesture_get_direction(struct tp_dispatch *tp, struct tp_touch *touch,
> +  unsigned int nfingers)
>  {
>   struct normalized_coords normalized;
>   struct device_float_coords delta;
>   double move_threshold = TP_MM_TO_DPI_NORMALIZED(1);
>  
> + move_threshold *= (nfingers - 1);

The threshold now becomes 0 for 1 finger, which I assume was not the
intended behaviour. Should `-1` be removed (and the commit message adapted)?

Alternatively, something like this would give the result from the commit
message:

move_threshold *= min(1, nfingers - 1);

> +
>   delta = device_delta(touch->point, touch->gesture.initial);
>  
>   normalized = tp_normalize_delta(tp, delta);
> @@ -347,8 +350,8 @@ tp_gesture_handle_state_unknown(struct tp_dispatch *tp, 
> uint64_t time)
>   }
>  
>   /* Else wait for both fingers to have moved */
> - dir1 = tp_gesture_get_direction(tp, first);
> - dir2 = tp_gesture_get_direction(tp, second);
> + dir1 = tp_gesture_get_direction(tp, first, tp->gesture.finger_count);
> + dir2 = tp_gesture_get_direction(tp, second, tp->gesture.finger_count);
>   if (dir1 == UNDEFINED_DIRECTION || dir2 == UNDEFINED_DIRECTION)
>   return GESTURE_STATE_UNKNOWN;
>  

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

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Jonas Ådahl]

On Thu, Jun 30, 2016 at 01:10:33PM +0200, Carlos Garnacho wrote:
> Hi!,
> 
> On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl  wrote:
> > On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
> >> The pad's interface is similar to the tool interface, a client is notified 
> >> of
> >> the pad after the tablet_added event.
> >>
> >> The pad has three functionalities: buttons, rings and strips.
> >> Buttons are fairly straightforward, rings and strips are separate 
> >> interfaces
> >> with a pointer-axis-like source/value/frame events.
> >> The two interfaces are effectively identical but for the actual value they
> >> send (degrees vs normalized position).
> >>
> >> Buttons are sequentially indexed starting with zero, unlike other protocols
> >> where a linux/input.h-style semantic event code is used. Since we expect 
> >> all
> >> buttons to have client-specific functionality, an additional event tells 
> >> the
> >> client when a given button index is not available, usually because the
> >> compositor assignes some function to it (e.g. mode switching, see below).
> >>
> >> Specific to the pad device is the set_feedback request which enables a 
> >> client
> >> to set a user-defined string to display for an OSD on the current mappings.
> >> This request is available for buttons, rings and strips.
> >>
> >> Finally, the pad supports groups, effectively sets of button/ring/strip
> >> configurations. Those groups may have multiple modes each, so that
> >> users/clients may map several actions to a single element.
> >>
> >> Signed-off-by: Carlos Garnacho 
> >> Signed-off-by: Peter Hutterer 
> >> Reviewed-by: Jason Gerecke 
> >> ---
> >>

... snip ...

> >> +
> >> +
> >> +  
> >> + Sent on wp_tablet_pad_group initialization to announce available 
> >> rings.
> >> + One event is sent for each ring available on this pad group.
> >> +
> >> + This event is sent in the initial burst of events before the
> >> + wp_tablet_pad_group.done event. This event is only sent when at least
> >> + one ring is available.
> >
> > The last sentence is redundant. It already says that there'll be one
> > event per ring, thus no rings, no events. It also makes it slightly
> > unclear (by the description alone) whethere multiple rings will result
> > in multiple events.
> 
> Agreed, removed. As for the last part... I guess the "One event is
> sent for each ring available..." bit makes it clear enough already?

Yes, I think that part makes it clear. It was only the part you now
removed that made it possible to doubt the first part for a second.

>

... snip ...

> >> +
> >> +
> >> +  
> >> + Notification that the mode was switched.
> >> +
> >> + A mode applies to all buttons, rings and strips in a group
> >> + simultaneously, but a client is not required to assign different 
> >> actions
> >> + for each mode. For example, a client may have mode-specific button
> >> + mappings but map the ring to vertical scrolling in all modes. Mode
> >> + indices start at 0.
> >> +
> >> + Switching modes is compositor-dependent. The compositor may provide
> >> + visual cues to the client about the mode, e.g. by toggling LEDs on
> >> + the tablet device. Mode-switching may be software-controlled or
> >> + controlled by one or more physical buttons. For example, on a Wacom
> >> + Intuos Pro, the button inside the ring may be assigned to switch
> >> + between modes.
> >> +
> >> + The current mode is compositor-global, the compositor will also send
> >
> > Isn't it just seat global? And why would this event be on the pad group
> > and not on the seat wide interface?
> 
> perhaps I should expand that first phrase :).
> 
> The extent of the current mode is pretty much group local, it only
> affects the buttons/rings/strips that have been announced through this
> group.
> 
> However, the current mode of every given group is global to all
> clients. If you have a client focused with a group in mode=1, focus
> another client, switch that group to mode=3 and go back to the first
> client, you'll receive a .mode_switch with mode=3 after
> wp_tablet_pad.enter.
> 
> This could be considered similar to keyboard modifiers, you don't
> reset those (eg. caps lock) when focusing another client, the current
> state is rather propagated to the newly focused client.
> 
> I'm replacing the beginning of that paragraph with this:
> "Compositors will globally track the current mode that every
> wp_tablet_pad_group has. This event will also be sent after
> wp_tablet_pad.enter for all groups in the pad in order to..."

I see. Any reason on why it needs to be compositor global? Couldn't that
be a decision left to the compositor? Either way, the new wording makes
me understand whats going on, so it now looks good to me.

> 
> >
> > On the other hand, in the pad group interface it says that "The 

Re: [PATCH weston v2 07/12] gl-renderer: Always setup gl-renderer

[Pekka Paalanen]

On Thu, 30 Jun 2016 06:26:11 +0200
Armin Krezović  wrote:

> On 27.06.2016 15:08, Pekka Paalanen wrote:
> >> diff --git a/src/gl-renderer.c b/src/gl-renderer.c
> >> index 23c0cd7..28c0b50 100644
> >> --- a/src/gl-renderer.c
> >> +++ b/src/gl-renderer.c
> >> @@ -2873,6 +2878,43 @@ platform_to_extension(EGLenum platform)
> >>  }
> >>  
> >>  static int
> >> +gl_renderer_create_pbuffer_surface(struct gl_renderer *gr) {  
> > 
> > Style-wise, this function could just take a EGLDisplay as an argument,
> > and return the EGLSurface. That way the setting of dummy_surface would
> > be in the caller, which would make it easier to read.
> >   
> >> +  EGLConfig pbuffer_config;
> >> +
> >> +  static const EGLint pbuffer_config_attribs[] = {
> >> +  EGL_SURFACE_TYPE, EGL_PBUFFER_BIT,
> >> +  EGL_RED_SIZE, 1,
> >> +  EGL_GREEN_SIZE, 1,
> >> +  EGL_BLUE_SIZE, 1,
> >> +  EGL_ALPHA_SIZE, 0,
> >> +  EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT,
> >> +  EGL_NONE
> >> +  };
> >> +
> >> +  static const EGLint pbuffer_attribs[] = {
> >> +  EGL_WIDTH, 10,
> >> +  EGL_HEIGHT, 10,
> >> +  EGL_NONE
> >> +  };
> >> +
> >> +  if (egl_choose_config(gr, pbuffer_config_attribs, NULL, 0, 
> >> _config) < 0) {
> >> +  weston_log("failed to choose EGL config for PbufferSurface");
> >> +  return -1;
> >> +  }
> >> +
> >> +  gr->dummy_surface = eglCreatePbufferSurface(gr->egl_display,
> >> +  pbuffer_config,
> >> +  pbuffer_attribs);
> >> +
> >> +  if (gr->dummy_surface == EGL_NO_SURFACE) {
> >> +  weston_log("failed to create PbufferSurface\n");
> >> +  return -1;
> >> +  }
> >> +
> >> +  return 0;
> >> +}
> >> +  
> 
> I've been looking at this. If I choose to pass EGLDisplay and return an
> EGLSurface from this function, I can't use egl_choose_config. Instead,
> I'd have to manually call eglGetConfigs and eglChooseConfig. So, I'd
> rather not do this, unless you really, really want it.

Hi Armin,

ok, that's fine. I missed the 'gr' argument to egl_choose_config.


Thanks,
pq


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

Re: [PATCH weston 2/2] input: Move weston_seat_set_keyboard_focus and document

[Pekka Paalanen]

On Wed, 29 Jun 2016 19:04:07 -0700
Bryce Harrington  wrote:

> Place it with the other weston_seat functions.
> 
> Signed-off-by: Bryce Harrington 
> ---
>  libweston/compositor.h |  7 ---
>  libweston/input.c  | 34 +++---
>  2 files changed, 23 insertions(+), 18 deletions(-)
> 
> diff --git a/libweston/compositor.h b/libweston/compositor.h
> index 5701a05..49ef063 100644
> --- a/libweston/compositor.h
> +++ b/libweston/compositor.h
> @@ -1167,9 +1167,6 @@ int
>  weston_spring_done(struct weston_spring *spring);
>  
>  void
> -weston_seat_set_keyboard_focus(struct weston_seat *seat,
> -struct weston_surface *surface);
> -void
>  notify_motion(struct weston_seat *seat, uint32_t time,
> struct weston_pointer_motion_event *event);
>  void
> @@ -1717,6 +1714,10 @@ weston_seat_get_pointer(struct weston_seat *seat);
>  struct weston_touch *
>  weston_seat_get_touch(struct weston_seat *seat);
>  
> +void
> +weston_seat_set_keyboard_focus(struct weston_seat *seat,
> +struct weston_surface *surface);
> +
>  #ifdef  __cplusplus
>  }
>  #endif
> diff --git a/libweston/input.c b/libweston/input.c
> index e8c060e..8f46698 100644
> --- a/libweston/input.c
> +++ b/libweston/input.c
> @@ -1297,21 +1297,6 @@ notify_motion_absolute(struct weston_seat *seat,
>  }
>  
>  WL_EXPORT void
> -weston_seat_set_keyboard_focus(struct weston_seat *seat,
> -struct weston_surface *surface)
> -{
> - struct weston_compositor *compositor = seat->compositor;
> - struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
> -
> - if (keyboard) {
> - weston_keyboard_set_focus(keyboard, surface);
> - wl_data_device_set_keyboard_focus(seat);
> - }
> -
> - wl_signal_emit(>activate_signal, surface);
> -}
> -
> -WL_EXPORT void
>  notify_button(struct weston_seat *seat, uint32_t time, int32_t button,
> enum wl_pointer_button_state state)
>  {
> @@ -2763,3 +2748,22 @@ weston_seat_get_touch(struct weston_seat *seat)
>  
>   return NULL;
>  }
> +
> +/** Sets the keyboard focus to the given surface
> + *
> + * \param seat The seat to query
> + */
> +WL_EXPORT void
> +weston_seat_set_keyboard_focus(struct weston_seat *seat,
> +struct weston_surface *surface)
> +{
> + struct weston_compositor *compositor = seat->compositor;
> + struct weston_keyboard *keyboard = weston_seat_get_keyboard(seat);
> +
> + if (keyboard) {
> + weston_keyboard_set_focus(keyboard, surface);
> + wl_data_device_set_keyboard_focus(seat);
> + }
> +
> + wl_signal_emit(>activate_signal, surface);
> +}

Hi Bryce,

both pushed:
   a5bb91d..24f917e  master -> master


The activate_signal will be a lot more difficult to handle. The only
in-tree user of it is xwayland's weston_wm_window_activate() which
assumes there can only be one surface active at a time, and it's not
even per seat, it's really just one. There might also be other users
out there I do not know of.

If we go with your plan to be able to have arbitrary many surfaces
active at the same time, without changes XWM would raise and activate
the most recent surface set active, regardless of what is already
active. Is that desireable, I do not know.

To be able to support any other kind of behaviour, we'd need signals for
both activate and deactivate. Or, we have to decide that you can only
have one surface active per seat, in which case we'd have a per-seat
activate_signal, and the active surface would be tracked just like
keyboard focus except in struct weston_seat, not in struct
weston_keyboard.

Looks like all of weston_keyboard, weston_pointer, and weston_touch
have their own focus_signals, too, which are naturally conditional on
having the capability in the seat.

These are the design questions we need to solve to add activeness
tracking in Weston core. If we put "active" as a thing in the core,
how should it behave?

Therefore I'd suggest to reconsider "activeness" for idle-inhibit. If
you just want a shell-controllable surface flag for "may inhibit idle
triggers", then we should not talk about active because active is
something else. Then I'd also ask why is it a surface and not a view.


Thanks,
pq


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

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Thu, Jun 30, 2016 at 6:27 AM, Jonas Ådahl  wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> The pad has three functionalities: buttons, rings and strips.
>> Buttons are fairly straightforward, rings and strips are separate interfaces
>> with a pointer-axis-like source/value/frame events.
>> The two interfaces are effectively identical but for the actual value they
>> send (degrees vs normalized position).
>>
>> Buttons are sequentially indexed starting with zero, unlike other protocols
>> where a linux/input.h-style semantic event code is used. Since we expect all
>> buttons to have client-specific functionality, an additional event tells the
>> client when a given button index is not available, usually because the
>> compositor assignes some function to it (e.g. mode switching, see below).
>>
>> Specific to the pad device is the set_feedback request which enables a client
>> to set a user-defined string to display for an OSD on the current mappings.
>> This request is available for buttons, rings and strips.
>>
>> Finally, the pad supports groups, effectively sets of button/ring/strip
>> configurations. Those groups may have multiple modes each, so that
>> users/clients may map several actions to a single element.
>>
>> Signed-off-by: Carlos Garnacho 
>> Signed-off-by: Peter Hutterer 
>> Reviewed-by: Jason Gerecke 
>> ---
>>
>> Changes since v3:
>>
>> - Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
>>   groups may have separate modes which are announced through a mode_switch
>>   event.
>> - Added serial argument to the set_feedback requests, to be obtained from
>>   the wp_tablet_pad_group.mode_switch events.
>> - Now that groups announce the buttons belonging to those, the
>>   wp_tablet_pad.buttons_reserved event has been removed in favor of implicit
>>   information (i.e. buttons not belonging to any group are reserved by the
>>   compositor).
>> - Added wp_tablet_pad.path event, similar to wp_tablet.path
>> - Button indices are now explicitly mentioned in docs where relevant
>> - Fixed several typos and improved docs here and there
>>
>>  unstable/tablet/tablet-unstable-v2.xml | 546 
>> -
>>  1 file changed, 543 insertions(+), 3 deletions(-)
>>
>> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
>> b/unstable/tablet/tablet-unstable-v2.xml
>> index 5248c64..63172e2 100644
>> --- a/unstable/tablet/tablet-unstable-v2.xml
>> +++ b/unstable/tablet/tablet-unstable-v2.xml
>> @@ -172,6 +172,22 @@
>>
>>> summary="the newly added tablet tool"/>
>>  
>> +
>> +
>> +  
>> + This event is sent whenever a new pad is known to the system. 
>> Typically,
>> + pads are physically attached to tablets and a pad_added event is
>> + sent immediately after the wp_tablet_seat.tablet_added.
>> + However, some standalone pad devices logically attach to tablets at
>> + runtime, and the client must wait for wp_tablet_pad.enter to know
>> + the tablet a pad is attached to.
>> +
>> + This event only provides the object id of the pad. All further
>> + features (buttons, strips, rings) are sent through the wp_tablet_pad
>> + interface.
>> +  
>> +  > summary="the newly added pad"/>
>> +
>>
>>
>>
>> @@ -508,9 +524,9 @@
>>
>>   Sent whenever the wheel on the tool emits an event. This event
>>   contains two values for the same axis change. The degrees value is
>> - in degrees in the same orientation as the wl_pointer.vertical_scroll
>> - axis. The clicks value is in discrete logical clicks of the mouse
>> - wheel. This value may be zero if the movement of the wheel was less
>> + in the same orientation as the wl_pointer.vertical_scroll axis. The
>> + clicks value is in discrete logical clicks of the mouse wheel. This
>> + value may be zero if the movement of the wheel was less
>
> This change seems unrelated.

It indeed is...

>
>>   than one logical click.
>>
>>   Clients should choose either value and avoid mixing degrees and
>> @@ -636,4 +652,528 @@
>>  
>>
>>
>> +  
>> +
>> +  A circular interaction area.
>> +
>> +  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
>> +  event.
>> +
>> +
>> +
>> +  
>> + Request that the compositor use the provided feedback string
>> + associated with this ring. This request should be issued immediately
>> + after a wp_tablet_pad.enter, or whenever the ring is mapped to a
>> + different action.
>> +
>> + Clients are encouraged to provide context-aware descriptions for
>> + the actions associated with the ring; compositors may use this
>> + information to offer visual 

Re: [PATCH wayland-web 1/1] html: Remove trailing whitespace

[Pekka Paalanen]

On Tue, 28 Jun 2016 08:52:33 -0500
Yong Bakos  wrote:

> From: Yong Bakos 
> 
> The html files contain trailing whitespace, which is an annoyance when making
> a change: editors configured to remove trailing whitespace upon save end up
> cluttering the diff beyond the intent of the author.
> 
> Remove trailing whitespace from all html files, so the annoyance described
> above no longer occurs.
> 
> Signed-off-by: Yong Bakos 
> ---
>  architecture.html | 12 +-
>  building.html | 12 +-
>  efl.html  | 10 
>  extras.html   | 14 +--
>  faq.html  | 10 
>  index.html| 12 +-
>  mesa-configure.html   | 18 +++---
>  qt5.html  | 10 
>  releases-archive.html | 14 +--
>  releases.html | 10 
>  reviewing.html| 66 
> +--
>  screenshots.html  | 12 +-
>  toolkits.html | 10 
>  ubuntu12.04.html  |  2 +-
>  xserver.html  | 12 +-
>  15 files changed, 112 insertions(+), 112 deletions(-)
> 

Hi Yong,

I have trouble applying this patch:

Applying: html: Remove trailing whitespace
Using index info to reconstruct a base tree...
error: patch failed: architecture.html:1
error: architecture.html: patch does not apply
error: patch failed: building.html:1
error: building.html: patch does not apply
error: patch failed: efl.html:1
error: efl.html: patch does not apply
error: patch failed: extras.html:1
error: extras.html: patch does not apply
error: patch failed: faq.html:1
error: faq.html: patch does not apply
error: patch failed: index.html:1
error: index.html: patch does not apply
error: patch failed: mesa-configure.html:1
error: mesa-configure.html: patch does not apply
error: patch failed: qt5.html:1
error: qt5.html: patch does not apply
error: patch failed: releases-archive.html:1
error: releases-archive.html: patch does not apply
error: patch failed: releases.html:1
error: releases.html: patch does not apply
error: patch failed: reviewing.html:1
error: reviewing.html: patch does not apply
error: patch failed: screenshots.html:1
error: screenshots.html: patch does not apply
error: patch failed: toolkits.html:1
error: toolkits.html: patch does not apply
error: patch failed: ubuntu12.04.html:303
error: ubuntu12.04.html: patch does not apply
error: patch failed: xserver.html:1
error: xserver.html: patch does not apply
error: Did you hand edit your patch?
It does not apply to blobs recorded in its index.
Patch failed at 0001 html: Remove trailing whitespace

When I look at the very first hunk in your patch, which I assume is
removing a trailing space, the removed line has no trailing space. The
file in git master does have a trailing space. It seems like something
mangled the patch, but I have no idea what, you seemed to have used
git-send-email.

I think it's the same way in Patchwork too.

Could you check what happened?

Otherwise I would've just pushed this one with Bryce's R-b.


Thanks,
pq


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

Re: [PATCH v4 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Carlos Garnacho]

Hi!,

On Thu, Jun 30, 2016 at 5:27 AM, Peter Hutterer
 wrote:
> On Tue, Jun 28, 2016 at 11:21:50PM +0200, Carlos Garnacho wrote:
>> The pad's interface is similar to the tool interface, a client is notified of
>> the pad after the tablet_added event.
>>
>> The pad has three functionalities: buttons, rings and strips.
>> Buttons are fairly straightforward, rings and strips are separate interfaces
>> with a pointer-axis-like source/value/frame events.
>> The two interfaces are effectively identical but for the actual value they
>> send (degrees vs normalized position).
>>
>> Buttons are sequentially indexed starting with zero, unlike other protocols
>> where a linux/input.h-style semantic event code is used. Since we expect all
>> buttons to have client-specific functionality, an additional event tells the
>> client when a given button index is not available, usually because the
>> compositor assignes some function to it (e.g. mode switching, see below).
>>
>> Specific to the pad device is the set_feedback request which enables a client
>> to set a user-defined string to display for an OSD on the current mappings.
>> This request is available for buttons, rings and strips.
>>
>> Finally, the pad supports groups, effectively sets of button/ring/strip
>> configurations. Those groups may have multiple modes each, so that
>> users/clients may map several actions to a single element.
>>
>> Signed-off-by: Carlos Garnacho 
>> Signed-off-by: Peter Hutterer 
>> Reviewed-by: Jason Gerecke 
>> ---
>>
>> Changes since v3:
>>
>> - Added wp_tablet_pad_group, this divides buttons/strips/rings into subsets,
>>   groups may have separate modes which are announced through a mode_switch
>>   event.
>> - Added serial argument to the set_feedback requests, to be obtained from
>>   the wp_tablet_pad_group.mode_switch events.
>> - Now that groups announce the buttons belonging to those, the
>>   wp_tablet_pad.buttons_reserved event has been removed in favor of implicit
>>   information (i.e. buttons not belonging to any group are reserved by the
>>   compositor).
>> - Added wp_tablet_pad.path event, similar to wp_tablet.path
>> - Button indices are now explicitly mentioned in docs where relevant
>> - Fixed several typos and improved docs here and there
>>
>>  unstable/tablet/tablet-unstable-v2.xml | 546 
>> -
>>  1 file changed, 543 insertions(+), 3 deletions(-)
>>
>> diff --git a/unstable/tablet/tablet-unstable-v2.xml 
>> b/unstable/tablet/tablet-unstable-v2.xml
>> index 5248c64..63172e2 100644
>> --- a/unstable/tablet/tablet-unstable-v2.xml
>> +++ b/unstable/tablet/tablet-unstable-v2.xml
>> @@ -172,6 +172,22 @@
>>
>>> summary="the newly added tablet tool"/>
>>  
>> +
>> +
>> +  
>> + This event is sent whenever a new pad is known to the system. 
>> Typically,
>> + pads are physically attached to tablets and a pad_added event is
>> + sent immediately after the wp_tablet_seat.tablet_added.
>> + However, some standalone pad devices logically attach to tablets at
>> + runtime, and the client must wait for wp_tablet_pad.enter to know
>> + the tablet a pad is attached to.
>> +
>> + This event only provides the object id of the pad. All further
>> + features (buttons, strips, rings) are sent through the wp_tablet_pad
>> + interface.
>> +  
>> +  > summary="the newly added pad"/>
>> +
>>
>>
>>
>> @@ -508,9 +524,9 @@
>>
>>   Sent whenever the wheel on the tool emits an event. This event
>>   contains two values for the same axis change. The degrees value is
>> - in degrees in the same orientation as the wl_pointer.vertical_scroll
>> - axis. The clicks value is in discrete logical clicks of the mouse
>> - wheel. This value may be zero if the movement of the wheel was less
>> + in the same orientation as the wl_pointer.vertical_scroll axis. The
>> + clicks value is in discrete logical clicks of the mouse wheel. This
>> + value may be zero if the movement of the wheel was less
>>   than one logical click.
>
> this hunk looks like rebase detritus

Oops, it indeed is. Now I wonder which of your earlier patches this
belonged to...

>>
>>   Clients should choose either value and avoid mixing degrees and
>> @@ -636,4 +652,528 @@
>>  
>>
>>
>> +  
>> +
>> +  A circular interaction area.
>
> I think it'd be best to add " such as the touch ring on the Wacom Intuos Pro
> series tablets", just to save us from having to explain what a ring is ;)
> Same goes for the strip.

Agreed :), added that blurb as-is, and another for strips/cintiqs.

>
> [...]
>> +
>> +  
>> + Describes the source types for ring events. This indicates to the
>> + client how a ring event was physically generated; a client may
>> + adjust the user interface accordingly. For example, events

About ivi shell and hmi controller

[袁嘉伟]

Hi, All


Sorry for I am a beginner in using ivi-shell to develop application. So I 
don't know the specific sequence and procedure.
I want to get some sample code which rendering with egl and using 
ivi-control to manage the layer,
that is similar to simple-egl.c, not ivi-shell-usr-interface.c in 
weston-1.9.0\clients.
Who can provide a C program for me.
Very thanks.


Best regards,
Anthenony



在 2016-06-30 14:07:57，"Ucan, Emre (ADITG/SW1)"  写道：
>Hi,
>
>Most chip vendors that I know have a GENIVI compliant BSP.
>Maybe you can ask to chip vendor if they have GENIVI support.
>
>Best regards
>
>Emre Ucan
>Software Group I (ADITG/SW1)
>
>Tel. +49 5121 49 6937
>
>> -Original Message-
>> From: 袁嘉伟 [mailto:yuanjw1...@163.com]
>> Sent: Mittwoch, 29. Juni 2016 04:16
>> To: Ucan, Emre (ADITG/SW1)
>> Cc: wayland-devel
>> Subject: Re:RE: About ivi shell and hmi controller
>> 
>> Hi Ucan,
>> 
>> There is another problem that ivi-controller.so or ivi-controller.h that is 
>> used
>> to develop doesn't exist in sdk which provided by chip vendor.
>> How can i get the .h and .so file?
>> Might I copile it by myself?
>> 
>> 
>> At 2016-06-28 16:03:44, "Ucan, Emre (ADITG/SW1)" 
>> wrote:
>> >Hi Anthenony,
>> >
>> >The ivi-hmi-controller protocol is a test/toy protocol only.
>> >It is not usable for real IVI sytems.
>> >
>> >You have to use ivi-controller protocol for entire functionality of 
>> >IVI-Shell.
>> >
>> >You can find the server and client side implementation of the ivi-controller
>> protocol at:
>> >http://projects.genivi.org/wayland-ivi-extension/
>> >
>> >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 ???
>> >> Sent: Dienstag, 28. Juni 2016 09:49
>> >> To: wayland-devel
>> >> Subject: About ivi shell and hmi controller
>> >>
>> >> Hi, all:
>> >>
>> >> Recently started using IVI to develop vehicle navigation with wayland
>> 1.9.
>> >> I downloaded a package named weston-1.9.0 at wayland official
>> website.
>> >> There is some source code in folder weston-1.9.0\ivi-shell. I found so
>> many
>> >> functional realization in ivi-layout.c and other .c files.
>> >> For example, set_position, set_visible,set_opacity, set_dimension and
>> so
>> >> on.
>> >> But there is only a small part of interfaces in 
>> >> ivi-application-client-
>> protocol.h
>> >> and ivi-hmi-controller-client-protocol.h
>> >> that provided by chip vendor(client-protocol.h has attached).
>> >> I created an ivi-application surface referring to simple-egl, and I 
>> >> don't
>> know
>> >> how to make it set positon and dimension.
>> >> Who has relevant experience please tell me.
>> >> Thanks.
>> >>
>> >>
>> >> Best regards,
>> >> Anthenony
>> >>
>> >>
>> >>
>> >
>> >___
>> >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

Why track window activeness? (Re: [PATCH weston v3 2/8] compositor: Track inhibition state in weston_surface)

[Pekka Paalanen]

On Wed, 29 Jun 2016 16:57:31 -0700
Bryce Harrington  wrote:

> On Tue, Jun 28, 2016 at 12:15:49PM +0300, Pekka Paalanen wrote:
> > On Thu, 23 Jun 2016 17:32:50 -0700
> > Bryce Harrington  wrote:
> >   
> > > On Thu, May 26, 2016 at 06:01:27PM +0300, Pekka Paalanen wrote:  
> > > > On Thu,  7 Apr 2016 16:44:17 -0700
> > > > Bryce Harrington  wrote:
> > > > 
> > > > > Signed-off-by: Bryce Harrington 
> > > > 
> > > > Hi,
> > > > 
> > > > the commit message could use an explanation of what the 'bool active'
> > > > will actually be useful for. What do we need the "is in active use" for?
> > > > The comment in the code does not really tell me either. This ties in
> > > > with my comments on patch 3.
> > > > 
> > > > The patch subject is misleading. There is no inhibition state tracking
> > > > at all in this patch. Instead, this patch is about tracking surface
> > > > activeness as defined by the shells.
> > > > 

> > > > > diff --git a/src/compositor.c b/src/compositor.c
> > > > > index 83cabf7..9531a0a 100644
> > > > > --- a/src/compositor.c
> > > > > +++ b/src/compositor.c
> > > > > @@ -612,6 +612,9 @@ weston_surface_create(struct weston_compositor 
> > > > > *compositor)
> > > > >   weston_matrix_init(>buffer_to_surface_matrix);
> > > > >   weston_matrix_init(>surface_to_buffer_matrix);
> > > > >  
> > > > > + surface->active = false;
> > > > > + surface->inhibit_idling = false;
> > > > > +
> > > > >   return surface;
> > > > >  }
> > > > >  
> > > > > @@ -3422,6 +3425,45 @@ weston_surface_copy_content(struct 
> > > > > weston_surface *surface,
> > > > >src_x, src_y, width, height);
> > > > >  }
> > > > >  
> > > > > +/** Sets the keyboard focus to the given surface
> > > > > + */
> > > > > +WL_EXPORT void
> > > > > +weston_surface_assign_keyboard(struct weston_surface *surface,
> > > > > +   struct weston_seat *seat)
> > > > 
> > > > This should be called weston_seat_set_keyboard_focus(seat, surface).
> > > > Keyboard focus is a property of the seat.
> > > > 
> > > > > +{
> > > > > +struct weston_compositor *compositor = seat->compositor;
> > > > > +struct weston_keyboard *keyboard = 
> > > > > weston_seat_get_keyboard(seat);
> > > > > +
> > > > > +if (keyboard) {
> > > > > +weston_keyboard_set_focus(keyboard, surface);
> > > > > +wl_data_device_set_keyboard_focus(seat);
> > > > 
> > > > I wonder if wl_data_device_set_keyboard_focus() is a misnomer. Its
> > > > purpose is to offer the selection to the newly activated surface, so in
> > > > that respect it should belong in weston_surface_activate() and not be
> > > > tied to the keyboard in any way. But, as it currently is inherently
> > > > tied to the keyboard, it needs to be here as it is.
> > > > 
> > > > > +}
> > > > > +
> > > > > +wl_signal_emit(>activate_signal, surface);
> > > > 
> > > > Why is sending the activate_signal here and not part of
> > > > weston_surface_activate()?
> > > 
> > > No, it doesn't belong in weston_surface_activate().  This is not a new
> > > signal added by this patch but a pre-existing one that gets triggered as
> > > part of the keyboard focus assignment.  
> > 
> > Hi Bryce,
> > 
> > you're right, it's not a new signal, but right now in master it is
> > being emitted from weston_surface_activate().
> > 
> > Can you explain why it does not belong in weston_surface_activate()?
> > Is the signal misnamed?  
> 
> Yes
> 
> > If it is misnamed, just explaining what it actually is in the commit
> > message would be a perfect fix for this review comment.
> >   
> > >   
> > > > > +}
> > > > > +
> > > > > +/** Set surface as considered 'active' by the shell.
> > > > > + */
> > > > > +WL_EXPORT void
> > > > > +weston_surface_activate(struct weston_surface *surface)
> > > > > +{
> > > > > + surface->active = true;
> > > > > +}
> > > > > +
> > > > > +/** Set surface as no longer considered 'active' by the shell.
> > > > > + */
> > > > > +WL_EXPORT void
> > > > > +weston_surface_deactivate(struct weston_surface *surface)
> > > > > +{
> > > > > + surface->active = false;
> > > > > +}
> > > > 
> > > > There was not a single call to weston_surface_deactivate() in this
> > > > patch. IOW, half of this patch is missing! See comments to patch 4.
> > > > 
> > > > That is, if surface->active is meant to essentially be equivalent to
> > > > keyboard focus if a keyboard existed?
> > > >
> > > > > +
> > > > > +WL_EXPORT bool
> > > > > +weston_surface_is_active(struct weston_surface *surface)
> > > > > +{
> > > > > + return surface->active;
> > > > > +}
> > > > 
> > > > This is also unused, but that's ok, I assume no-one is yet interested
> > > > in it. But missing the deactivate is a real problem, because not using
> > > > it will leave stale 

RE: Re:RE: About ivi shell and hmi controller

[Ucan, Emre (ADITG/SW1)]

Hi,

Most chip vendors that I know have a GENIVI compliant BSP.
Maybe you can ask to chip vendor if they have GENIVI support.

Best regards

Emre Ucan
Software Group I (ADITG/SW1)

Tel. +49 5121 49 6937

> -Original Message-
> From: 袁嘉伟 [mailto:yuanjw1...@163.com]
> Sent: Mittwoch, 29. Juni 2016 04:16
> To: Ucan, Emre (ADITG/SW1)
> Cc: wayland-devel
> Subject: Re:RE: About ivi shell and hmi controller
> 
> Hi Ucan,
> 
> There is another problem that ivi-controller.so or ivi-controller.h that is 
> used
> to develop doesn't exist in sdk which provided by chip vendor.
> How can i get the .h and .so file?
> Might I copile it by myself?
> 
> 
> At 2016-06-28 16:03:44, "Ucan, Emre (ADITG/SW1)" 
> wrote:
> >Hi Anthenony,
> >
> >The ivi-hmi-controller protocol is a test/toy protocol only.
> >It is not usable for real IVI sytems.
> >
> >You have to use ivi-controller protocol for entire functionality of 
> >IVI-Shell.
> >
> >You can find the server and client side implementation of the ivi-controller
> protocol at:
> >http://projects.genivi.org/wayland-ivi-extension/
> >
> >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 ???
> >> Sent: Dienstag, 28. Juni 2016 09:49
> >> To: wayland-devel
> >> Subject: About ivi shell and hmi controller
> >>
> >> Hi, all:
> >>
> >> Recently started using IVI to develop vehicle navigation with wayland
> 1.9.
> >> I downloaded a package named weston-1.9.0 at wayland official
> website.
> >> There is some source code in folder weston-1.9.0\ivi-shell. I found so
> many
> >> functional realization in ivi-layout.c and other .c files.
> >> For example, set_position, set_visible,set_opacity, set_dimension and
> so
> >> on.
> >> But there is only a small part of interfaces in ivi-application-client-
> protocol.h
> >> and ivi-hmi-controller-client-protocol.h
> >> that provided by chip vendor(client-protocol.h has attached).
> >> I created an ivi-application surface referring to simple-egl, and I 
> >> don't
> know
> >> how to make it set positon and dimension.
> >> Who has relevant experience please tell me.
> >> Thanks.
> >>
> >>
> >> Best regards,
> >> Anthenony
> >>
> >>
> >>
> >
> >___
> >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