Re: Introduction and updates from NVIDIA
On Tue, Mar 22, 2016 at 05:12:52PM -0700, Andy Ritger wrote: > Thanks for the thorough responses, Daniel. > > On Tue, Mar 22, 2016 at 01:49:59PM +, Daniel Stone wrote: > > Secondly, looking at the compositor-drm case, the use of the dumb > > buffer to display undefined content as a dummy modeset really makes me > > uneasy, > > Yes, the use of dumb buffer in this patch series is a kludge. If we > were going to use drmModeSetCrtc + EGLStreams, I think we'd want to > pass no fb to drmModeSetCrtc, but that currently gets rejected by DRM. > Are surface-less modesets intended to be allowable in DRM? I can hunt > that down if that is intended to work. Of course, better to work out > how EGLStreams should cooperate with atomic KMS. Side comment: With universal planes (and hence atomic) you can light up a CRTC without any planes enabled. If your hw can do it. It's supposed to be black in that case, and there's some pages floating around to control the background colour (if anyone ever wants to change that ...). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Introduction and updates from NVIDIA
On Tue, Mar 22, 2016 at 05:33:57PM -0700, Andy Ritger wrote: > On Tue, Mar 22, 2016 at 09:52:21PM +, Daniel Stone wrote: > > Hi, > > > > On 22 March 2016 at 21:43, Daniel Vetter wrote: > > > On Tue, Mar 22, 2016 at 01:49:59PM +, Daniel Stone wrote: > [...] > > >> I think it's been good to have this series to push the discussion > > >> further in more concrete terms, but unfortunately I have to say that > > >> I'm even less convinced now than I have ever been. Sorry. > > > > > > Well the thing that irks me is that this isn't aiming to build a common > > > platform. There's definitely issues with gbm/gralloc+kms+egl in upstream > > > repos, and vendors have hacked around those in all kinds of horrible ways. > > > But trying to fix this mess with yet another vendor-private solution just > > > doesn't help. Instead we need to fix what is there, for everyone, instead > > > of fragmenting more. > > > > Agreed. One of the things I've been incredibly happy with is how our > > platform has managed to stay completely generic and vendor-neutral so > > far, and I'd love to preserve that. > > I don't think you'll find any disagreement to that from NVIDIA, either. > > I apologize if the EGLStreams proposal gave the impression of a > vendor-private solution. That wasn't the intent. The EGLStream family > of extensions are, after all, an open specification that any EGL vendor > can implement. If there are aspects of any of these EGL extensions that > seem useful, I'd hope that Mesa would we willing to adopt them. > > We (NVIDIA) clearly think EGLStreams is a good direction for expressing > buffer sharing semantics. In our ideal world, everyone would implement > these extensions and Wayland compositors would migrate to using them as > the generic vendor-neutral mechanism for buffer sharing :) > > But, I'm also happy discuss ways to incrementally improve gbm. I tried > to address Daniel (Stone)'s questions about NVIDIA's gbm concerns. For this: So I guess the top level issue with eglstreams+kms that at least I see is that if we really want to do this, we would need to terminate the eglstream in the kernel. Since with kms really only the kernel knows why exactly a buffer isn't the right one, and what the producer should change to get to a more optimal setup. But the problem is that KMS is ABI and vendor-neutral, which means all that fancy metadata that you want to attach would need to be standardized in some way. And we'd need to have in-kernel eglstreams. So you'd face both the problem of getting a new primitive into upstream (dma-buf took massive efforts, same for fences going on now). And you'd lose the benefit of eglstreams being able to encapsulate vendor metadata. And we need to figure out how to standardize this a bit better even without eglstreams, so that's why I don't really understand why eglstreams has benefits. It's clearly a nice concept if your in a world of one-vendor-only, but that's not what KMS is aiming for really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v6] input: use doubles in the interfaces to notify of input events
On Tue, 22 Mar 2016 17:44:54 +0200 Giulio Camuffo wrote: > This patch is a further step in the wl_fixed_t internal sanitization. > It changes the notify_* functions to take doubles instead of wl_fixed_t > but does not change how these are stored in the various input structs > yet, except for weston_pointer_axis_event. > However this already allows to remove all wl_fixed_t usage in places > like the libinput or the x11 backend. > > Reviewed-by: Daniel Stone > Reviewed-by: Pekka Paalanen > --- > > v6: fixed pointer going out of sync with the x11 backend > > desktop-shell/shell.c| 6 +++--- > src/compositor-rdp.c | 12 +++ > src/compositor-wayland.c | 56 > +--- > src/compositor-x11.c | 22 +-- > src/compositor.c | 12 +-- > src/compositor.h | 12 +-- > src/input.c | 19 ++-- > src/libinput-device.c| 26 ++ > src/screen-share.c | 5 +++-- > 9 files changed, 89 insertions(+), 81 deletions(-) Enough, pushed: fcf4b6c..90a6fc6 master -> master Let's see if any bug reports come up. :-D Thanks, pq pgpBsUWsiedzZ.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH weston] compositor.h: Add shell_interface.get_output_work_area
From: Quentin Glidic
This will allow plugins to be aware of e.g. panels, to avoid covering
them with other surfaces.
Signed-off-by: Quentin Glidic
---
desktop-shell/shell.c | 4 +++-
src/compositor.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
index 24437d8..9b01f4f 100644
--- a/desktop-shell/shell.c
+++ b/desktop-shell/shell.c
@@ -453,10 +453,11 @@ get_output_panel_size(struct desktop_shell *shell,
}
static void
-get_output_work_area(struct desktop_shell *shell,
+get_output_work_area(void *data,
struct weston_output *output,
pixman_rectangle32_t *area)
{
+ struct desktop_shell *shell = data;
int32_t panel_width = 0, panel_height = 0;
area->x = output->x;
@@ -6625,6 +6626,7 @@ module_init(struct weston_compositor *ec,
ec->shell_interface.set_window_geometry = set_window_geometry;
ec->shell_interface.set_maximized = shell_interface_set_maximized;
ec->shell_interface.set_pid = set_pid;
+ ec->shell_interface.get_output_work_area = get_output_work_area;
weston_layer_init(&shell->fullscreen_layer, &ec->cursor_layer.link);
weston_layer_init(&shell->panel_layer, &shell->fullscreen_layer.link);
diff --git a/src/compositor.h b/src/compositor.h
index 08b4059..d61a327 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -116,6 +116,7 @@ struct weston_shell_interface {
int32_t width, int32_t height);
void (*set_maximized)(struct shell_surface *shsurf);
void (*set_pid)(struct shell_surface *shsurf, pid_t pid);
+ void (*get_output_work_area)(void *shell, struct weston_output *output,
pixman_rectangle32_t *area);
};
struct weston_animation {
--
2.7.2
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC weston 2/2] RFC: Example of using plugin-registry
From: Pekka Paalanen
The desktop shell plugin exports what is essentially the struct
weston_shell_interface API. Xwayland is modified to show how it could
find that API.
This patch does not compile, it is merely a demonstration of the
concept: the intended way to use the plugin registry.
Noteworthy things:
- shell-api.h is a model for how to write public API headers
- no specific fields are needed in struct weston_compositor
- the module context, struct desktop_shell, can be found through
weston_compositor in desktop_shell_get()
- when is weston_plugin_api_register() called
- when is weston_pluhin_api_get() called (via
weston_get_desktop_shell_api())
- what needs to be stored in the importer context (struct
weston_xserver)
---
desktop-shell/shell-api.h | 125 ++
desktop-shell/shell.c | 27 ++
xwayland/launcher.c | 16 ++
xwayland/xwayland.h | 3 ++
4 files changed, 171 insertions(+)
create mode 100644 desktop-shell/shell-api.h
diff --git a/desktop-shell/shell-api.h b/desktop-shell/shell-api.h
new file mode 100644
index 000..3896950
--- /dev/null
+++ b/desktop-shell/shell-api.h
@@ -0,0 +1,125 @@
+/*
+ * Copyright © 2008-2011 Kristian Høgsberg
+ * Copyright © 2012 Collabora, Ltd.
+ * Copyright (C) 2016 DENSO CORPORATION
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#ifndef WESTON_DESKTOP_SHELL_API_H
+#define WESTON_DESKTOP_SHELL_API_H
+
+#include "plugin-registry.h"
+
+#include
+#include
+
+/** \file
+ *
+ * This is the API exported by the desktop shell plugin for transplanting
+ * windows from other window systems. It is published through
+ * weston_plugin_api_register().
+ */
+
+struct desktop_shell;
+
+struct weston_surface;
+struct weston_pointer;
+struct weston_output;
+struct shell_surface;
+
+struct weston_shell_client {
+ void
+ (*send_configure)(struct weston_surface *surface,
+ int32_t width, int32_t height);
+
+ void
+ (*send_position)(struct weston_surface *surface,
+int32_t x, int32_t y);
+};
+
+#define WESTON_DESKTOP_SHELL_API_NAME "desktop-shell-v1"
+
+/** The desktop shell window API
+ *
+ * Desktop shell is a Weston plugin that provides window management for
+ * desktop applications. Other plugins can use this API to transplant
+ * windows from other window systems, provided there is a conversion
+ * application already creating wl_surfaces.
+ */
+struct weston_shell_api {
+ struct desktop_shell *
+ get_desktop_shell(struct weston_compositor *compositor);
+
+ struct shell_surface *
+ (*create_shell_surface)(struct desktop_shell *shell,
+ struct weston_surface *surface,
+ const struct weston_shell_client *client);
+
+ void
+ (*set_toplevel)(struct shell_surface *shsurf);
+
+ void
+ (*set_transient)(struct shell_surface *shsurf,
+struct weston_surface *parent,
+int x, int y, uint32_t flags);
+
+ void
+ (*set_fullscreen)(struct shell_surface *shsurf,
+ uint32_t method,
+ uint32_t framerate,
+ struct weston_output *output);
+
+ void
+ (*set_xwayland)(struct shell_surface *shsurf,
+ int x, int y, uint32_t flags);
+
+ int
+ (*move)(struct shell_surface *shsurf, struct weston_pointer *pointer);
+
+ int
+ (*resize)(struct shell_surface *shsurf,
+ struct weston_pointer *pointer, uint32_t edges);
+
+ void
+ (*set_title)(struct shell_surface *shsurf, const char *title);
+
+ void
+ (*set_window_geometry)(struct shell_surface *shsurf,
+ int32_t x, int32_t y,
+ int32_t width,
[RFC weston 1/2] compositor: add plugin-registry
From: Pekka Paalanen
Implement a simple register and lookup for function tables. This is
intended for plugins to expose APIs to other plugins.
It has been very hard to arrange a plugin to be able to call into
another plugin without modifying Weston core to explicitly support each
case. This patch fixes that.
The tests all pass.
Signed-off-by: Pekka Paalanen
---
Makefile.am | 8 +++
src/compositor.c | 6 ++
src/compositor.h | 2 +
src/plugin-registry.c| 163 +++
src/plugin-registry.h| 55 +++
tests/plugin-registry-test.c | 101 +++
6 files changed, 335 insertions(+)
create mode 100644 src/plugin-registry.c
create mode 100644 src/plugin-registry.h
create mode 100644 tests/plugin-registry-test.c
diff --git a/Makefile.am b/Makefile.am
index d1644ac..1a90fd5 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -83,6 +83,8 @@ weston_SOURCES = \
src/noop-renderer.c \
src/pixman-renderer.c \
src/pixman-renderer.h \
+ src/plugin-registry.c \
+ src/plugin-registry.h \
src/timeline.c \
src/timeline.h \
src/timeline-object.h \
@@ -207,6 +209,7 @@ westonincludedir = $(includedir)/weston
westoninclude_HEADERS =\
src/version.h \
src/compositor.h\
+ src/plugin-registry.h \
src/timeline-object.h \
shared/matrix.h \
shared/config-parser.h \
@@ -1084,6 +1087,7 @@ shared_tests =\
zuctest
module_tests = \
+ plugin-registry-test.la \
surface-test.la \
surface-global-test.la
@@ -1134,6 +1138,10 @@ noinst_PROGRAMS += \
test_module_ldflags = \
-module -avoid-version -rpath $(libdir) $(COMPOSITOR_LIBS)
+plugin_registry_test_la_SOURCES = tests/plugin-registry-test.c
+plugin_registry_test_la_LDFLAGS = $(test_module_ldflags)
+plugin_registry_test_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
+
surface_global_test_la_SOURCES = tests/surface-global-test.c
surface_global_test_la_LDFLAGS = $(test_module_ldflags)
surface_global_test_la_CFLAGS = $(AM_CFLAGS) $(COMPOSITOR_CFLAGS)
diff --git a/src/compositor.c b/src/compositor.c
index d8f3e34..ba31379 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -61,6 +61,7 @@
#include "shared/timespec-util.h"
#include "git-version.h"
#include "version.h"
+#include "plugin-registry.h"
#define DEFAULT_REPAINT_WINDOW 7 /* milliseconds */
@@ -4770,6 +4771,8 @@ weston_compositor_create(struct wl_display *display, void
*user_data)
wl_list_init(&ec->axis_binding_list);
wl_list_init(&ec->debug_binding_list);
+ wl_list_init(&ec->plugin_api_list);
+
weston_plane_init(&ec->primary_plane, ec, 0, 0);
weston_compositor_stack_plane(ec, &ec->primary_plane, NULL);
@@ -5021,6 +5024,9 @@ weston_compositor_destroy(struct weston_compositor
*compositor)
if (compositor->backend)
compositor->backend->destroy(compositor);
+
+ weston_plugin_api_destroy_list(compositor);
+
free(compositor);
}
diff --git a/src/compositor.h b/src/compositor.h
index 08b4059..fc29490 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -766,6 +766,8 @@ struct weston_compositor {
struct weston_launcher *launcher;
+ struct wl_list plugin_api_list; /* struct weston_plugin_api::link */
+
uint32_t output_id_pool;
struct xkb_rule_names xkb_names;
diff --git a/src/plugin-registry.c b/src/plugin-registry.c
new file mode 100644
index 000..3890d28
--- /dev/null
+++ b/src/plugin-registry.c
@@ -0,0 +1,163 @@
+/*
+ * Copyright (C) 2016 DENSO CORPORATION
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT
[RFC weston 0/2] Plugin registry
From: Pekka Paalanen Hi, here are two patches. The first one implements the plugin registry, and the second one is a demonstration on how you might use it. Plugin registry is meant for plugins to hook up to other plugins. A plugin exporting an API registers it, and a plugin looking for to use an API can find it. An API is essentially a virtual function table, a struct filled with function pointers. Each API has a name that identifies it. Multiple plugins cannot register the same API name, nor can an API be unregistered to keep the implementation simple. The main benefit of this approach is that we do not need to store an explicit pointer in struct weston_compositor for evert API one might expose to other plugins or the core. It's a tiny step towards making weston_compositor opaque. APIs like struct weston_renderer probably would not use plugin registry as is, because the core always needs exactly one renderer, and a renderer is initialized explicitly by a backend. The plugin registry is meant for more dynamic things. The example of using a shell API from the xwayland plugin is more towards the intended use, though perhaps arguable. I am working on something that is not ready to be posted yet, but I thought this little piece of it might be of interest already, particularly for libweston, maybe. I would consider patch 1 to be of mergeable quality, if there just was a user for the feature. Thanks, pq Pekka Paalanen (2): compositor: add plugin-registry RFC: Example of using plugin-registry Makefile.am | 8 +++ desktop-shell/shell-api.h| 125 + desktop-shell/shell.c| 27 +++ src/compositor.c | 6 ++ src/compositor.h | 2 + src/plugin-registry.c| 163 +++ src/plugin-registry.h| 55 +++ tests/plugin-registry-test.c | 101 +++ xwayland/launcher.c | 16 + xwayland/xwayland.h | 3 + 10 files changed, 506 insertions(+) create mode 100644 desktop-shell/shell-api.h create mode 100644 src/plugin-registry.c create mode 100644 src/plugin-registry.h create mode 100644 tests/plugin-registry-test.c -- 2.7.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH wayland] Add API to install protocol loggers on the server wl_display
The new wl_display_add_protocol_logger allows to set a function as
a logger, which will get called when a new request is received or an
event is sent.
This is akin to setting WAYLAND_DEBUG=1, but more powerful because it
can be enabled at run time and allows to show the log e.g. in a UI view.
Signed-off-by: Giulio Camuffo
---
src/connection.c | 117 ++
src/wayland-private.h | 4 ++
src/wayland-server-core.h | 13 ++
src/wayland-server.c | 94 ++---
4 files changed, 192 insertions(+), 36 deletions(-)
diff --git a/src/connection.c b/src/connection.c
index c0e322f..f6447c0 100644
--- a/src/connection.c
+++ b/src/connection.c
@@ -1181,71 +1181,128 @@ wl_closure_queue(struct wl_closure *closure, struct
wl_connection *connection)
return result;
}
-void
-wl_closure_print(struct wl_closure *closure, struct wl_object *target, int
send)
+static inline int
+min(int a, int b)
+{
+ return a < b ? a : b;
+}
+
+/** Formats the closure and returns a static const char * with the value,
+ * in the 'interface@id.message_name(args)' format.
+ * DO NOT free or mess with the returned pointer.
+ */
+const char *
+wl_closure_format(struct wl_closure *closure, struct wl_object *target)
{
+ static char *buffer = NULL;
+ static size_t buf_size;
int i;
struct argument_details arg;
const char *signature = closure->message->signature;
- struct timespec tp;
- unsigned int time;
+ size_t size = 0;
- clock_gettime(CLOCK_REALTIME, &tp);
- time = (tp.tv_sec * 100L) + (tp.tv_nsec / 1000);
+ if (!buffer) {
+ buf_size = 128;
+ buffer = malloc(buf_size);
+ }
- fprintf(stderr, "[%10.3f] %s%s@%u.%s(",
- time / 1000.0,
- send ? " -> " : "",
- target->interface->name, target->id,
- closure->message->name);
+ size = snprintf(buffer, buf_size, "%s@%u.%s(",
+ target->interface->name, target->id,
+ closure->message->name);
for (i = 0; i < closure->count; i++) {
signature = get_next_argument(signature, &arg);
if (i > 0)
- fprintf(stderr, ", ");
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size),
+", ");
switch (arg.type) {
case 'u':
- fprintf(stderr, "%u", closure->args[i].u);
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size),
+"%u", closure->args[i].u);
break;
case 'i':
- fprintf(stderr, "%d", closure->args[i].i);
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size),
+"%d", closure->args[i].i);
break;
case 'f':
- fprintf(stderr, "%f",
- wl_fixed_to_double(closure->args[i].f));
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size), "%f",
+
wl_fixed_to_double(closure->args[i].f));
break;
case 's':
- fprintf(stderr, "\"%s\"", closure->args[i].s);
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size),
+"\"%s\"", closure->args[i].s);
break;
case 'o':
if (closure->args[i].o)
- fprintf(stderr, "%s@%u",
- closure->args[i].o->interface->name,
- closure->args[i].o->id);
+ size += snprintf(buffer + size,
+buf_size - min(size,
buf_size), "%s@%u",
+
closure->args[i].o->interface->name,
+closure->args[i].o->id);
else
- fprintf(stderr, "nil");
+ size += snprintf(buffer + size,
+buf_size - min(size, buf_size),
+"nil");
break;
case 'n':
- fprintf(stderr, "new id %s@",
- (closure->message->types[i]) ?
-
Re: [PATCH wayland-protocols v5] text: Create second version of text input protocol
There is a reference implementation of this version of the protocol in QtWayland https://codereview.qt-project.org/#/c/153711/ where the text-input protocol is used to proxy the Qt input method of Qt Wayland clients to the Qt input method on compositor side. One can then use for example the qtvirtualkeyboard (which plugs in the Qt input method system) in the Qt compositor and use that to input text in all clients. Jan Arne Petersen On Mon, Mar 14, 2016 at 12:58 PM Jan Arne Petersen wrote: > There were some shortcomings in the first version of the protocol which > makes it not really useful in real world applications. It is not really > possible to fix them in a compatible way so introduce a new v2 of the > protocol. > > Fixes some shortcomings of the first version: > > * Use only one wp_text_input per wl_seat (client side should be > handled by client toolkit) > * Allow focus tracking without wl_keyboard present > * Improve update state handling and better define state handling > > Signed-off-by: Jan Arne Petersen > --- > Chnages to v4: >* Improved descriptions >* Remove invoke_action request > > unstable/text-input/text-input-unstable-v2.xml | 484 > + > 1 file changed, 484 insertions(+) > create mode 100644 unstable/text-input/text-input-unstable-v2.xml > > diff --git a/unstable/text-input/text-input-unstable-v2.xml > b/unstable/text-input/text-input-unstable-v2.xml > new file mode 100644 > index 000..1e64c4b > --- /dev/null > +++ b/unstable/text-input/text-input-unstable-v2.xml > @@ -0,0 +1,484 @@ > + > + > + > + > +Copyright © 2012, 2013 Intel Corporation > +Copyright © 2015, 2016 Jan Arne Petersen > + > +Permission to use, copy, modify, distribute, and sell this > +software and its documentation for any purpose is hereby granted > +without fee, provided that the above copyright notice appear in > +all copies and that both that copyright notice and this permission > +notice appear in supporting documentation, and that the name of > +the copyright holders not be used in advertising or publicity > +pertaining to distribution of the software without specific, > +written prior permission. The copyright holders make no > +representations about the suitability of this software for any > +purpose. It is provided "as is" without express or implied > +warranty. > + > +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS > +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND > +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY > +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN > +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, > +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF > +THIS SOFTWARE. > + > + > + > + > + The zwp_text_input_v2 interface represents text input and input > methods > + associated with a seat. It provides enter/leave events to follow the > + text input focus for a seat. > + > + Requests are used to enable/disable the text-input object and set > + state information like surrounding and selected text or the content > type. > + The information about the entered text is sent to the text-input > object > + via the pre-edit and commit events. Using this interface removes > the need > + for applications to directly process hardware key events and > compose text > + out of them. > + > + Text is valid UTF-8 encoded, indices and lengths are in bytes. > Indices > + have to always point to the first byte of an UTF-8 encoded code > point. > + Lengths are not allowed to contain just a part of an UTF-8 encoded > code > + point. > + > + State is sent by the state requests (set_surrounding_text, > + set_content_type, set_cursor_rectangle and set_preferred_language) > and > + an update_state request. After an enter or an input_method_change > event > + all state information is invalidated and needs to be resent from the > + client. A reset or entering a new widget on client side also > + invalidates all current state information. > + > + Serials are used to synchronize the state between the client and > + an input method. New serials are sent by the text input in the > + update_state request and are used by the input method to indicate > + the known text input state in events like preedit_string, > commit_string, > + and keysym. The text input can then ignore events from the input > method > + which are based on an outdated state (for example after a reset). > + > + > + > + > + Destroy the wp_text_input object. Also disables all surfaces > enabled > + through this wp_text_input object > + > + > + > + > + > + Enable text input in a surface (usually
Re: [PATCH weston 0/5] simple ivi-shell fortification
Hi Pekka, I'm working in the same team with Emre and Natsume-san please find some comments below On 22.03.2016 15:48, Pekka Paalanen wrote: From: Pekka Paalanen Hi, I have written these simple patches as a side-product, and I'm proposing to merge them upstream. They are mostly just adding sanity checks, except the last one that is a possible behavioral change. I'm not sure what the proper response in hmi-controller would be in patch 5, and there probably is no way to test it readily. Feel free to reject that one if it's a too lazy patch. agree to all patches besides the patch: [PATCH weston 5/5] ivi-shell: forward zero size to controller will add some comments in reply to the patch itself Thanks, pq Pekka Paalanen (5): ivi-shell: add shell surface labels ivi-shell: add input panel label func ivi-shell: add sanity check in ivi_shell_surface_configure ivi-shell: harden get_ivi_shell_surface() ivi-shell: forward zero size to controller ivi-shell/hmi-controller.c | 2 ++ ivi-shell/input-panel-ivi.c | 8 ivi-shell/ivi-shell.c | 31 +++ 3 files changed, 37 insertions(+), 4 deletions(-) ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Proposal for Anti-Keystroke Fingerprinting at the Display Server Level
== Attack Description == Keystroke fingerprinting works by measuring how long keys are pressed and the time between presses. Its very high accuracy poses a serious threat to anonymous users.[1] This tracking technology has been deployed by major advertisers (Google, Facebook), banks and massive online courses. Its also happening at a massive scale because just using a JS application (or SSH in interactive mode) in presence of a network adversary that records all traffic allows them to construct biometric models for virtually everyone (think Google suggestions) even if the website does not record these biometric stats itself.[2] They have this data from everyone's clearnet browsing and by comparing this to data exiting the Tor network they will unmask users. == Current Measures and Threat Model == While the Tor Browser team is aware of the problem and working on a solution, current measures [6] are not enough. [4][5] It's very useful to have it fixed on the host OS (display server) level so even compromised VMs could not perform keystroke fingerprinting. Another reason is, that other applications (chat clients come to mind) and others that implement javascript one or another way, may be leaking this also. So having this fixed in Tor Browser is nice but non-ideal. This is valid for systems running in VMs or on bare metal such as the TAILS Anonymous distro. == Existing Work on Countermeasures == As a countermeasure security researcher Paul Moore created a prototype Chrome plugin known as KeyboardPrivacy. It works by caching keystrokes and introducing a random delay before passing them on to a webpage.[3] Unfortunately there is no source code available for the add-on and the planned Firefox version has not surfaced so far. There are hints that the author wants to create a closed hardware USB device that implements this which does not help our cause. A widely deployed libre version only makes sense and would have the greatest impact for security of most free/open systems out there. == Proposal for a System-wide Solution == A very much needed project would be to write a program that mimics the functionality of the this add-on but on the kernel level. Implementing it in the display server ensures absolutely everything consuming input events on a workstation is protected. Ideally the solution would be compatible with Wayland for the upcoming transition in the near future. [1] http://arstechnica.com/security/2015/07/how-the-way-you-type-can-shatter-anonymity-even-on-tor/ [2] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=7358795 [3] https://archive.is/vCvWb [4] https://www.lightbluetouchpaper.org/2015/07/30/double-bill-password-hashing-competition-keyboardprivacy/#comment-1288166 [5] https://trac.torproject.org/projects/tor/ticket/16110 [6] https://trac.torproject.org/projects/tor/ticket/1517 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston 5/5] ivi-shell: forward zero size to controller
Hi,
this is indeed a change in behavior, there is a case in ivi-controller
where the ivi surface has not width and height it is the time between
the ivi surface is created but the corresponding wayland surface did not
received any buffer so far. Of cause wayland surface might also get
buffer attached with size zero but this case is not properly handled
currently.
I would like to skip this patch for the time being
On 22.03.2016 15:48, Pekka Paalanen wrote:
From: Pekka Paalanen
When surface size changes to zero, do not ignore it, but forward that
change to the controller. A controller should do what's proper for a
surface that just lost its content.
Signed-off-by: Pekka Paalanen
---
ivi-shell/hmi-controller.c | 2 ++
ivi-shell/ivi-shell.c | 3 ---
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/ivi-shell/hmi-controller.c b/ivi-shell/hmi-controller.c
index e9c9ab0..7c96439 100644
--- a/ivi-shell/hmi-controller.c
+++ b/ivi-shell/hmi-controller.c
@@ -660,6 +660,8 @@ set_notification_configure_surface(struct
ivi_layout_surface *ivisurf,
*/
surface = ivi_layout_interface->surface_get_weston_surface(ivisurf);
if (surface) {
+ /* XXX: needs to handle zero size by unmapping the surface */
+
ivi_layout_interface->surface_set_source_rectangle(
ivisurf, 0, 0, surface->width,
surface->height);
diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index c502c74..fe86c27 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -118,9 +118,6 @@ ivi_shell_surface_configure(struct weston_surface *surface,
if (!ivisurf)
return;
- if (surface->width == 0 || surface->height == 0)
- return;
-
if (ivisurf->width != surface->width ||
ivisurf->height != surface->height) {
ivisurf->width = surface->width;
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v5] text: Create second version of text input protocol
This look much more promising from input method point of view comparing with previous version. I tried to implement inputmethod protocol v1 for wayland in fcitx quite some time ago, but I never put it in real use because.. it's not really practical comparing with what we have in customized im module. Personally I liked be able to limit the amount of surrounding text .. I had to implement that manually in im module before to avoid unnecessarily sending large amount of string. One thing that I dislike in input-method v1 is that input method context is destroyed after it lost focus, tbus it's not possible track a window(surface) and remember some specific state (e.g. using different engine for different surface), is that planned to be improved in the future? See my other comments below. On Monday, 14 March 2016 12:58:27 PDT Jan Arne Petersen wrote: > + > + > + Notify when text should be inserted into the editor widget. The text to > + commit could be either just a single character after a key press or the > + result of some composing (pre-edit). It could be also an empty text > + when some text should be removed (see delete_surrounding_text) or when > + the input cursor should be moved (see cursor_position). > + > + Any previously set composing text should be removed. > + > + + > + > + > + > + > + > + Notify when the text around the current cursor position should be > + deleted. > + > + Index is relative to the current cursor (in bytes). > + Length is the length of deleted text (in bytes). > + > + This event should be handled as part of a following commit_string > + or preedit_string event. > + > + > + > + > + From my experience of developing a Qt immodule, Qt's surrounding text is actually causing some trouble to me recently because deleteSurroundingText is actually behave differently in Qt and Gtk. So I hope this update to protocol description should cover this part. 1. will preedit string be counted in surrounding text? I assume no, because no toolkit currently did this and it would be headache for input method engine author if so. 2. what happens to selected text if delete surrounding text happens? This is never clear and behavior is currently different in different toolkits. I hope we can have answer of following questions covered in this protocol, I'll also give my suggestion to this answer below. - what will happen to currently selected string after commit string * I expect currently selected string being replaced - what will happen to currently selected string after deleting surrounding text * do nothing to currently selected string - where is the cursor after committing string * cursor advance to the send to committed string - where is the cursor after deleting surrounding text . * keep the cursor/anchor as it is if cursor/anchor is outside of the deleted text * if cursor/anchor is covered by deleted range, move it to the edge of deleted range, for example suppose we have string: ABCDE, cursor is 1, anchor is 4. If deleting surrounding text with (-1, 2), we have CDE, cursor is 0, anchor is 2. If with (1, 1), text is ABDE, cursor is 1, anchor is 3. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: [PATCH weston 0/8] IVI Screen refactoring
Hello Pekka-san, Emre-san, It is fine with me as well. This refactoring removes duplicated logic in ivi-layout and results in lower maintenance effort. Acked-by: Wataru Natsume Best Regards, Wataru Natsume --- Wataru Natsume / 夏目 亘 Advanced Driver Information Technology Software Group (ADITJ/SWG) E-mail: wnats...@jp.adit-jv.com Tel: +81-(0)566-61-4551 / Extension 551-43644 -Original Message- From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On Behalf Of Pekka Paalanen Sent: Friday, March 18, 2016 8:25 PM To: Ucan, Emre (ADITG/SW1); wataru_natsume Cc: Friedrich, Eugen (ADITG/SW1); wayland-devel@lists.freedesktop.org Subject: Re: [PATCH weston 0/8] IVI Screen refactoring On Thu, 17 Mar 2016 15:30:22 + "Ucan, Emre (ADITG/SW1)" wrote: > Basic idea of the patch series is to use weston_output in public APIs. > The controller plugins will call IVI Layout API with weston output > instead of ivi_layout_screen. This change simplifies the IVI Layout > API implementation, e.g.: > > 1. Don't need to have id_screen. Weston output already has ID. > 2. The screen resolution can be get from weston output directly. > 3. Get screns API is unnecessary, because the compositor already has a >list of outputs. > > Emre Ucan (8): > ivi-shell: remove id_screen > ivi-shell: remove ivi_layout_get_id_of_screen API > ivi-shell: remove ivi_layout_get_screen_resolution API > ivi-shell: remove ivi_layout_get_screens API > ivi-shell: use weston_output in public APIs > ivi-shell: implement get_screen_from_output > ivi-shell: remove ivi_layout_get_screen_from_id API > ivi-shell: remove ivi_layout_get_screen_output API > > ivi-shell/hmi-controller.c | 99 +++ > ivi-shell/ivi-layout-export.h| 62 +++-- > ivi-shell/ivi-layout.c | 136 > ++ > tests/ivi_layout-internal-test.c | 125 > +-- > 4 files changed, 82 insertions(+), 340 deletions(-) > Hi Emre, I see this as an offical step towards removing the mid-layer called ivi-layout, and leaving it as a helper interface to realize the surface(/view)/layer/screen hierarchy. So the direction is for controllers to use more Weston core API rather than ivi-layout to eventually wrap all of Weston core API. Am I correct? Can I get an Acked-by from someone else (Natsume-san?) that it is ok to move the ivi-layout architecture in this direction? Personally I am happy to see things going in this direction. Some details: - Weston will aggressively re-use output ids, and does not guarantee any persistent mapping between an output (connector) and an id. Is this ok, or would you need more reliable screen ids? - For get_screen_resolution, I would prefer a function for controllers to call to get it. That would be the perfect place to document what "screen resolution" actually means, because we have things like output scale and output transform, which ivi-layout has so far just assumed being identity. These parameters make the difference between the coordinate systems the shell uses to lay out surfaces, and the coordinate system on the monitor device. It would be ok to make this a Weston core function, provided it is accurately documented. Note, that output scale and transform are not controlled by the shell (at least yet). Other than that, all the patches look good to me. I'll just wait for someone else to Ack this plan before trying to land this series. Thanks, pq ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[libinput] How I get to scroll.wheel_click_angle value using libinput?
Hello, guys. When I check mouse wheel events using libinput, I found that this wheel value was always converted by libinput. Like this: wheel_degrees.y = -1 * e->value * device- >scroll.wheel_click_angle. In function evdev_process_relative(). That value is set using udev property named "MOUSE_WHEEL_CLICK_ANGLE". But if that value is not exist, set default value(DEFAULT_WHEEL_CLICK_ANGLE). In that case, I move wheel to just one, kernel send wheel event that value is 1, and libinput changed it to 15(this is currently default value). This is my concerned point. I just want to know mouse wheel's real move, not converted value. So I found how to get that value(scroll.wheel_click_angle) for revert value to 1(like via kernel) But currently libinput_device_config_scroll_* API's doesn't support this. How can I get this value? Or how about make a new API like libinput_device_config_scroll_get_wheel_click_angle()? If you this make sense, I will upload a commit to add a new API. Please give me your opinions. Thanks and regards, JengHyun Kang. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
