Re: [RFC] Interface for injection of input events
On Wed, Mar 22, 2017 at 1:24 PM Peter Hutterer wrote: > Hi all, > > This is an RFC for a new interface to generate input events from arbitrary > clients. Note that this is only a few days old, so **do not** assume this > is > anything more a thought experiment right now. This email is supposed to > start a > discussion and collection of the various points that need to be addressed. > > First: why? There are some commandline tools like xdotool that allow for > some > scripting of desktop interactions. xdotool supports two categories: input > device emulation and window management. > > This RFC primarily addresses the input device emulation bits but there is > room for adding window management capabilities. I have a basic repo here: > http://github.com/whot/woodotool but it doesn't contain much beyond what's > in this email. > > This will be a discussion of the interface only because the implementations > are so specific that there is no real code-sharing beyond the interface > itself. I've talked privately to some of you already, the general mood is > somewhere around reluctant acceptance. > > So here's a list of talking points: > > == DBus == > What we need is basic IPC and not directly Wayland related, DBus provides a > bunch of extras over the wayland protocol: introspection, ease of > extensibility, bindings, etc. Also, Mir. > > == Functionality-based interfaces == > We need a mix of capabilities and features, not all of which will/should be > available to all clients. Right now, I have two for devices: > org.freedesktop.WoodoTool.Keyboard (Press, Release) > org.freedesktop.WoodoTool.Mouse (Press, Release, MoveRelative, > MoveAbsolute) > Compositors can implement one, both, either, etc. For future extensions, > having a Touch interface, Joystick, or whatever is deemed useful is > technically trivial. > > There's a manager interface too but that's a technical detail, see the repo > for more details. > > == Control of the event stream == > The events are coming in through a custom interface, so it's relatively > trivial to ignore events based on context, e.g. ignore fake key events > while > the screen is locked. Any uinput-based solution would lack this context. > > == Authentication/Identification == > The goal is to filter clients based on some white/blacklist, so that e.g. > xdotool can access this interface but others cannot. > > This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this reliably. > It's trivial to do per user, but per-process is difficult. DBus filters > are largely limited to per-users. It's possible to get the process ID of a > sender but going beyond that is unreliable (kernel doesn't guarantee comm > being accurate). > For Ubuntu, at least, we use the apparmor dbus integration to filter dbus on a pretty granular level. If push came to shove it would presumably be reasonably easy to add an selinux query in the same path to do the same. *waves hands* … > > == Use for testing == > Came up several times, I'm not yet convinced this is a good compositor > testing > interface beyond basic input. A good testing interface likely requires > something more compositor-specific where more of the window state is made > available. But it could work as an interim solution. > > Toolkits seem to have pretty usable introspection capabilities - for example, there are lots of automated tests of the Ubuntu Touch devices that use Qt hooks to verify lots of behaviours and need only a way to generate input events and lookup screen coordinates from client coordinates. It'll be less useful for testing the compositor itself, though (unless you happen to have written the compositor in an introspectable toolkit). > == Input coordinate handling == > Keys and mouse buttons are trivial unless we want custom focus (we don't). > Relative coordinates are ok too, absolute ones are trickier because they > rely on screen layout not available to the client. > > So the specification needs to include a behaviour we can stick to forever, > something like "in pixels as measured from the logical top-left of the > top-left-most screen" etc. Not difficult per se, but this stuff is usually > prone to corner-case unhappiness. > > == Input coordinate filtering == > One use-case that was mentioned to me was effectively "intercept button X > and send key events 'abc' instead". This is not possible with the current > proposal and I'm not sure it can be without going overboard with > specifications. It *may* be possible to provide some global hotkey hooks I > have not come up with a good solution to that. > > == Window management == > This is beyond the current suggestion but also where it gets both > interesting and difficult. > > I have a sample org.freedesktop.WoodoTool.Desktop interface that would send > Edge signals to clients. The compositor decides when these are triggered, > the client can react to these things with custom commmands. > > But this is where we get into the proper scripting territory and that's > als
Re: [PATCH libinput] touchpad: add pressure ranges for cyapa touchpads
On Tue, Mar 21, 2017 at 10:32:03AM +1000, Peter Hutterer wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=100122
>
> Signed-off-by: Peter Hutterer
> ---
> src/evdev-mt-touchpad.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
> index e2866df..924e4f0 100644
> --- a/src/evdev-mt-touchpad.c
> +++ b/src/evdev-mt-touchpad.c
> @@ -2385,6 +2385,9 @@ tp_init_pressure(struct tp_dispatch *tp,
> if (device->model_flags & EVDEV_MODEL_ELANTECH_TOUCHPAD) {
> tp->pressure.high = 24;
> tp->pressure.low = 10;
> + } else if (device->model_flags & EVDEV_MODEL_CYAPA) {
> + tp->pressure.high = 8;
> + tp->pressure.low = 6;
updated locally to 10/8 at the tester's request
Cheers,
Peter
> } else {
> /* Approximately the synaptics defaults */
> tp->pressure.high = abs->minimum + 0.12 * range;
> --
> 2.9.3
>
> ___
> 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: [RFC] Interface for injection of input events
On Wed, Mar 22, 2017 at 12:23:46PM +1000, Peter Hutterer wrote: > Hi all, > > This is an RFC for a new interface to generate input events from arbitrary > clients. Note that this is only a few days old, so **do not** assume this is > anything more a thought experiment right now. This email is supposed to start > a > discussion and collection of the various points that need to be addressed. > > First: why? There are some commandline tools like xdotool that allow for some > scripting of desktop interactions. xdotool supports two categories: input > device emulation and window management. > > This RFC primarily addresses the input device emulation bits but there is > room for adding window management capabilities. I have a basic repo here: > http://github.com/whot/woodotool but it doesn't contain much beyond what's > in this email. > > This will be a discussion of the interface only because the implementations > are so specific that there is no real code-sharing beyond the interface > itself. I've talked privately to some of you already, the general mood is > somewhere around reluctant acceptance. > > So here's a list of talking points: > > == DBus == > What we need is basic IPC and not directly Wayland related, DBus provides a > bunch of extras over the wayland protocol: introspection, ease of > extensibility, bindings, etc. Also, Mir. > > == Functionality-based interfaces == > We need a mix of capabilities and features, not all of which will/should be > available to all clients. Right now, I have two for devices: > org.freedesktop.WoodoTool.Keyboard (Press, Release) > org.freedesktop.WoodoTool.Mouse (Press, Release, MoveRelative, MoveAbsolute) > Compositors can implement one, both, either, etc. For future extensions, > having a Touch interface, Joystick, or whatever is deemed useful is > technically trivial. I wouldn't say Joystick, at the current state, is trivial at all, as it'd require a compositor to have a setuid uinput process doing this. There hasn't been a consensus on whether to add a joystick/gamepad protocol or introduce a lower (evdev) level protocol to Wayland, and AFAIK reading the evdev node directly is how it's done on X11. > > There's a manager interface too but that's a technical detail, see the repo > for more details. > > == Control of the event stream == > The events are coming in through a custom interface, so it's relatively > trivial to ignore events based on context, e.g. ignore fake key events while > the screen is locked. Any uinput-based solution would lack this context. > > == Authentication/Identification == > The goal is to filter clients based on some white/blacklist, so that e.g. > xdotool can access this interface but others cannot. > > This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this reliably. > It's trivial to do per user, but per-process is difficult. DBus filters > are largely limited to per-users. It's possible to get the process ID of a > sender but going beyond that is unreliable (kernel doesn't guarantee comm > being accurate). > > Requiring applications to bind to a bus name merely restricts them to being > a singleton, there is no guarantee the application that binds > org.freedesktop.org.WoodoTool.auth.xdotool is actually xdotool. > > The option that comes closest so far is some pre-shared key between > compositor and application. That would need to be worked into the API, but > it also relies on all participants to keep the key encrypted in memory and > the various configuration files. > > So it's not clear whether we can do anything beyond a basic on/off toggle on > whether to allow events from fake input devices. Debatable if such a crude > mechanism is useful. > > > Either way, this is a problem that *must* be solved but not necessarily one > that affects the API itself (beyond what is required to make it > technically feasable, e.g. passing cookies around) This could be left up to flatpak et.al, couldn't it? Coming up with a authentication mechanism that likely can be worked around without proper sandboxing doesn't sound relaible. CC:ing Alex regarding this. > > == Isolation of devices == > Compositors should create separate virtual input devices for each client so > one client can't mess with the state of another one or even detect if > there's another one active. Plus we get to re-use all the existing code that > merge state from different (physical) devices. This just makes the actual > device handling implementation trivial. > > It gets a bit more difficult if we want to have this per-seat though. Seat > is a wayland concept so we could fold that in, but then you're leaking the > seat configuration. So I'm not 100% sure we even want this, or whether we > should just make sure it can be retrofitted in the future. One option, that I think has been experimented with in terms of remote desktoping, is to create new seats. I.e. a scripting client can create its own seat, and create devices on that. This could be added to th
[RFC] Interface for injection of input events
Hi all, This is an RFC for a new interface to generate input events from arbitrary clients. Note that this is only a few days old, so **do not** assume this is anything more a thought experiment right now. This email is supposed to start a discussion and collection of the various points that need to be addressed. First: why? There are some commandline tools like xdotool that allow for some scripting of desktop interactions. xdotool supports two categories: input device emulation and window management. This RFC primarily addresses the input device emulation bits but there is room for adding window management capabilities. I have a basic repo here: http://github.com/whot/woodotool but it doesn't contain much beyond what's in this email. This will be a discussion of the interface only because the implementations are so specific that there is no real code-sharing beyond the interface itself. I've talked privately to some of you already, the general mood is somewhere around reluctant acceptance. So here's a list of talking points: == DBus == What we need is basic IPC and not directly Wayland related, DBus provides a bunch of extras over the wayland protocol: introspection, ease of extensibility, bindings, etc. Also, Mir. == Functionality-based interfaces == We need a mix of capabilities and features, not all of which will/should be available to all clients. Right now, I have two for devices: org.freedesktop.WoodoTool.Keyboard (Press, Release) org.freedesktop.WoodoTool.Mouse (Press, Release, MoveRelative, MoveAbsolute) Compositors can implement one, both, either, etc. For future extensions, having a Touch interface, Joystick, or whatever is deemed useful is technically trivial. There's a manager interface too but that's a technical detail, see the repo for more details. == Control of the event stream == The events are coming in through a custom interface, so it's relatively trivial to ignore events based on context, e.g. ignore fake key events while the screen is locked. Any uinput-based solution would lack this context. == Authentication/Identification == The goal is to filter clients based on some white/blacklist, so that e.g. xdotool can access this interface but others cannot. This is a big ¯\_(ツ)_/¯ for now, I don't now how to do this reliably. It's trivial to do per user, but per-process is difficult. DBus filters are largely limited to per-users. It's possible to get the process ID of a sender but going beyond that is unreliable (kernel doesn't guarantee comm being accurate). Requiring applications to bind to a bus name merely restricts them to being a singleton, there is no guarantee the application that binds org.freedesktop.org.WoodoTool.auth.xdotool is actually xdotool. The option that comes closest so far is some pre-shared key between compositor and application. That would need to be worked into the API, but it also relies on all participants to keep the key encrypted in memory and the various configuration files. So it's not clear whether we can do anything beyond a basic on/off toggle on whether to allow events from fake input devices. Debatable if such a crude mechanism is useful. Either way, this is a problem that *must* be solved but not necessarily one that affects the API itself (beyond what is required to make it technically feasable, e.g. passing cookies around) == Isolation of devices == Compositors should create separate virtual input devices for each client so one client can't mess with the state of another one or even detect if there's another one active. Plus we get to re-use all the existing code that merge state from different (physical) devices. This just makes the actual device handling implementation trivial. It gets a bit more difficult if we want to have this per-seat though. Seat is a wayland concept so we could fold that in, but then you're leaking the seat configuration. So I'm not 100% sure we even want this, or whether we should just make sure it can be retrofitted in the future. == Use for testing == Came up several times, I'm not yet convinced this is a good compositor testing interface beyond basic input. A good testing interface likely requires something more compositor-specific where more of the window state is made available. But it could work as an interim solution. == Input coordinate handling == Keys and mouse buttons are trivial unless we want custom focus (we don't). Relative coordinates are ok too, absolute ones are trickier because they rely on screen layout not available to the client. So the specification needs to include a behaviour we can stick to forever, something like "in pixels as measured from the logical top-left of the top-left-most screen" etc. Not difficult per se, but this stuff is usually prone to corner-case unhappiness. == Input coordinate filtering == One use-case that was mentioned to me was effectively "intercept button X and send key events 'abc' instead". This is not possible with the current proposal and I'm not su
Re: [PATCH 1/2] wayland-web: Update documentation for EFL toolkit web page
On 21/03/17 09:29 AM, Chris Michael wrote: This patch updates the documentation for building EFL with wayland support on the wayland web site. Signed-off-by: Chris Michael --- efl.html | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/efl.html b/efl.html index 024109a..5b179df 100644 --- a/efl.html +++ b/efl.html @@ -32,7 +32,6 @@ $ git clone git://git.enlightenment.org/core/efl.git - $ git clone git://git.enlightenment.org/core/elementary.git Ok, those build instructions were savagely out of date. Thanks for fixing this up. both are: Reviewed-by: Derek Foreman I was going to complain about the file size of the screenshot, but it seems there are a few screenshots already in the repo designed to dazzle us with a flashy background image. I wouldn't mind seeing those compressed more or replaced with shots that get their point across in a less bandwidth intensive way, but I can't cry foul on this screenshot if the others are just as bad. :) Thanks, Derek Compiling EFL @@ -51,13 +50,6 @@ $ make install - elementary - - $ ./autogen.sh --prefix=$WLD - $ make - $ make install - - With all these components it is important to read the output given by configure to ensure the requested options were enabled. You may need to look in config.log to identify missing @@ -71,13 +63,15 @@ or use EGL. For applications that use Elementary set the environment variable - ELM_ENGINE to wayland_egl or - wayland_shm as above. + ELM_DISPLAY to wl. You may also set the + environment variable ELM_ACCEL to none + to use software rendering, or to gl to use hardware + accelerated rendering. Getting help and reporting issues Issues in the Wayland port of EFL can be reported in the Enlightenment https://phab.enlightenment.org/maniphest/";>bug -tracker.There is also the #wayland-efl IRC channel on irc.freenode.net +tracker.There is also the #edevelop IRC channel on irc.freenode.net ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] configure.ac: use AC_HEADER_MAJOR to detect major()/minor()
Before the change build failed on Gentoo as:
libweston/weston_launch-weston-launch.o: In function `handle_open':
weston/libweston/weston-launch.c:363: undefined reference to `major'
weston/libweston/weston-launch.c:365: undefined reference to `major'
weston/libweston/weston-launch.c:325: undefined reference to `major'
weston/libweston/weston-launch.c:326: undefined reference to `major'
libweston/weston_launch-weston-launch.o: In function `setup_tty':
weston/libweston/weston-launch.c:548: undefined reference to `major'
weston/libweston/weston-launch.c:548: undefined reference to `minor'
weston/libweston/weston-launch.c:555: undefined reference to `major'
weston/libweston/weston-launch.c:558: undefined reference to `minor'
libweston/weston_launch-weston-launch.o: In function `close_input_fds':
weston/libweston/weston-launch.c:451: undefined reference to `major'
glibc plans to remove from glibc's :
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html
Gentoo already applied glibc patch to experimental glibc-2.24
to start preparingfor the change.
Autoconf has AC_HEADER_MAJOR to find out which header defines
reqiured macros:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Particular-Headers.html
This change should also increase portability across other libcs.
Bug: https://bugs.gentoo.org/610652
Signed-off-by: Sergei Trofimovich
---
configure.ac | 1 +
libweston/launcher-direct.c| 8
libweston/launcher-logind.c| 8
libweston/launcher-weston-launch.c | 7 +++
libweston/weston-launch.c | 8
5 files changed, 32 insertions(+)
diff --git a/configure.ac b/configure.ac
index 9df85d20..b99e7fdd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -34,6 +34,7 @@ AC_CONFIG_MACRO_DIR([m4])
AC_USE_SYSTEM_EXTENSIONS
AC_SYS_LARGEFILE
+AC_HEADER_MAJOR
AM_INIT_AUTOMAKE([1.11 parallel-tests foreign no-dist-gzip dist-xz color-tests
subdir-objects])
diff --git a/libweston/launcher-direct.c b/libweston/launcher-direct.c
index 4195cf65..16bac5f4 100644
--- a/libweston/launcher-direct.c
+++ b/libweston/launcher-direct.c
@@ -46,6 +46,14 @@
#define KDSKBMUTE 0x4B51
#endif
+/* major()/minor() */
+#ifdef MAJOR_IN_MKDEV
+#include
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include
+#endif
+
#ifdef HAVE_LIBDRM
#include
diff --git a/libweston/launcher-logind.c b/libweston/launcher-logind.c
index 8de1ed11..663cff28 100644
--- a/libweston/launcher-logind.c
+++ b/libweston/launcher-logind.c
@@ -44,6 +44,14 @@
#define DRM_MAJOR 226
+/* major()/minor() */
+#ifdef MAJOR_IN_MKDEV
+#include
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include
+#endif
+
struct launcher_logind {
struct weston_launcher base;
struct weston_compositor *compositor;
diff --git a/libweston/launcher-weston-launch.c
b/libweston/launcher-weston-launch.c
index 930f4e0c..3f7dde50 100644
--- a/libweston/launcher-weston-launch.c
+++ b/libweston/launcher-weston-launch.c
@@ -74,6 +74,13 @@ drmSetMaster(int drm_fd)
#endif
+/* major()/minor() */
+#ifdef MAJOR_IN_MKDEV
+#include
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include
+#endif
union cmsg_data { unsigned char b[4]; int fd; };
diff --git a/libweston/weston-launch.c b/libweston/weston-launch.c
index 140fde1d..5fe0c4a9 100644
--- a/libweston/weston-launch.c
+++ b/libweston/weston-launch.c
@@ -92,6 +92,14 @@ drmSetMaster(int drm_fd)
#endif
+/* major()/minor() */
+#ifdef MAJOR_IN_MKDEV
+#include
+#endif
+#ifdef MAJOR_IN_SYSMACROS
+#include
+#endif
+
struct weston_launch {
struct pam_conv pc;
pam_handle_t *ph;
--
2.12.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland v2 2/4] wayland-util: split out private functionality to separate file
Hi Emil,
> On Feb 21, 2017, at 8:14 AM, Emil Velikov wrote:
>
> From: Emil Velikov
>
> With next commit we'll make wayland-util a shared library (for reasons
> mentioned in the commit). As such we need to make sure that the private
> symbols are somewhere that they can be used internally. Otherwise we'll
> end up with link errors.
>
> v2: Rebase.
>
> Signed-off-by: Emil Velikov
While others will have to chime in about the separate .so and approve
patches 2 - 4, the remainder of this series is
Reviewed-by: Yong Bakos
Tested-by: Yong Bakos
Regards,
yong
> ---
> Makefile.am| 1 +
> src/wayland-util-private.c | 303 +
> src/wayland-util.c | 272 +---
> 3 files changed, 305 insertions(+), 271 deletions(-)
> create mode 100644 src/wayland-util-private.c
>
> diff --git a/Makefile.am b/Makefile.am
> index d0c8bd3..7e15465 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -56,6 +56,7 @@ libwayland_private_la_SOURCES = \
> src/connection.c\
> src/wayland-os.c\
> src/wayland-os.h\
> + src/wayland-util-private.c \
> src/wayland-private.h
>
> include_HEADERS = \
> diff --git a/src/wayland-util-private.c b/src/wayland-util-private.c
> new file mode 100644
> index 000..9861170
> --- /dev/null
> +++ b/src/wayland-util-private.c
> @@ -0,0 +1,303 @@
> +/*
> + * Copyright © 2008-2011 Kristian Høgsberg
> + * Copyright © 2011 Intel 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "wayland-private.h"
> +
> +/** \cond */
> +
> +struct wl_object global_zombie_object;
> +
> +int
> +wl_interface_equal(const struct wl_interface *a, const struct wl_interface
> *b)
> +{
> + /* In most cases the pointer equality test is sufficient.
> + * However, in some cases, depending on how things are split
> + * across shared objects, we can end up with multiple
> + * instances of the interface metadata constants. So if the
> + * pointers match, the interfaces are equal, if they don't
> + * match we have to compare the interface names.
> + */
> + return a == b || strcmp(a->name, b->name) == 0;
> +}
> +
> +union map_entry {
> + uintptr_t next;
> + void *data;
> +};
> +
> +#define map_entry_is_free(entry) ((entry).next & 0x1)
> +#define map_entry_get_data(entry) ((void *)((entry).next & ~(uintptr_t)0x3))
> +#define map_entry_get_flags(entry) (((entry).next >> 1) & 0x1)
> +
> +void
> +wl_map_init(struct wl_map *map, uint32_t side)
> +{
> + memset(map, 0, sizeof *map);
> + map->side = side;
> +}
> +
> +void
> +wl_map_release(struct wl_map *map)
> +{
> + wl_array_release(&map->client_entries);
> + wl_array_release(&map->server_entries);
> +}
> +
> +uint32_t
> +wl_map_insert_new(struct wl_map *map, uint32_t flags, void *data)
> +{
> + union map_entry *start, *entry;
> + struct wl_array *entries;
> + uint32_t base;
> +
> + if (map->side == WL_MAP_CLIENT_SIDE) {
> + entries = &map->client_entries;
> + base = 0;
> + } else {
> + entries = &map->server_entries;
> + base = WL_SERVER_ID_START;
> + }
> +
> + if (map->free_list) {
> + start = entries->data;
> + entry = &start[map->free_list >> 1];
> + map->free_list = entry->next;
> + } else {
> + entry = wl_array_add(entries, sizeof *entry);
> + if (!entry)
> + return 0;
> + start = entries->data;
> + }
> +
> + entry->data = data;
> + entry->next |= (flags & 0x1) << 1;
> +
>
[PATCH 1/2] wayland-web: Update documentation for EFL toolkit web page
This patch updates the documentation for building EFL with wayland support on the wayland web site. Signed-off-by: Chris Michael --- efl.html | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/efl.html b/efl.html index 024109a..5b179df 100644 --- a/efl.html +++ b/efl.html @@ -32,7 +32,6 @@ $ git clone git://git.enlightenment.org/core/efl.git - $ git clone git://git.enlightenment.org/core/elementary.git Compiling EFL @@ -51,13 +50,6 @@ $ make install - elementary - - $ ./autogen.sh --prefix=$WLD - $ make - $ make install - - With all these components it is important to read the output given by configure to ensure the requested options were enabled. You may need to look in config.log to identify missing @@ -71,13 +63,15 @@ or use EGL. For applications that use Elementary set the environment variable - ELM_ENGINE to wayland_egl or - wayland_shm as above. + ELM_DISPLAY to wl. You may also set the + environment variable ELM_ACCEL to none + to use software rendering, or to gl to use hardware + accelerated rendering. Getting help and reporting issues Issues in the Wayland port of EFL can be reported in the Enlightenment https://phab.enlightenment.org/maniphest/";>bug -tracker.There is also the #wayland-efl IRC channel on irc.freenode.net +tracker.There is also the #edevelop IRC channel on irc.freenode.net -- 2.10.2 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC weston] libweston-desktop: Add size_requested API
From: Quentin Glidic
Some shells (wl_shell) does not let the compositor control the surface
state and instead force one. Therefore, they cannot call
{maximized,fullscreen}_requested as these imply the compositor can still
opt-out.
This new callback is called whenever a state change requests a new size,
be it triggered by the client or the compositor.
Signed-off-by: Quentin Glidic
---
This patch works correctly as-is, but is RFC because I have yet to add
some API to support output choice in wl_shell.
libweston-desktop/internal.h | 12 +++
libweston-desktop/libweston-desktop.c | 8 +
libweston-desktop/libweston-desktop.h | 11 ++
libweston-desktop/surface.c | 36
libweston-desktop/wl-shell.c | 14 +---
libweston-desktop/xdg-shell-v5.c | 64 +--
libweston-desktop/xdg-shell-v6.c | 64 +--
libweston-desktop/xwayland.c | 11 --
8 files changed, 194 insertions(+), 26 deletions(-)
diff --git a/libweston-desktop/internal.h b/libweston-desktop/internal.h
index 763355bf..38386916 100644
--- a/libweston-desktop/internal.h
+++ b/libweston-desktop/internal.h
@@ -80,6 +80,9 @@ weston_desktop_api_maximized_requested(struct weston_desktop
*desktop,
void
weston_desktop_api_minimized_requested(struct weston_desktop *desktop,
struct weston_desktop_surface *surface);
+void
+weston_desktop_api_size_requested(struct weston_desktop *desktop,
+ struct weston_desktop_surface *surface);
void
weston_desktop_api_set_xwayland_position(struct weston_desktop *desktop,
@@ -123,6 +126,15 @@ struct weston_desktop_surface_implementation {
(*get_min_size)(struct weston_desktop_surface *surface,
void *user_data);
+ bool (*get_pending_activated)(struct weston_desktop_surface *surface,
+ void *user_data);
+ bool (*get_pending_fullscreen)(struct weston_desktop_surface *surface,
+void *user_data);
+ bool (*get_pending_maximized)(struct weston_desktop_surface *surface,
+ void *user_data);
+ bool (*get_pending_resizing)(struct weston_desktop_surface *surface,
+ void *user_data);
+
void (*destroy)(struct weston_desktop_surface *surface,
void *user_data);
};
diff --git a/libweston-desktop/libweston-desktop.c
b/libweston-desktop/libweston-desktop.c
index 48e90009..a5ae5bd9 100644
--- a/libweston-desktop/libweston-desktop.c
+++ b/libweston-desktop/libweston-desktop.c
@@ -243,6 +243,14 @@ weston_desktop_api_minimized_requested(struct
weston_desktop *desktop,
desktop->api.minimized_requested(surface, desktop->user_data);
}
+void
+weston_desktop_api_size_requested(struct weston_desktop *desktop,
+ struct weston_desktop_surface *surface)
+{
+ if (desktop->api.size_requested != NULL)
+ desktop->api.size_requested(surface, desktop->user_data);
+}
+
void
weston_desktop_api_set_xwayland_position(struct weston_desktop *desktop,
struct weston_desktop_surface *surface,
diff --git a/libweston-desktop/libweston-desktop.h
b/libweston-desktop/libweston-desktop.h
index 03b04c7b..8da10a49 100644
--- a/libweston-desktop/libweston-desktop.h
+++ b/libweston-desktop/libweston-desktop.h
@@ -80,6 +80,8 @@ struct weston_desktop_api {
bool maximized, void *user_data);
void (*minimized_requested)(struct weston_desktop_surface *surface,
void *user_data);
+ void (*size_requested)(struct weston_desktop_surface *surface,
+ void *user_data);
/** Position suggestion for an Xwayland window
*
@@ -192,6 +194,15 @@ weston_desktop_surface_get_max_size(struct
weston_desktop_surface *surface);
struct weston_size
weston_desktop_surface_get_min_size(struct weston_desktop_surface *surface);
+bool
+weston_desktop_surface_get_pending_activated(struct weston_desktop_surface
*surface);
+bool
+weston_desktop_surface_get_pending_maximized(struct weston_desktop_surface
*surface);
+bool
+weston_desktop_surface_get_pending_fullscreen(struct weston_desktop_surface
*surface);
+bool
+weston_desktop_surface_get_pending_resizing(struct weston_desktop_surface
*surface);
+
#ifdef __cplusplus
}
#endif
diff --git a/libweston-desktop/surface.c b/libweston-desktop/surface.c
index d3be9364..50aa4f46 100644
--- a/libweston-desktop/surface.c
+++ b/libweston-desktop/surface.c
@@ -675,6 +675,42 @@ weston_desktop_surface_get_min_size(struct
weston_desktop_surface *surface)
surface->implementation_data);
}
+WL_EXPORT bool
+weston_des
Re: [PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library
On Mon, 20 Mar 2017 18:21:53 +
Emil Velikov wrote:
> On 17 March 2017 at 13:32, Pekka Paalanen wrote:
> > On Fri, 17 Mar 2017 12:07:45 +
> > Emil Velikov wrote:
> >
> >> On 17 March 2017 at 11:10, Pekka Paalanen wrote:
> >> > On Thu, 16 Mar 2017 15:32:46 +
> >> > Emil Velikov wrote:
> >> >
> >> >> On 16 March 2017 at 12:40, Pekka Paalanen wrote:
> >
> >> >> > Hi,
> >> >> >
> >> >> > since I have so much trouble making my mind on this patch, how about a
> >> >> > silly counter-proposal?
> >> >> >
> >> >> > Let's squash libwayland-server.so and libwayland-client.so into a
> >> >> > single libwayland.so.
> >> >> >
> >> >> > That would take care of the duplicate exported symbols issue not just
> >> >> > for the util functions, but also for the exported variables produced
> >> >> > by
> >> >> > wayland-scanner. Since we have many programs (libEGL!) that
> >> >> > necessarily
> >> >> > already link to both, there cannot be problems from linking to
> >> >> > everything always.
> >> >> >
> >> >> > We would still need to install dummy libwayland-server.so and
> >> >> > libwayland-client.so just for pulling in libwayland.so, but that's no
> >> >> > worse than Emil's proposition.
> >> >> >
> >> >> > Whether we have the existing .pc files telling to link to
> >> >> > server/client
> >> >> > or just libwayland.so would be up for debate. I'm not suggesting to
> >> >> > merge the .pc files.
> >> >> >
> >> >> > libwayland-server.so and libwayland-client.so have exactly the same
> >> >> > set
> >> >> > of dependencies.
> >> >> >
> >> >> > Any downsides to this approach vs. doing nothing vs. Emil's
> >> >> > libwayland-{client,server,util}.so?
> >
> >> How exactly do you see libwayland.so relative to the client/server one
> >> - which provides what symbols, etc.
> >> - are the client/server DSOs - symlinks/other ?
> >
> > This is how I imagined it:
> >
> > - libwayland.so contains all the code, and exports both server and
> > client symbols.
> >
> > - libwayland-server.so and libwayland-client.so are normal DSOs that
> > export essentially no symbols, they only depend on libwayland.so and
> > cause it to be loaded.
> >
> > In other words, you proposed to move util functions into a third
> > library. I proposed to move everything into a third library.
> >
> I'm yet to see/hear of such a DSO, and I'd imagine it will be rather
> confusing/misleading.
>
> >
> > One thing now coming to my mind is this. With your
> > https://github.com/evelikov/wl_link_test experiments, did you try the
> > following?
> > 1. build and install old wayland
> > 2. build link test
> > 3. build and install your patched wayland
> > 4. run link test (do not rebuild)
> >
> > The point here is that the application executable nor library does not
> > have libwayland-util.so as NEEDED themselves. Still, they need to
> > continue working fine.
> >
> Dan pointed out the same concert - bumping the -version-info will handle that.
No, that was a different case. Daniel was worried about downgrading
libwayland*.so, I am asking about updating libwayland*.so without
rebuilding users.
How would bumping -version-info handle it?
One updates libwayland*.so, gets a new version-info, while old programs
were expecting the old ones. I can see only two possible outcomes:
a) either version-info guarantees that the old programs no longer start
as the library of that version is not found, or
b) the version-info is still compatible, so nothing changes by bumping
it.
Regardless of that, the original question remains: the user binary (e.g.
wl_link_test) will not have libwayland-util.so as NEEDED - does it
still work?
I've been running with the assumption that it still does work, and your
commit message seemed to imply that too, hence I started wondering why
you want to add libwayland-util.so as NEEDED in newly built binaries?
Is it necessary, which would mean that all programs would need to be
rebuilt, or is it not necessary, in which case it would only serve to
break newly built programs in the case Daniel pointed out?
> > Then there is the case of dlopen()'ing these libraries. I think there
> > might be something unexpected to expect because we have this:
> > https://cgit.freedesktop.org/wayland/weston/tree/libweston/compositor-drm.c?id=2.0.0#n1575
> > introduced in commit 97f2952b.
> >
> This one works perfectly fine with or w/o a version-info change - try
> the wl-dl-test.
>
> > Does that mean that if someone writes a plugin for his app, and that
> > plugin uses wl_list, your patch would require them to at least rebuild
> > the plugin?
> >
> There's no requirement to rebuild anything. If we're concerned about
> using FOO build against wayland X+1, while running on wayland X -
> version-info will make that an explicit error, as it should be.
> Similar thing has been done already twice, afaict.
>
> If that's not a concern one need not bother changing version-info.
Ok, so it's just to ensure the user gets a runtime
Re: [PATCH wayland v2 3/4] wayland-util: build/ship as separate shared library
On Mon, 20 Mar 2017 17:55:25 + Emil Velikov wrote: > On 17 March 2017 at 13:24, Daniel Stone wrote: > > Hi, > > > > If you want to avoid sinking too much time into this, I suggest you > > work on polishing the rationale first. > > > Agreed, I could and should sell it out better. > > There's a thing that I've been wondering - have you/Pekka/others had > "fun" experience fixing up after symbol collisions ? I do not recall ever bumping into such, except for making wl_interface_equal() work which needs to handle "same interface, different address" even if we had no collisions anywhere with exported symbols (there can be "collisions" with private or local symbols being passed as function arguments). Thanks, pq pgpaYzEG0n_AT.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
