Re: [PATCH v3 weston] Introduce pointer locking and confinement protocol
On Sat, Aug 22, 2015 at 06:49:15PM -0500, Derek Foreman wrote: > Hi Jonas, > > Instead of a reasonable review, I'm going to mostly ask a bunch of noob > questions. Feel free to disregard if you don't have time to enlighten me... Thanks for the input. I'll answer inline. > > On 25/06/15 11:38 PM, Jonas Ådahl wrote: > > This patch introduces a new protocol for locking and confining a > > pointer. It consists of a new global object with two requests; one for > > locking the surface to a position, one for confining the pointer to a > > given region. > > > > See pointer-lock.xml for details of the protocol. > > > > In this patch, only the locking part is fully implemented as in > > specified in the protocol, while confinement is only implemented for > > when the union of the passed region and the input region of the confined > > surface is a single rectangle. > > > > Note that the interfaces are prefixed with an underscore in order to > > avoid future incompatibilities with a future stable interface with an > > equivalent name. > > > > Signed-off-by: Jonas Ådahl > > --- > > > > Changes since v2: > > > > * Updated copyright. > > * Updated to the fixed license text. > > * Clarified that locks are on made on a certain surface from a given > >seat. The same surface may have many parallel locks; one per seat. > > * Added an error enum. > > * Changed the wording explaining that constraints for activating a lock > >is compositor specific. > > * Clarified that there is no guarantee that a lock will ever be > >activated. No error will be raised if the compositor will never > >activate the lock. > > * Changed wording related to pointer events (make them speak protocol, > >not abstract events). > > * Clarify what happens if a surface is destroyed. > > * Fixed various typos. > > * Implemented support for per-seat locks. > > * Clarified what happens when effective lock/confine regions change. > > * Added wl_locked_pointer.set_region and wl_confined_pointer.set_region > >(see below). > > * Implemented support for above mentioned new requests. > > * Changed the order of requests (put destroy first). > > * Added 'unstable protocol' warning and explained its semantics. > > > > This version adds support for changing the lock/confine region after the > > lock was created. > > > > This is so that a client can change the lock region without being > > exposed to a race condition. Depending on the type of lock > > (lock/confine). For exampe, a client who maximizes wants to keep the > > pending lock or pending/active confinement intact can use the set_region > > request. The region is double buffered, meaning it is synchronized with > > the surface input region. > > > > For wl_locked_pointer, since a changed effective region has no effect on > > the lock after it being activated, the set_region request only has effect > > before the lock is activated. As such, it affects the region that is used > > to activate the lock. > > > > For pending wl_confined_pointer lock, the effect is the same as for > > wl_locked_pointer. But for an already activated confinement, it affects the > > pointer, i.e. warps the pointer to somewhere within the region. > > > > > > Jonas > > > > > > Makefile.am | 3 + > > protocol/pointer-lock.xml | 275 + > > src/compositor.c | 11 + > > src/compositor.h | 38 +++ > > src/input.c | 751 > > -- > > 5 files changed, 1061 insertions(+), 17 deletions(-) > > create mode 100644 protocol/pointer-lock.xml > > > > diff --git a/Makefile.am b/Makefile.am > > index 70c436f..201b780 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -106,6 +106,8 @@ nodist_weston_SOURCES = > > \ > > protocol/presentation_timing-server-protocol.h \ > > protocol/scaler-protocol.c \ > > protocol/scaler-server-protocol.h \ > > + protocol/pointer-lock-protocol.c\ > > + protocol/pointer-lock-server-protocol.h \ > > protocol/relative-pointer-protocol.c\ > > protocol/relative-pointer-server-protocol.h > > > > @@ -1186,6 +1188,7 @@ EXTRA_DIST += \ > > protocol/scaler.xml \ > > protocol/ivi-application.xml\ > > protocol/ivi-hmi-controller.xml \ > > + protocol/pointer-lock.xml \ > > protocol/relative-pointer.xml > > > > # > > diff --git a/protocol/pointer-lock.xml b/protocol/pointer-lock.xml > > new file mode 100644 > > index 000..ee5e274 > > --- /dev/null > > +++ b/protocol/pointer-lock.xml > > @@ -0,0 +1,275 @@ > > + > > + > > + > > + > > +Copyright © 2014 Jonas Ådahl > > +Copyright © 2015 Red Hat Inc. > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > +copy of this software
[PATCH weston v2] ivi-layout: implement surface clipping
From: Nobuhiko Tanibata
View clip region is set in surface-local coordinates. To compute that
region, the ivi-layer destination rectangle in the global coordinates
are transformed back into the surface-local coordinates.
The transformation is computed by first forming the transformation
matric for the forward mappings, and then inverting it. The inverse
matric is used to transform the destination rectangles to the
surface-local coordinate system. The intersection of the rectangles is
the view clip mask.
Signed-off-by: Nobuhiko Tanibata
Reviewed-by: Pekka Paalanen
---
Changes for v2
- fix whitespaces
- rebase on master branch
ivi-shell/ivi-layout.c | 147 +++--
1 file changed, 141 insertions(+), 6 deletions(-)
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 827359a..24bd8dd 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -67,6 +67,8 @@
#include "shared/helpers.h"
#include "shared/os-compatibility.h"
+#define max(a, b) ((a) > (b) ? (a) : (b))
+
struct link_layer {
struct ivi_layout_layer *ivilayer;
struct wl_list link;
@@ -567,18 +569,127 @@ calc_transformation_matrix(struct ivi_rectangle
*source_rect,
weston_matrix_translate(m, translate_x, translate_y, 0.0f);
}
+/*
+ * This computes intersected rect_output from two ivi_rectangles
+ */
+static void
+ivi_rectangle_intersect(const struct ivi_rectangle *rect1,
+ const struct ivi_rectangle *rect2,
+ struct ivi_rectangle *rect_output)
+{
+ int32_t rect1_right = rect1->x + rect1->width;
+ int32_t rect1_bottom = rect1->y + rect1->height;
+ int32_t rect2_right = rect2->x + rect2->width;
+ int32_t rect2_bottom = rect2->y + rect2->height;
+
+ rect_output->x = max(rect1->x, rect2->x);
+ rect_output->y = max(rect1->y, rect2->y);
+ rect_output->width = rect1_right < rect2_right ?
+rect1_right - rect_output->x :
+rect2_right - rect_output->x;
+ rect_output->height = rect1_bottom < rect2_bottom ?
+ rect1_bottom - rect_output->y :
+ rect2_bottom - rect_output->y;
+
+ if (rect_output->width < 0 || rect_output->height < 0) {
+ rect_output->width = 0;
+ rect_output->height = 0;
+ }
+}
+
+/*
+ * Transform rect_input by the inverse of matrix, intersect with boundingbox,
+ * and store the result in rect_output.
+ * The boundingbox must be given in the same coordinate space as rect_output.
+ * Additionally, there are the following restrictions on the matrix:
+ * - no projective transformations
+ * - no skew
+ * - only multiples of 90-degree rotations supported
+ *
+ * In failure case of weston_matrix_invert, rect_output is set to boundingbox
+ * as a fail-safe with log.
+ */
+static void
+calc_inverse_matrix_transform(const struct weston_matrix *matrix,
+ const struct ivi_rectangle *rect_input,
+ const struct ivi_rectangle *boundingbox,
+ struct ivi_rectangle *rect_output)
+{
+ struct weston_matrix m;
+ struct weston_vector top_left;
+ struct weston_vector bottom_right;
+
+ assert(boundingbox != rect_output);
+
+ if (weston_matrix_invert(&m, matrix) < 0) {
+ weston_log("ivi-shell: calc_inverse_matrix_transform fails to
invert a matrix.\n");
+ weston_log("ivi-shell: boundingbox is set to the
rect_output.\n");
+ rect_output->x = boundingbox->x;
+ rect_output->y = boundingbox->y;
+ rect_output->width = boundingbox->width;
+ rect_output->height = boundingbox->height;
+ }
+
+ /* The vectors and matrices involved will always produce f[3] == 1.0. */
+ top_left.f[0] = rect_input->x;
+ top_left.f[1] = rect_input->y;
+ top_left.f[2] = 0.0f;
+ top_left.f[3] = 1.0f;
+
+ bottom_right.f[0] = rect_input->x + rect_input->width;
+ bottom_right.f[1] = rect_input->y + rect_input->height;
+ bottom_right.f[2] = 0.0f;
+ bottom_right.f[3] = 1.0f;
+
+ weston_matrix_transform(&m, &top_left);
+ weston_matrix_transform(&m, &bottom_right);
+
+ if (top_left.f[0] < bottom_right.f[0]) {
+ rect_output->x = top_left.f[0];
+ rect_output->width = bottom_right.f[0] - rect_output->x;
+ } else {
+ rect_output->x = bottom_right.f[0];
+ rect_output->width = top_left.f[0] - rect_output->x;
+ }
+
+ if (top_left.f[1] < bottom_right.f[1]) {
+ rect_output->y = top_left.f[1];
+ rect_output->height = bottom_right.f[1] - rect_output->y;
+ } else {
+ rect_output->y = bottom_right.f[1];
+ rect_output->height = top_left.f[1] - rect_output->y;
+ }
+
+
[PATCH weston] hmi-controller: fix the laucher layer width
From: Nobuhiko Tanibata
A layer for workspace is used to display icons for invoking applications
in several pages. These pages are swapped from one to next page. The
width of the layer was decided as a size of screen before reading
weston.ini. This worked correctly because there was no feature of
clipping of layer so the width of layer was not taken account.
Now clipping feature is supported. So the width shall be set to correct
one after reading weston.ini.
Signed-off-by: Nobuhiko Tanibata
Reviewed-by: Pekka Paalanen
---
ivi-shell/hmi-controller.c | 71 --
1 file changed, 44 insertions(+), 27 deletions(-)
diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index 760bf06..19ceef2 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -725,27 +725,9 @@ hmi_controller_create(struct weston_compositor *ec)
ivi_controller_interface->layer_set_visibility(
hmi_ctrl->workspace_background_layer.ivilayer, false);
- /* init workspace ivi_layer */
- hmi_ctrl->workspace_layer.x = hmi_ctrl->workspace_background_layer.x;
- hmi_ctrl->workspace_layer.y = hmi_ctrl->workspace_background_layer.y;
- hmi_ctrl->workspace_layer.width =
- hmi_ctrl->workspace_background_layer.width;
- hmi_ctrl->workspace_layer.height =
- hmi_ctrl->workspace_background_layer.height;
- hmi_ctrl->workspace_layer.id_layer =
- hmi_ctrl->hmi_setting->workspace_layer_id;
-
- create_layer(iviscrn, &hmi_ctrl->workspace_layer);
-
ivi_controller_interface->layer_set_opacity(hmi_ctrl->workspace_layer.ivilayer,
0);
-
ivi_controller_interface->layer_set_visibility(hmi_ctrl->workspace_layer.ivilayer,
- false);
wl_list_init(&hmi_ctrl->workspace_fade.layer_list);
tmp_link_layer = MEM_ALLOC(sizeof(*tmp_link_layer));
- tmp_link_layer->layout_layer = hmi_ctrl->workspace_layer.ivilayer;
- wl_list_insert(&hmi_ctrl->workspace_fade.layer_list,
- &tmp_link_layer->link);
- tmp_link_layer = MEM_ALLOC(sizeof(*tmp_link_layer));
tmp_link_layer->layout_layer =
hmi_ctrl->workspace_background_layer.ivilayer;
wl_list_insert(&hmi_ctrl->workspace_fade.layer_list,
@@ -980,12 +962,11 @@ static void
ivi_hmi_controller_add_launchers(struct hmi_controller *hmi_ctrl,
int32_t icon_size)
{
- struct ivi_layout_layer *layer = hmi_ctrl->workspace_layer.ivilayer;
int32_t minspace_x = 10;
int32_t minspace_y = minspace_x;
- int32_t width = hmi_ctrl->workspace_layer.width;
- int32_t height = hmi_ctrl->workspace_layer.height;
+ int32_t width = hmi_ctrl->workspace_background_layer.width;
+ int32_t height = hmi_ctrl->workspace_background_layer.height;
int32_t x_count = (width - minspace_x) / (minspace_x + icon_size);
int32_t space_x = (int32_t)((width - x_count * icon_size) / (1.0 +
x_count));
@@ -1015,6 +996,11 @@ ivi_hmi_controller_add_launchers(struct hmi_controller
*hmi_ctrl,
struct ivi_layout_surface* layout_surface = NULL;
uint32_t *add_surface_id = NULL;
+ struct ivi_layout_screen *iviscrn = NULL;
+ struct link_layer *tmp_link_layer = NULL;
+ struct ivi_layout_screen **pp_screen = NULL;
+ int32_t screen_length = 0;
+
if (0 == x_count)
x_count = 1;
@@ -1091,16 +1077,10 @@ ivi_hmi_controller_add_launchers(struct hmi_controller
*hmi_ctrl,
ivi_controller_interface->get_surface_from_id(data->surface_id);
assert(layout_surface);
- ret = ivi_controller_interface->layer_add_surface(layer,
layout_surface);
- assert(!ret);
-
ret =
ivi_controller_interface->surface_set_destination_rectangle(
layout_surface, x, y, icon_size, icon_size);
assert(!ret);
- ret =
ivi_controller_interface->surface_set_visibility(layout_surface, true);
- assert(!ret);
-
nx++;
if (x_count == nx) {
@@ -1109,6 +1089,43 @@ ivi_hmi_controller_add_launchers(struct hmi_controller
*hmi_ctrl,
}
}
+ /* init workspace ivi_layer */
+ hmi_ctrl->workspace_layer.x = hmi_ctrl->workspace_background_layer.x;
+ hmi_ctrl->workspace_layer.y = hmi_ctrl->workspace_background_layer.y;
+ hmi_ctrl->workspace_layer.width =
+ hmi_ctrl->workspace_background_layer.width *
hmi_ctrl->workspace_count;
+ hmi_ctrl->workspace_layer.height =
+ hmi_ctrl->workspace_background_layer.height;
+ hmi_ctrl->workspace_layer.id_layer =
+ hmi_ctrl->hmi_setting->workspace_layer_id;
+
+ ivi_controller_interface->get_screens(&screen_length, &pp_screen);
+ ivi
[PATCH weston] hmi-controller: fix wrong width and height are set to a layer of workspace.
From: Nobuhiko Tanibata Signed-off-by: Nobuhiko Tanibata Reviewed-by: Pekka Paalanen --- ivi-shell/hmi-controller.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c index 19ceef2..c388164 100644 --- a/ivi-shell/hmi-controller.c +++ b/ivi-shell/hmi-controller.c @@ -1287,8 +1287,8 @@ move_workspace_grab_end(struct move_grab *move, struct wl_resource* resource, duration); ivi_controller_interface->layer_set_destination_rectangle(layer, end_pos, pos_y, - hmi_ctrl->workspace_background_layer.width, - hmi_ctrl->workspace_background_layer.height); + hmi_ctrl->workspace_layer.width, + hmi_ctrl->workspace_layer.height); ivi_controller_interface->commit_changes(); } -- 1.8.3.1 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] ivi-layout: implement surface clipping
From: Nobuhiko Tanibata
View clip region is set in surface-local coordinates. To compute that
region, the ivi-layer destination rectangle in the global coordinates
are transformed back into the surface-local coordinates.
The transformation is computed by first forming the transformation
matric for the forward mappings, and then inverting it. The inverse
matric is used to transform the destination rectangles to the
surface-local coordinate system. The intersection of the rectangles is
the view clip mask.
Signed-off-by: Nobuhiko Tanibata
Reviewed-by: Pekka Paalanen
---
ivi-shell/ivi-layout.c | 148 +++--
1 file changed, 142 insertions(+), 6 deletions(-)
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index d412069..69adac7 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -58,6 +58,7 @@
#include "config.h"
#include
+#include
#include "compositor.h"
#include "ivi-layout-export.h"
@@ -66,6 +67,8 @@
#include "shared/helpers.h"
#include "shared/os-compatibility.h"
+#define max(a, b) ((a) > (b) ? (a) : (b))
+
struct link_layer {
struct ivi_layout_layer *ivilayer;
struct wl_list link;
@@ -586,18 +589,127 @@ calc_transformation_matrix(struct ivi_rectangle
*source_rect,
weston_matrix_translate(m, translate_x, translate_y, 0.0f);
}
+/*
+ * This computes intersected rect_output from two ivi_rectangles
+ */
+static void
+ivi_rectangle_intersect(const struct ivi_rectangle *rect1,
+ const struct ivi_rectangle *rect2,
+ struct ivi_rectangle *rect_output)
+{
+ int32_t rect1_right = rect1->x + rect1->width;
+ int32_t rect1_bottom = rect1->y + rect1->height;
+ int32_t rect2_right = rect2->x + rect2->width;
+ int32_t rect2_bottom = rect2->y + rect2->height;
+
+ rect_output->x = max(rect1->x, rect2->x);
+ rect_output->y = max(rect1->y, rect2->y);
+ rect_output->width = rect1_right < rect2_right ?
+rect1_right - rect_output->x :
+rect2_right - rect_output->x;
+ rect_output->height = rect1_bottom < rect2_bottom ?
+ rect1_bottom - rect_output->y :
+ rect2_bottom - rect_output->y;
+
+ if (rect_output->width < 0 || rect_output->height < 0) {
+ rect_output->width = 0;
+ rect_output->height = 0;
+ }
+}
+
+/*
+ * Transform rect_input by the inverse of matrix, intersect with boundingbox,
+ * and store the result in rect_output.
+ * The boundingbox must be given in the same coordinate space as rect_output.
+ * Additionally, there are the following restrictions on the matrix:
+ * - no projective transformations
+ * - no skew
+ * - only multiples of 90-degree rotations supported
+ *
+ * In failure case of weston_matrix_invert, rect_output is set to boundingbox
+ * as a fail-safe with log.
+ */
+static void
+calc_inverse_matrix_transform(const struct weston_matrix *matrix,
+ const struct ivi_rectangle *rect_input,
+ const struct ivi_rectangle *boundingbox,
+ struct ivi_rectangle *rect_output)
+{
+ struct weston_matrix m;
+ struct weston_vector top_left;
+ struct weston_vector bottom_right;
+
+ assert(boundingbox != rect_output);
+
+ if (weston_matrix_invert(&m, matrix) < 0) {
+ weston_log("ivi-shell: calc_inverse_matrix_transform fails to
invert a matrix.\n");
+ weston_log("ivi-shell: boundingbox is set to the
rect_output.\n");
+ rect_output->x = boundingbox->x;
+ rect_output->y = boundingbox->y;
+ rect_output->width = boundingbox->width;
+ rect_output->height = boundingbox->height;
+ }
+
+ /* The vectors and matrices involved will always produce f[3] == 1.0. */
+ top_left.f[0] = rect_input->x;
+ top_left.f[1] = rect_input->y;
+ top_left.f[2] = 0.0f;
+ top_left.f[3] = 1.0f;
+
+ bottom_right.f[0] = rect_input->x + rect_input->width;
+ bottom_right.f[1] = rect_input->y + rect_input->height;
+ bottom_right.f[2] = 0.0f;
+ bottom_right.f[3] = 1.0f;
+
+ weston_matrix_transform(&m, &top_left);
+ weston_matrix_transform(&m, &bottom_right);
+
+ if (top_left.f[0] < bottom_right.f[0]) {
+ rect_output->x = top_left.f[0];
+ rect_output->width = bottom_right.f[0] - rect_output->x;
+ } else {
+ rect_output->x = bottom_right.f[0];
+ rect_output->width = top_left.f[0] - rect_output->x;
+ }
+
+ if (top_left.f[1] < bottom_right.f[1]) {
+ rect_output->y = top_left.f[1];
+ rect_output->height = bottom_right.f[1] - rect_output->y;
+ } else {
+ rect_output->y = bottom_right.f[1];
+ rect_outp
Re: [PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"
On Mon, Aug 17, 2015 at 04:17:57PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d.
>
> Developers have been trying to reduce the number of by default required
> environment variables, and the mentioned commit is a step backwards in
> that sense. The fundamental assumption is that a user has only one main
> (Wayland) display server where all programs should connect to by
> default, and do so with an a priori known socket name.
>
> The commit also broke various use cases in the wild, some accidentally
> due to other causes, some intentionally. This revert allows those use
> cases to continue.
>
> The original problem of running Weston in a window in an existing GNOME
> X11 session and getting applications unintentionally launched into
> Weston can be circumvented by letting Weston use a non-default socket
> name, leaving wayland-0 unused.
>
> Discussion:
> http://lists.freedesktop.org/archives/wayland-devel/2015-August/023927.html
> http://lists.freedesktop.org/archives/wayland-devel/2015-August/023937.html
not a big fan of it, but Acked-by: Peter Hutterer
Cheers,
Peter
>
> Cc: Dima Ryazanov
> Cc: Giulio Camuffo
> Cc: Daniel Stone
> Cc: Jasper St. Pierre
> Cc: Ryo Munakata
> Cc: Ray Strode
> Cc: Peter Hutterer
> Cc: Matthias Clasen
> Cc: Sjoerd Simons
> Signed-off-by: Pekka Paalanen
> ---
> doc/man/wl_display_connect.xml| 5 +++--
> doc/publican/sources/Protocol.xml | 8
> src/wayland-client.c | 10 --
> 3 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index ded3cbd..7e6e05c 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -57,8 +57,9 @@
>that was previously opened by a Wayland server. The server socket
> must
>be placed in XDG_RUNTIME_DIR for this function to
>find it. The name argument specifies the name of
> - the socket or NULL to use the default
> - (which is the value of WAYLAND_DISPLAY). If
> + the socket or NULL to use the default (which
> is
> + "wayland-0"). The environment variable
> + WAYLAND_DISPLAY replaces the default value. If
>WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the
> file-descriptor
>number taken from the environment variable.
> diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> index 9464953..477063b 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -60,10 +60,10 @@
> Wire Format
>
>The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> - name is determined by the WAYLAND_DISPLAY
> - environment variable. Its value will usually be
> - wayland-0. The protocol is
> message-based.
> - A message sent by a client to the server is called request. A message
> + usually is named wayland-0
> + (although it can be changed via WAYLAND_DISPLAY
> + in the environment). The protocol is message-based. A
> + message sent by a client to the server is called request. A message
>from the server to a client is called event. Every message is
>structured as 32-bit words, values are represented in the host's
>byte-order.
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index ffbca4b..09c594a 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -764,11 +764,8 @@ connect_to_socket(const char *name)
>
> if (name == NULL)
> name = getenv("WAYLAND_DISPLAY");
> - if (name == NULL) {
> - wl_log("error: WAYLAND_DISPLAY not set in the environment.\n");
> - errno = ENOENT;
> - return -1;
> - }
> + if (name == NULL)
> + name = "wayland-0";
>
> fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> if (fd < 0)
> @@ -872,7 +869,8 @@ wl_display_connect_to_fd(int fd)
> * \return A \ref wl_display object or \c NULL on failure
> *
> * Connect to the Wayland display named \c name. If \c name is \c NULL,
> - * its value will be replaced with the WAYLAND_DISPLAY environment variable.
> + * its value will be replaced with the WAYLAND_DISPLAY environment
> + * variable if it is set, otherwise display "wayland-0" will be used.
> *
> * \memberof wl_display
> */
> --
> 2.4.6
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput: Halfkey/Mirrorboard implementation
Hi Bill On 19 August 2015 at 19:03, Bill Spitzak wrote: > On Tue, Aug 18, 2015 at 11:20 PM, Peter Hutterer > wrote: >> >> >> > My difficulties with xkb are in creating a mapping where by the space >> > bar >> > acts as both a modifier *and* a space bar. >> >> right. I don't think xkb will let you do this, at least not as a either/or >> case depending on e.g. how long you press. you'll need to designate a >> separate key for it. > > > He does not want "how long you press". What is wanted is that if the key is > pressed and then released without any other keys being pressed, it produces > the keysym (on the up event). It acts as a modifier in all cases (the client > will see the modifier flag turn on/off). Absolutely correct. > This is a very common request, usually for the opposite reason: to make a > modifier also produce a keysym. In particular it would allow Ctrl or AltGr > to act as a compose prefix, something a lot of plugins for Windows does, > while X (which invented the compose key) is forced to dedicate a key. > (compose is (I hope) actually done by the input method, which can in fact do > this handling of Ctrl, the problem is that it can't use the mapping of the > compose key, it has to actually use Ctrl, and thus it has to have a > different configuration file to control what key is the compose prefix than > the keyboard layout). > > This can also make Windows style things like Alt moving the focus to the > menubar, or the Super key popping up a dialog while still acting like a > modifier. I know these work on Linux but they do so because the apps are > actually looking at the Alt or Super key to see if they are released. It > seems more consistent that these actually produce a "Move to menubar" or > "super menu" keysym, thus allowing keyboard layouts to move them around. Yes - these are perfect examples. I guess you are saying that this is not currently handled by xkb, but by the desktop manager or UI toolkit? > And before you say "rollover" I am well aware of that. The toolkits handling > the Alt key are already dealing with this, and it is no excuse for > completely disabling functionality!. I think xkb could use the event > timestamps to detect this. Though it really sounds like that touch handling > stuff with all the fiddly timing and dependency on hardware details, so > maybe (yeah right) we could again consider moving keysym translation to > libinput and out of clients. What's 'rollover' in this context? -- Regards Kieran ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Libinput: Halfkey/Mirrorboard implementation
On 19 August 2015 at 07:20, Peter Hutterer wrote: > On Tue, Aug 18, 2015 at 05:47:43PM +0100, Kieran Bingham wrote: >> Hi Peter, >> >> Sorry for the late reply here, I've moved back from South America to England >> and had to look in to some of my assumptions! >> >> On 27 July 2015 at 06:07, Peter Hutterer wrote: >> > >> > Hi Kieran, >> > >> > On Fri, Jul 24, 2015 at 04:28:04PM -0500, Kieran Bingham wrote: >> > > Hi Guys, >> > > >> > > I've been working on a personal project to implement one-handed touch >> > > typing as an accessibility feature. >> > > >> > > There are software solutions for this available for Win/MacOS >> > > http://www.onehandkeyboard.org, and an (expensive) >> > > hardware solution available. There is also a solution which uses xkb >> > > mappings to utilise the caps-lock as a modifier, >> > > but this didn't meet my needs; along with a couple of outdated other >> > > linux >> > > alternatives mentioned at >> > > http://www.onehandkeyboard.org/linux-one-handed-keyboards/ >> > >> > so first of all, I appreciate your work. the first question I have here is >> > why the current solutions are insufficient, especially the xkb one. >> >> >> The xkb solution is the only real alternate contender here for me. >> (Hardware = cost, windows/mac != linux, other solutions = old+broken) >> >> My difficulties with xkb are in creating a mapping where by the space bar >> acts as both a modifier *and* a space bar. > > right. I don't think xkb will let you do this, at least not as a either/or > case depending on e.g. how long you press. you'll need to designate a > separate key for it. As I feared, - the really big power in this feature is that the keyboard acts normally until the space bar is held down. And it needs to be a central modifier so that both the left and right hand can both access it with ease. (Using the thumb to flip is very easy) >> > > I had originally started this using XLib hooks to capture all keyboard >> > > input and re-introduce keys through XTest. >> > > This wasn't the best solution however, and while reading up on wayland, I >> > > discovered libinput provides a good >> > > location for this work. And using the xf86-input-libinput wrapper for X >> > > I'm >> > > now using it on my laptop. >> > > >> > > Anyway, I thought I had got to a stage where I could share some code >> > > (although this is still a work in progress) >> > > >> > > I'd love to hear your feedback as to whether this is something that you >> > > would like to integrate, or for me to continue working on. >> > > (I'll continue to use it for personal use, but if its desired, I can work >> > > on improvements to upstream it) >> > >> > I'm wondering if libinput is the right position in the stack to handle >> > this. >> > libinput is a hw abstraction that makes the hw easier to deal with, more >> > complex things should go into the higher layers. >> >> Exactly - I had assumed (which now I think may be wrong) that libinput was >> effectively passing up the equivalent to scancodes which are then modified >> by X to perform the keyboard mappings. > > That's correct, libinput passes evdev codes (see the KEY_* defines in > linux/input.h) to the xf86-input-libinput driver which simply adds 8 > (historical reasons) and passes that on. in that it's no different to e.g. > evdev. > >> I was hoping to be able to generate >> a solution which will act 'under' the keyboard layouts so that it doesn't >> matter >> what the key is ... it is being mirrored as if it was a hardware mirror. > > that is possible, but only while you're assuming that the HW is mostly > identical, and this is where the difficulty lies. take your normal PC > keyboard and it won't matter if the layout up-top is us or fr. take a laptop > keyboard and it starts to matter, since the keys are suddenly all over the > place. > For the most part, I'd expect only the main row keys to be mirrored, So I would expect limitations. Do you know of any keyboards that don't have the usual main rows? - i.e. A-Z and numbers albeit in a localised layout? Ideally there would be a way for users to customise, perhaps with a configuration file, or GUI ... but I'm getting ahead of myself here if its not feasible :) -- Regards Kieran > Cheers, >Peter > >> I'd (foolisly) hoped for a single solution that would map on to french azerty >> keyboards, just the same as it would map to a us/en qwerty by simply >> mirroring >> under the layout definitions. Now that I've dug deeper into xkb - I see that >> it >> would of course be more complicated than that anyway. >> >> >> > >> > Flipping keyboard layouts is semantically more complicated than what >> > libinput knows about the keyboard (e.g. we don't handle keyboard layouts) >> > so >> > you'll likely run into a number of issues here when the keyboard layouts >> > differ from the us default. That's a nonissue for a local installation, but >> > a bigger issue when we'd try to merge this as a generic solution for all >> >
Re: [PATCH wayland] Revert "client: require WAYLAND_DISPLAY to be set"
Although I personally like the current behavior, I think this revert is
reasonable.
Acked-By: Ryo Munakata
Thanks.
On Mon, 17 Aug 2015 16:17:57 +0300
Pekka Paalanen wrote:
> From: Pekka Paalanen
>
> This reverts commit fb7e13021730d0a5516ecbd3712ea4235e05d24d.
>
> Developers have been trying to reduce the number of by default required
> environment variables, and the mentioned commit is a step backwards in
> that sense. The fundamental assumption is that a user has only one main
> (Wayland) display server where all programs should connect to by
> default, and do so with an a priori known socket name.
>
> The commit also broke various use cases in the wild, some accidentally
> due to other causes, some intentionally. This revert allows those use
> cases to continue.
>
> The original problem of running Weston in a window in an existing GNOME
> X11 session and getting applications unintentionally launched into
> Weston can be circumvented by letting Weston use a non-default socket
> name, leaving wayland-0 unused.
>
> Discussion:
> http://lists.freedesktop.org/archives/wayland-devel/2015-August/023927.html
> http://lists.freedesktop.org/archives/wayland-devel/2015-August/023937.html
>
> Cc: Dima Ryazanov
> Cc: Giulio Camuffo
> Cc: Daniel Stone
> Cc: Jasper St. Pierre
> Cc: Ryo Munakata
> Cc: Ray Strode
> Cc: Peter Hutterer
> Cc: Matthias Clasen
> Cc: Sjoerd Simons
> Signed-off-by: Pekka Paalanen
> ---
> doc/man/wl_display_connect.xml| 5 +++--
> doc/publican/sources/Protocol.xml | 8
> src/wayland-client.c | 10 --
> 3 files changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/doc/man/wl_display_connect.xml b/doc/man/wl_display_connect.xml
> index ded3cbd..7e6e05c 100644
> --- a/doc/man/wl_display_connect.xml
> +++ b/doc/man/wl_display_connect.xml
> @@ -57,8 +57,9 @@
>that was previously opened by a Wayland server. The server socket
> must
>be placed in XDG_RUNTIME_DIR for this function to
>find it. The name argument specifies the name of
> - the socket or NULL to use the default
> - (which is the value of WAYLAND_DISPLAY). If
> + the socket or NULL to use the default (which
> is
> + "wayland-0"). The environment variable
> + WAYLAND_DISPLAY replaces the default value. If
>WAYLAND_SOCKET is set, this function behaves like
>wl_display_connect_to_fd with the
> file-descriptor
>number taken from the environment variable.
> diff --git a/doc/publican/sources/Protocol.xml
> b/doc/publican/sources/Protocol.xml
> index 9464953..477063b 100644
> --- a/doc/publican/sources/Protocol.xml
> +++ b/doc/publican/sources/Protocol.xml
> @@ -60,10 +60,10 @@
> Wire Format
>
>The protocol is sent over a UNIX domain stream socket, where the
> endpoint
> - name is determined by the WAYLAND_DISPLAY
> - environment variable. Its value will usually be
> - wayland-0. The protocol is
> message-based.
> - A message sent by a client to the server is called request. A message
> + usually is named wayland-0
> + (although it can be changed via WAYLAND_DISPLAY
> + in the environment). The protocol is message-based. A
> + message sent by a client to the server is called request. A message
>from the server to a client is called event. Every message is
>structured as 32-bit words, values are represented in the host's
>byte-order.
> diff --git a/src/wayland-client.c b/src/wayland-client.c
> index ffbca4b..09c594a 100644
> --- a/src/wayland-client.c
> +++ b/src/wayland-client.c
> @@ -764,11 +764,8 @@ connect_to_socket(const char *name)
>
> if (name == NULL)
> name = getenv("WAYLAND_DISPLAY");
> - if (name == NULL) {
> - wl_log("error: WAYLAND_DISPLAY not set in the environment.\n");
> - errno = ENOENT;
> - return -1;
> - }
> + if (name == NULL)
> + name = "wayland-0";
>
> fd = wl_os_socket_cloexec(PF_LOCAL, SOCK_STREAM, 0);
> if (fd < 0)
> @@ -872,7 +869,8 @@ wl_display_connect_to_fd(int fd)
> * \return A \ref wl_display object or \c NULL on failure
> *
> * Connect to the Wayland display named \c name. If \c name is \c NULL,
> - * its value will be replaced with the WAYLAND_DISPLAY environment variable.
> + * its value will be replaced with the WAYLAND_DISPLAY environment
> + * variable if it is set, otherwise display "wayland-0" will be used.
> *
> * \memberof wl_display
> */
> --
> 2.4.6
>
--
Ryo Munakata
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
