Re: It seems regular linux desktops can't run android apps even on Wayland?

[The Rasterman]

On Wed, 22 Mar 2017 01:19:55 -0300 Lúcio Boari  said:

> Hello I'm Lúcio. I'm not a programmer so maybe what I am discussing here is
> somehow erroneous. Today I was wondering why it's not possible to have
> Android apps running natively on a Linux desktop since Android runs atop
> the Linux Kernel and it is pretty much compatible with the x86
> architecture, and since Google has always open sourced their code. I made
> some research and found this page
> which
> explains basically a triple layered EGL context will always exist if you
> try to attach the Android's display server on Wayland, and very few drivers
> are capable of handling this.
> 
> Why does the same thing doesn't happen with Xwayland? Isn't it the same
> kind of problem? It is a pity things are this way because if Android apps
> were compatible with the standard linux system there would be a certain
> advantage in shipping a standard Linux distro on smartphones and tablets
> over the plain Android System to not talk about regular computers which
> would gain a huge amount of applications.
> 
> I hope you Wayland developers could make a way to attach Androrid
> applications on Wayland, but if there's really no good way to do this
> currently... If there is I'd like to know why there's apparently no one
> interested to make such a thing to happen...

Android is NOT an open OS. Not these days. Google very much push apps to RELY
on Google Play Services and "upgrade" from old Android API's. All development
of core Android API's (e.g. location API) stopped and all future additions
happen to Google Play Services which is proprietary, closed and specific to
Google.

Just because Android and "Desktop/Server Linux" (aka GNU/Linux - until Android
I never though I'd use this term) share the same kernel does not mean that are
anything alike further up the stack. They are vastly different with different
libc's and just about everything higher up being different.

So Android apps are NOT compatible with GNU/Linx. Android is a completely
different OS that just shares ONLY the kernel and nothing more worth talking
about. Because it is a foreign OS possibly even more so than iOS or OSX would
be (but less than Windows), no one really is going to chase this moving target
that ever becomes more and more closed over time.

Given that ... any EGL stack talk and Wayland is kind of moot. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

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

[ANNOUNCE] libinput 1.7.0

[Peter Hutterer]

libinput 1.7 is now available. Only one change that matters since the last
rc: cyapa touchpads now have a custom pressure ranage. The rest below is a
(slightly edited) copy of the rc1 announce email so you know what you get
updating from 1.6 to 1.7.

First big feature: James Ye implemented support for switches, in particular
lid switches. Closing the lid now disables the touchpad to avoid ghost
touches but it also makes the lid switch event itself available to any
callers. This is a new interface announced by the LIBINPUT_DEVICE_CAP_SWITCH
capability, see the documentation for more info:
https://wayland.freedesktop.org/libinput/doc/latest/group__event__switch.html

Touchpads now use pressure values to detect touches instead of relying on
BTN_TOUCH. This enables us to have per-device pressure values where needed
to avoid misdetection of light or hovering touches. For now most touchpads
use the default pressure vaules, if you have had issues with touch
misdetection please file a bug with the required pressure ranges. As usual,
this feature is device-dependent so not all touchpads will use pressure
values.

Wheel tilt events are now handled as such provided the device is correctly
labelled by the hwdb. A wheel tilt will not be advertised as scroll source
'wheel' but rather 'wheel tilt', making it possible to different between the
two in the caller.

Middle mouse button emulation is now compatible with scroll wheel emulation,
i.e. it is possible to set scroll wheel emulation on the right mouse button
and still enjoy middle button emulation. This is useful mostly on very old
mice and some trackballs.

On the topic of scroll wheel emulation: pressing the scroll button now
always generates a button event (provided now scrolling was triggered).
Previously this depended on an internal timeout which was hard to predict
for users. Of course, if any scrolling is triggered while the button is
down, no button events are sent.

Tablet pad LEDs now hook up correctly to the new kernel LED implementation
available in v4.9 and later. Pressing the respective mode button will thus
toggle pad modes in the events correctly.

Internal cleanup work touched most of libinput. And a gcov run exposed
some untested code paths and a lot of tests have been added for those.
External touchpad-keyboard combos can now be marked with a udev property to
ensure we enable disable-while-typing on the correct devices.

Finally, the libinput-debug-events tool now uses colours and hides keycodes
by default. It's now safe to run it in the background to record events
without having to worry that passwords end up in the log. If you do need the
keycodes, run with the --show-keycodes argument.

As usual, the git shortlog is below.

Peter Hutterer (7):
  test: don't use the same mouse twice
  test: fix tablet touch arbitration case
  test: add missing linebreak to error message
  tools: print axes, but not capabilities on proximity out
  touchpad: add pressure ranges for cyapa touchpads
  evdev: mark the new log functions as printf-style functions
  configure.ac: libinput 1.7.0

git tag: 1.7.0

https://www.freedesktop.org/software/libinput/libinput-1.7.0.tar.xz
MD5:  b6689bfacc1239082afd453216fc3d0e  libinput-1.7.0.tar.xz
SHA1: f4b7c5322937c46562163934b9988772ccd0e36d  libinput-1.7.0.tar.xz
SHA256: 12a670f63d01e9e9c98ad0b31aef22160aac52187b4ee8f068a6902181c1a8a8  
libinput-1.7.0.tar.xz
SHA512: 
9058eab813ea3de230835155ca843f248127cbafaf1aecc9a2e209a0215b090beef0468cc863a24320f8d0db1f2863baba680e2416e9e409e958b2c1d18e43a1
  libinput-1.7.0.tar.xz
PGP:  https://www.freedesktop.org/software/libinput/libinput-1.7.0.tar.xz.sig



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

Re: [PATCH weston 1/2] Add option to disable unconfigured outputs

[Quentin Glidic]

On 08/03/2017 16:43, Ucan, Emre (ADITG/SW1) wrote:

In current implementation, there is no configuration
to disable unconfigured outputs.

One can create an output section for a known output
in weston.ini file and set its mode to "off" to disable
a known output. But there is no configuration to disable
unknown outputs.

This might be usefull for example, if someone wants to
enable just one output and disable all others. Without
this option, we have to right down an output section for
every output known to system and disable all outputs,
which we do not want to enable.

It might be usefull also for startup time optimization,
because some display types (e.g. LVDS and VGA) are always
up. Therefore, weston would modeset every one of them.
Even there are no attached displays.

This introduces a simple configuration in weston.ini:
   [core]
   require-output-config=false

False is the default, so no behavioral change is introduced.

Signed-off-by: Emre Ucan 
---
  compositor/main.c  |8 +++-
  libweston/compositor.h |3 +++
  man/weston.ini.man |4 
  weston.ini.in  |1 +
  4 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/compositor/main.c b/compositor/main.c
index e870dd4..92f8741 100644
--- a/compositor/main.c
+++ b/compositor/main.c
@@ -1174,7 +1174,8 @@ drm_backend_output_configure(struct wl_listener 
*listener, void *data)
section = weston_config_get_section(wc, "output", "name", output->name);
weston_config_section_get_string(section, "mode", , "preferred");
  
-	if (strcmp(s, "off") == 0) {

+   if ((!section && output->compositor->require_output_config) ||
+   (strcmp(s, "off") == 0)) {
weston_output_disable(output);
free(s);
return;
@@ -1785,6 +1786,7 @@ int main(int argc, char *argv[])
struct weston_seat *seat;
struct wet_compositor user_data;
int require_input;
+   int require_output_config;
  
  	const struct weston_option core_options[] = {

{ WESTON_OPTION_STRING, "backend", 'B',  },
@@ -1874,6 +1876,10 @@ int main(int argc, char *argv[])
   _input, true);
ec->require_input = require_input;
  
+	weston_config_section_get_bool(section, "require-output-config",

+  _output_config, false);
+   ec->require_output_config = require_output_config;
+
if (load_backend(ec, backend, , argv, config) < 0) {
weston_log("fatal: failed to create compositor backend\n");
goto out;
diff --git a/libweston/compositor.h b/libweston/compositor.h
index 08e728a..a7abd35 100644
--- a/libweston/compositor.h
+++ b/libweston/compositor.h
@@ -891,6 +891,9 @@ struct weston_compositor {
/* Whether to let the compositor run without any input device. */
bool require_input;
  
+	/* Whether to disable unconfigured outputs */

+   bool require_output_config;
+


This is a setting used by Weston, in Weston code. If it were used in 
libweston, it would be the good place to put. Right now it’s not, and we 
don’t want it in libweston.

Put in in wet_compositor instead.

With that fixed:
Reviewed-by: Quentin Glidic 

Thanks,



  };
  
  struct weston_buffer {

diff --git a/man/weston.ini.man b/man/weston.ini.man
index 5ec0e1d..90e1c55 100644
--- a/man/weston.ini.man
+++ b/man/weston.ini.man
@@ -181,6 +181,10 @@ set to 300 seconds.
  .TP 7
  .BI "require-input=" true
  require an input device for launch
+.TP 7
+.BI "require-output-config=" false
+require an output section for every created output. If there is no section
+for an output, compositor disables the output.
  
  .SH "LIBINPUT SECTION"

  The
diff --git a/weston.ini.in b/weston.ini.in
index 257c4ec..fba893d 100644
--- a/weston.ini.in
+++ b/weston.ini.in
@@ -4,6 +4,7 @@
  #shell=desktop-shell.so
  #gbm-format=xrgb2101010
  #require-input=true
+#require-output-config=false
  
  [shell]

  background-image=/usr/share/backgrounds/gnome/Aqua.jpg




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Fix uninitialized msec_to_next in output_repaint_timer_arm

[Quentin Glidic]

On 18/03/2017 13:01, Sergi Granell wrote:

Signed-off-by: Sergi Granell 


Good:
Reviewed-by: Quentin Glidic 

And pushed:
65e57c93..b4c08863  master -> master

Thanks,


---
  libweston/compositor.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libweston/compositor.c b/libweston/compositor.c
index fb647daa..048b195c 100644
--- a/libweston/compositor.c
+++ b/libweston/compositor.c
@@ -2388,7 +2388,7 @@ output_repaint_timer_arm(struct weston_compositor 
*compositor)
struct weston_output *output;
bool any_should_repaint = false;
struct timespec now;
-   int64_t msec_to_next;
+   int64_t msec_to_next = INT64_MAX;
  
  	weston_compositor_read_presentation_clock(compositor, );
  




--

Quentin “Sardem FF7” Glidic
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] Introduce keyboard grabbing protocol for Xwayland

[Olivier Fourdan]

This patch introduces a new protocol for grabbing the keyboard from
Xwayland.

This is needed for X11 applications that map an override redirect window
(ths not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.

Signed-off-by: Olivier Fourdan 
---
 Makefile.am|   2 +
 configure.ac   |   2 +-
 unstable/xwayland-keyboard-grab/README |   4 +
 .../xwayland-keyboard-grab-unstable-v1.xml | 101 +
 4 files changed, 108 insertions(+), 1 deletion(-)
 create mode 100644 unstable/xwayland-keyboard-grab/README
 create mode 100644 
unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index e693afa..d100c13 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,8 @@ unstable_protocols =  
\
unstable/tablet/tablet-unstable-v2.xml  
\
unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
unstable/idle-inhibit/idle-inhibit-unstable-v1.xml  
\
+   unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
\
+   
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
$(NULL)
 
 stable_protocols = 
\
diff --git a/configure.ac b/configure.ac
index fbb0ec2..e98bceb 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,7 +1,7 @@
 AC_PREREQ([2.64])
 
 m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [7])
+m4_define([wayland_protocols_minor_version], [8])
 m4_define([wayland_protocols_version],
   [wayland_protocols_major_version.wayland_protocols_minor_version])
 
diff --git a/unstable/xwayland-keyboard-grab/README 
b/unstable/xwayland-keyboard-grab/README
new file mode 100644
index 000..dbe45a5
--- /dev/null
+++ b/unstable/xwayland-keyboard-grab/README
@@ -0,0 +1,4 @@
+Xwayland keyboard grabbing protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git 
a/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml 
b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
new file mode 100644
index 000..31dc365
--- /dev/null
+++ b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
@@ -0,0 +1,101 @@
+
+
+
+  
+   Copyright ?? 2017 Red Hat Inc.
+
+   Permission is hereby granted, free of charge, to any person obtaining a
+   copy of this software and associated documentation files (the 
"Software"),
+   to deal in the Software without restriction, 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.
+  
+
+  
+   This protocol specifies a way for Xwayland to request all keyboard
+   events to be forwarded to a surface even when the surface does not
+   have keyboard focus.
+
+   Unlike the X11 protocol, Wayland doesn't have the notion of
+   active grab on the keyboard.
+
+   When an X11 client acquires an active grab on the keyboard, all
+   key events are reported only to the grabbing X11 client.
+   When running in Xwayland, X11 applications may acquire an active
+   grab but that cannot be translated to the Wayland compositor who
+   may set the input focus to some other surface, thus breaking the
+   X11 client assumption that all key events are reported.
+
+   When an X11 client requests a keyboard grab, the Wayland compositor
+   may either inform or ask the user for the right to forward all key
+   events to the given client surface.
+
+   Warning! The protocol described in this file is experimental and
+   backward incompatible changes may be made. Backward compatible
+   changes may be added together with the corresponding interface
+   version bump.
+   Backward incompatible changes are done by 

[PATCH 2/2] Add keyboard shortcuts inhibitor

[Olivier Fourdan]

This adds a new protocol to let Wayland clients specify that they want
all keyboard events to be send to the client, regardless of the
compositor own shortcuts.

This is for use by virtual machine and remote connections viewers.

Signed-off-by: Olivier Fourdan 
---
 unstable/keyboard-shortcuts-inhibit/README |  4 +
 .../keyboard-shortcuts-inhibit-unstable-v1.xml | 85 ++
 2 files changed, 89 insertions(+)
 create mode 100644 unstable/keyboard-shortcuts-inhibit/README
 create mode 100644 
unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml

diff --git a/unstable/keyboard-shortcuts-inhibit/README 
b/unstable/keyboard-shortcuts-inhibit/README
new file mode 100644
index 000..929959c
--- /dev/null
+++ b/unstable/keyboard-shortcuts-inhibit/README
@@ -0,0 +1,4 @@
+Compositor shortcut inhibit protocol
+
+Maintainers:
+Olivier Fourdan 
diff --git 
a/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
new file mode 100644
index 000..f68e25a
--- /dev/null
+++ 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,85 @@
+
+
+
+  
+   Copyright ?? 2017 Red Hat Inc.
+
+   Permission is hereby granted, free of charge, to any person obtaining a
+   copy of this software and associated documentation files (the 
"Software"),
+   to deal in the Software without restriction, 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.
+  
+
+  
+   This protocol specifies a way for a client to request the compositor
+   to ignore its own keyboard shortcuts, so that all keyboard events
+   get forwarded to a surface.
+
+   Warning! The protocol described in this file is experimental and
+   backward incompatible changes may be made. Backward compatible
+   changes may be added together with the corresponding interface
+   version bump.
+   Backward incompatible changes are done by bumping the version
+   number in the protocol and interface names and resetting the
+   interface version. Once the protocol is to be declared stable,
+   the 'z' prefix and the version number in the protocol and
+   interface names are removed and the interface version number is
+   reset.
+  
+
+  
+
+
+  
+   Destroy the keyboard shortcuts inhibitor manager.
+  
+
+
+
+  
+   Create a new keyboard shortcuts inhibitor object associated with the 
given surface.
+  
+  
+  
+
+
+  
+
+  
+
+   A keyboard shortcuts inhibitor instructs the compositor to ignore
+   its own keyboard shortcuts when the associated surface has keyboard
+   focus. As a result, when the surface is focused, it will receive all
+   keyboard events, even those which would normally be caught by the
+   compositor for its own shortcuts.
+
+   If the surface is destroyed, unmapped, or loses keyboard focus, the
+   the compositor will restore its own keyboard shortcuts.
+
+   If the surface regains keyboard focus the inhibitor will take effect
+   again.
+
+
+
+  
+   Remove the keyboard shortcuts inhibitor from the associated wl_surface.
+  
+
+
+  
+
-- 
2.9.3

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

[PATCH weston] input: Do not override keyboard focus on restore

[Quentin Glidic]

From: Quentin Glidic 

If we start a special (grabbing) client when Weston is unfocused, it
would lose focus when coming back to Weston.

Signed-off-by: Quentin Glidic 
---
 libweston/input.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libweston/input.c b/libweston/input.c
index 4fedc558..6ebb4f97 100644
--- a/libweston/input.c
+++ b/libweston/input.c
@@ -2070,7 +2070,8 @@ notify_keyboard_focus_in(struct weston_seat *seat, struct 
wl_array *keys,
 
if (surface) {
wl_list_remove(>saved_kbd_focus_listener.link);
-   weston_keyboard_set_focus(keyboard, surface);
+   if (!keyboard->focus)
+   weston_keyboard_set_focus(keyboard, surface);
seat->saved_kbd_focus = NULL;
}
 }
-- 
2.11.1

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

Re: [PATCH libinput] touchpad: add pressure ranges for cyapa touchpads

[Hans de Goede]

Hi,

On 22-03-17 06:52, Peter Hutterer wrote:

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


LGTM:

Reviewed-by: Hans de Goede 

Regards,

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

Re: [PATCH weston v9 14/62] compositor-drm: Introduce fb_last member

[Pekka Paalanen]

On Fri,  3 Mar 2017 23:05:25 +
Daniel Stone  wrote:

> Clean up some ambiguity around current/next: current could previously
> have referred to a buffer which was being displayed, or the last buffer
> being displayed whilst we waited for a configuration we'd requested to
> take effect.
> 
> Introduce a new variable, fb_last, which exclusively holds the latter
> case, thus leaving us with three unambiguous members: fb_pending is used
> as a scratch space for a buffer we're about to post, fb_current holds
> the buffer we last requested to display (whether active yet or not), and
> fb_last is again scratch space for a buffer which is no longer being
> displayed after a previous configuration reqeust.
> 
> Signed-off-by: Daniel Stone 
> 
> Differential Revision: https://phabricator.freedesktop.org/D1411
> 
> Signed-off-by: Daniel Stone 
> ---
>  libweston/compositor-drm.c | 42 ++
>  1 file changed, 30 insertions(+), 12 deletions(-)

Hi,

the minor problem I have with this patch is that "current" is no longer
the current fb on screen if we have programmed a new flip. Your
new definition "(whether active yet or not)" contains very much an
ambiguity: whether it is actually on screen or not, which I think would
be a fairly important difference.

'current' has never referred to an FB that is no longer on screen,
because page_flip_handler() replaces it with the FB that just came on
screen.

I would argue an FB is "pending" until the flip completes. That makes
me think of the following terminology:

pending: the FB in a programmed flip, but not completed the flip yet.

current: the FB currently on screen

And there is no need for a third state, because when 'current' stop
being current, it only needs to be unreffed, it does not need to be
stored anymore.

But that's how it was, and you need a third state.

If we look at it from the FB point of view:

prepared: the FB (and state) we are building up for the next screen
update.

queued: the FB in a programmed flip, but not completed the flip
yet.

current: the FB currently on screen.

'prepared' would become 'queued' when we issue drmModePageFlip().
When the pageflip completes, 'current' is unreffed, and 'queued'
becomes 'current'.


However, that's a "wrong" point of view. I believe your ultimate aim is
*not* to track FB state, but to track collections of atomic state. An
atomic state set is constructed (fb_pending), programmed (fb_current),
and finished (fb_last). When an atomic state set is finished and
destroyed, the FB is only "current" as it is now on screen. You have no
need to keep the atomic state set that is currently on screen, do you?

I think this patch could use a better explanation, particularly if all
my speculations were in fact incorrect. ;-)


> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 3f6fafc..0f47d4f 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -189,7 +189,7 @@ struct drm_output {
>   uint32_t gbm_format;
>  
>   struct weston_plane fb_plane;
> - struct drm_fb *fb_current, *fb_pending;
> + struct drm_fb *fb_current, *fb_pending, *fb_last;
>  
>   struct drm_fb *dumb[2];
>   pixman_image_t *image[2];
> @@ -209,7 +209,7 @@ struct drm_sprite {
>  
>   struct weston_plane plane;
>  
> - struct drm_fb *fb_current, *fb_pending;
> + struct drm_fb *fb_current, *fb_pending, *fb_last;
>   struct drm_output *output;
>   struct drm_backend *backend;
>  
> @@ -794,6 +794,8 @@ drm_output_repaint(struct weston_output *output_base,
>   if (output->disable_pending || output->destroy_pending)
>   return -1;
>  
> + assert(!output->fb_last);
> +
>   drm_output_render(output, damage);
>   if (!output->fb_pending)
>   return -1;
> @@ -819,6 +821,10 @@ drm_output_repaint(struct weston_output *output_base,
>   goto err_pageflip;
>   }
>  
> + output->fb_last = output->fb_current;
> + output->fb_current = output->fb_pending;
> + output->fb_pending = NULL;
> +
>   output->page_flip_pending = 1;
>  
>   drm_output_set_cursor(output);
> @@ -833,6 +839,8 @@ drm_output_repaint(struct weston_output *output_base,
>   .request.sequence = 1,
>   };
>  
> + /* XXX: Set output much earlier, so we don't attempt to place
> +  *  planes on entirely the wrong output. */

That's an interesting comment, not quite sure what it does in this
patch.

>   if ((!s->fb_current && !s->fb_pending) ||
>   !drm_sprite_crtc_supported(output, s))
>   continue;
> @@ -864,6 +872,9 @@ drm_output_repaint(struct weston_output *output_base,
>   }
>  
>   s->output = output;
> + s->fb_last = s->fb_current;
> + s->fb_current = s->fb_pending;
> +

It seems regular linux desktops can't run android apps even on Wayland?

[Lúcio Boari]

Hello I'm Lúcio. I'm not a programmer so maybe what I am discussing here is
somehow erroneous. Today I was wondering why it's not possible to have
Android apps running natively on a Linux desktop since Android runs atop
the Linux Kernel and it is pretty much compatible with the x86
architecture, and since Google has always open sourced their code. I made
some research and found this page
which
explains basically a triple layered EGL context will always exist if you
try to attach the Android's display server on Wayland, and very few drivers
are capable of handling this.

Why does the same thing doesn't happen with Xwayland? Isn't it the same
kind of problem? It is a pity things are this way because if Android apps
were compatible with the standard linux system there would be a certain
advantage in shipping a standard Linux distro on smartphones and tablets
over the plain Android System to not talk about regular computers which
would gain a huge amount of applications.

I hope you Wayland developers could make a way to attach Androrid
applications on Wayland, but if there's really no good way to do this
currently... If there is I'd like to know why there's apparently no one
interested to make such a thing to happen...
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v9 13/62] compositor-drm: Return FB directly from render

[Pekka Paalanen]

On Fri,  3 Mar 2017 23:05:24 +
Daniel Stone  wrote:

> Instead of setting state members directly in the drm_output_render
> functions (to paint using Pixman or GL), just return a drm_fb, and let
> the core function place it in state.
> 
> Signed-off-by: Daniel Stone 
> 
> Differential Revision: https://phabricator.freedesktop.org/D1419
> 
> Signed-off-by: Daniel Stone 
> ---
>  libweston/compositor-drm.c | 30 +++---
>  1 file changed, 19 insertions(+), 11 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 423bd51..3f6fafc 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -653,11 +653,12 @@ drm_output_prepare_scanout_view(struct drm_output 
> *output,
>   return >fb_plane;
>  }
>  
> -static void
> +static struct drm_fb *
>  drm_output_render_gl(struct drm_output *output, pixman_region32_t *damage)
>  {
>   struct drm_backend *b = to_drm_backend(output->base.compositor);
>   struct gbm_bo *bo;
> + struct drm_fb *ret;
>  
>   output->base.compositor->renderer->repaint_output(>base,
> damage);
> @@ -665,20 +666,21 @@ drm_output_render_gl(struct drm_output *output, 
> pixman_region32_t *damage)
>   bo = gbm_surface_lock_front_buffer(output->gbm_surface);
>   if (!bo) {
>   weston_log("failed to lock front buffer: %m\n");
> - return;
> + return NULL;
>   }
>  
> - output->fb_pending = drm_fb_get_from_bo(bo, b, output->gbm_format,
> - BUFFER_GBM_SURFACE);
> - if (!output->fb_pending) {
> + ret = drm_fb_get_from_bo(bo, b, output->gbm_format, BUFFER_GBM_SURFACE);
> + if (!ret) {
>   weston_log("failed to get drm_fb for bo\n");
>   gbm_surface_release_buffer(output->gbm_surface, bo);
> - return;
> + return NULL;
>   }
> - output->fb_pending->gbm_surface = output->gbm_surface;
> + ret->gbm_surface = output->gbm_surface;
> +
> + return ret;
>  }
>  
> -static void
> +static struct drm_fb *
>  drm_output_render_pixman(struct drm_output *output, pixman_region32_t 
> *damage)
>  {
>   struct weston_compositor *ec = output->base.compositor;
> @@ -694,7 +696,6 @@ drm_output_render_pixman(struct drm_output *output, 
> pixman_region32_t *damage)
>  
>   output->current_image ^= 1;
>  
> - output->fb_pending = drm_fb_ref(output->dumb[output->current_image]);
>   pixman_renderer_output_set_buffer(>base,
> output->image[output->current_image]);
>  
> @@ -702,6 +703,8 @@ drm_output_render_pixman(struct drm_output *output, 
> pixman_region32_t *damage)
>  
>   pixman_region32_fini(_damage);
>   pixman_region32_fini(_damage);
> +
> + return drm_fb_ref(output->dumb[output->current_image]);
>  }
>  
>  static void
> @@ -709,6 +712,7 @@ drm_output_render(struct drm_output *output, 
> pixman_region32_t *damage)
>  {
>   struct weston_compositor *c = output->base.compositor;
>   struct drm_backend *b = to_drm_backend(c);
> + struct drm_fb *fb;
>  
>   /* If we already have a client buffer promoted to scanout, then we don't
>* want to render. */
> @@ -716,9 +720,13 @@ drm_output_render(struct drm_output *output, 
> pixman_region32_t *damage)
>   return;
>  
>   if (b->use_pixman)
> - drm_output_render_pixman(output, damage);
> + fb = drm_output_render_pixman(output, damage);
>   else
> - drm_output_render_gl(output, damage);
> + fb = drm_output_render_gl(output, damage);
> +
> + if (!fb)
> + return;
> + output->fb_pending = fb;
>  
>   pixman_region32_subtract(>primary_plane.damage,
>>primary_plane.damage, damage);

Hi,

this patch has an unmentioned effect: if rendering fails, damage is not
cleared. This is good and logical.

Reviewed-by: Pekka Paalanen 


Thanks,
pq


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

Re: [PATCH weston v9 12/62] compositor-drm: Reshuffle drm_output_render

[Pekka Paalanen]

On Fri,  3 Mar 2017 23:05:23 +
Daniel Stone  wrote:

> Call drm_output_render unconditionally, doing an early exit if we're
> already rendering a client buffer on the primary plane, and asserting
> for damage on the way out.
> 
> Differential Revision: https://phabricator.freedesktop.org/D1494
> 
> Signed-off-by: Daniel Stone 
> ---
>  libweston/compositor-drm.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/libweston/compositor-drm.c b/libweston/compositor-drm.c
> index 5a54e29..423bd51 100644
> --- a/libweston/compositor-drm.c
> +++ b/libweston/compositor-drm.c
> @@ -710,6 +710,11 @@ drm_output_render(struct drm_output *output, 
> pixman_region32_t *damage)
>   struct weston_compositor *c = output->base.compositor;
>   struct drm_backend *b = to_drm_backend(c);
>  
> + /* If we already have a client buffer promoted to scanout, then we don't
> +  * want to render. */
> + if (output->fb_pending)
> + return;
> +
>   if (b->use_pixman)
>   drm_output_render_pixman(output, damage);
>   else
> @@ -781,8 +786,7 @@ drm_output_repaint(struct weston_output *output_base,
>   if (output->disable_pending || output->destroy_pending)
>   return -1;
>  
> - if (!output->fb_pending)
> - drm_output_render(output, damage);
> + drm_output_render(output, damage);
>   if (!output->fb_pending)
>   return -1;
>  

Hi,

instead of this, my first idea would be to take the following patch and
extend it even further to return the drm_fb out from
drm_output_render() so that drm_output_repaint() can set
output->fb_pending.

Anyway.

What's the talk about asserting for damage? I don't see it. If you can
just remove that sentence, then:
Reviewed-by: Pekka Paalanen 


Thanks,
pq


pgpSxGCt4l_C0.pgp
Description: OpenPGP digital signature
___
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

[Pekka Paalanen]

On Wed, 22 Mar 2017 12:23:46 +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.
> 
> 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.

Hi,

if one allows a generic tool that essentially exposes everything at
will, there isn't much point in authenticating that program, because
any other program can simply call it.

> 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)

It's essentially the same problem we have with all the privileged
Wayland interfaces, too.

Containers or sandboxing have been mentioned as a possible way to let
the OS reliably identify the running program.


> == 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 possibility is to always create at least one new virtual seat
(wl_seat) for the emulated input devices. Woodotool clients would see
the virtual seat and possibly be allowed to create and destroy more
virtual seats at will. This would not leak or interfere with the real
seats.

At the same time it would also exclude use cases where one wants 

Re: [RFC] Interface for injection of input events

[Christopher James Halse Rogers]

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