Re: [PATCH 3/3] xwayland: Fix override redirect window positioning

[Scott Moreau]

On Sat, Jun 24, 2017 at 1:18 AM, Scott Moreau  wrote:

> When override redirect windows are created, the x/y offsets
> provided at map time may be incorrect. The correct offsets are
> sent in a configure event from the xserver some time later.
> Here we fix the positions by delaying the call to set_xwayland()
> from map time to the needed configure event in the case where x/y
> are both 0 for override redirect windows.
> ---
>  xwayland/window-manager.c | 23 ---
>  xwayland/xwayland.h   |  1 +
>  2 files changed, 21 insertions(+), 3 deletions(-)
>
> diff --git a/xwayland/window-manager.c b/xwayland/window-manager.c
> index 951a7cf..2e61ea4 100644
> --- a/xwayland/window-manager.c
> +++ b/xwayland/window-manager.c
> @@ -169,6 +169,7 @@ struct weston_wm_window {
> int maximized_horz;
> struct wm_size_hints size_hints;
> struct motif_wm_hints motif_hints;
> +   struct wl_list or_link;
> struct wl_list link;
>  };
>
> @@ -737,9 +738,11 @@ our_resource(struct weston_wm *wm, uint32_t id)
>  static void
>  weston_wm_handle_configure_notify(struct weston_wm *wm,
> xcb_generic_event_t *event)
>  {
> +   const struct weston_desktop_xwayland_interface *xi =
> +   wm->server->compositor->xwayland_interface;
> xcb_configure_notify_event_t *configure_notify =
> (xcb_configure_notify_event_t *) event;
> -   struct weston_wm_window *window;
> +   struct weston_wm_window *window, *w, *next;
>
> wm_log("XCB_CONFIGURE_NOTIFY (window %d) %d,%d @ %dx%d%s\n",
>configure_notify->window,
> @@ -760,6 +763,16 @@ weston_wm_handle_configure_notify(struct weston_wm
> *wm, xcb_generic_event_t *eve
> if (window->frame)
> frame_resize_inside(window->frame,
> window->width, window->height);
> +   if (window->x != 0 || window->y != 0) {
> +   wl_list_for_each_safe(w, next,
> >or_window_list, or_link) {
> +   if (w == window) {
> +   if (w->shsurf)
> +
>  xi->set_xwayland(w->shsurf, w->x, w->y);
> +   wl_list_remove(>or_link);
> +   break;
> +   }
> +   }
> +   }
> }
>  }
>
> @@ -2478,6 +2491,7 @@ weston_wm_create(struct weston_xserver *wxs, int fd)
> wl_signal_add(>compositor->kill_signal,
>   >kill_listener);
> wl_list_init(>unpaired_window_list);
> +   wl_list_init(>or_window_list);
>
> weston_wm_create_cursors(wm);
> weston_wm_window_set_cursor(wm, wm->screen->root,
> XWM_CURSOR_LEFT_PTR);
> @@ -2761,8 +2775,11 @@ xserver_map_shell_surface(struct weston_wm_window
> *window,
>
>  window->legacy_fullscreen_output.output);
> return;
> } else if (window->override_redirect) {
> -   xwayland_interface->set_xwayland(window->shsurf,
> -window->x, window->y);
> +   if (window->x == 0 && window->y == 0)
> +   wl_list_insert(>or_window_list,
> >or_link);
> +   else
> +   xwayland_interface->set_xwayland(window->shsurf,
> +
>  window->x, window->y);
> } else if (window->transient_for && window->transient_for->surface)
> {
> parent = window->transient_for;
> if (weston_wm_window_type_inactive(window)) {
> diff --git a/xwayland/xwayland.h b/xwayland/xwayland.h
> index ca75f5b..54e8908 100644
> --- a/xwayland/xwayland.h
> +++ b/xwayland/xwayland.h
> @@ -72,6 +72,7 @@ struct weston_wm {
> struct wl_listener activate_listener;
> struct wl_listener kill_listener;
> struct wl_list unpaired_window_list;
> +   struct wl_list or_window_list;
>
> xcb_window_t selection_window;
> xcb_window_t selection_owner;
> --
> 2.7.4
>
>

The problem fixed by this patch is also fixed with
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034357.html
which is a much cleaner solution.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH wayland-protocols v8 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 sent to the client, regardless of the
compositor own shortcuts.

This protocol can be used for virtual machine and remote connection
viewers which require to pass all keyboard shortcuts to the hosted or
remote system instead of being caught up by the compositor locally.

Signed-off-by: Olivier Fourdan 
Reviewed-by: Peter Hutterer 
---
 v6: Indentation issues, rephrase "active" event description as per Peter's
 review
 Remove the key combo definition after discussing with Peter and Jonas
 on irc #wayland:
 
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=wayland=2017-06-06
 v7: Add the definition on "inactive" event that I removed by mistake instead
 of amending it between iteration 3 and 4...
 v8: Clarify keyboard focus and rephrase full access to all keyboard shortcuts
 as per Jonas review.

 Makefile.am|   1 +
 unstable/keyboard-shortcuts-inhibit/README |   4 +
 .../keyboard-shortcuts-inhibit-unstable-v1.xml | 143 +
 3 files changed, 148 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/Makefile.am b/Makefile.am
index 12465e6..d100c13 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -13,6 +13,7 @@ unstable_protocols =  
\
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/unstable/keyboard-shortcuts-inhibit/README 
b/unstable/keyboard-shortcuts-inhibit/README
new file mode 100644
index 000..63ff335
--- /dev/null
+++ b/unstable/keyboard-shortcuts-inhibit/README
@@ -0,0 +1,4 @@
+Compositor shortcuts 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..2774876
--- /dev/null
+++ 
b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
@@ -0,0 +1,143 @@
+
+
+
+  
+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 for a given seat, so that all
+key events from that seat 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.
+  
+
+  
+
+  A global interface used for inhibiting the compositor keyboard shortcuts.
+
+
+
+  
+   Destroy the keyboard shortcuts inhibitor manager.
+  
+
+
+
+  
+   Create a new keyboard shortcuts inhibitor object associated with
+   the given surface for the given seat.
+
+   

[PATCH wayland-protocols v6 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
(thus not focused by the window manager) and issue an active grab on the
keyboard to capture all keyboard events.

Signed-off-by: Olivier Fourdan 
Reviewed-by: Peter Hutterer 
---
 Makefile.am|   1 +
 unstable/xwayland-keyboard-grab/README |   4 +
 .../xwayland-keyboard-grab-unstable-v1.xml | 121 +
 3 files changed, 126 insertions(+)
 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..12465e6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -12,6 +12,7 @@ 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  
\
$(NULL)
 
 stable_protocols = 
\
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..be4992f
--- /dev/null
+++ b/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
@@ -0,0 +1,121 @@
+
+
+
+  
+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 is application-specific to meet the needs of the X11
+protocol through Xwayland. It provides a way for Xwayland to request
+all keyboard events to be forwarded to a surface even when the
+surface does not have keyboard focus.
+
+In the X11 protocol, a client may request an "active grab" on the
+keyboard. On success, all key events are reported only to the
+grabbing X11 client. For details, see XGrabKeyboard(3).
+
+The core Wayland protocol does not have a notion of an active
+keyboard grab. When running in Xwayland, X11 applications may
+acquire an active grab inside Xwayland but that cannot be translated
+to the Wayland compositor who may set the input focus to some other
+surface. In doing so, it breaks the X11 client assumption that all
+key events are reported to the grabbing client.
+
+This protocol specifies a way for Xwayland to request all keyboard
+be directed to the given surface. The protocol does not guarantee
+that the compositor will honor this request and it does not
+prescribe user interfaces on how to handle the respond. For example,
+a compositor may inform the user that all key events are now
+forwarded to the given client surface, or it may ask the user for
+permission to do so.
+
+Compositors are required to restrict access to this application
+specific protocol to Xwayland alone.
+
+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 

Re: [PATCH libinput] tools: add the libinput version to the man pages

[Eric Engestrom]

On Friday, 2017-06-30 16:21:39 +0100, Eric Engestrom wrote:
> On Thursday, 2017-06-29 10:01:10 +1000, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer 
> > ---
> >  configure.ac   |  1 +
> >  meson.build| 45 
> > +++---
> >  tools/Makefile.am  |  7 
> >  ...ut-debug-events.1 => libinput-debug-events.man} |  2 +-
> >  ...libinput-debug-gui.1 => libinput-debug-gui.man} |  2 +-
> >  ...ut-list-devices.1 => libinput-list-devices.man} |  2 +-
> >  ...pad-tap.1 => libinput-measure-touchpad-tap.man} |  2 +-
> >  tools/{libinput-measure.1 => libinput-measure.man} |  2 +-
> >  tools/{libinput.1 => libinput.man} |  2 +-
> >  9 files changed, 53 insertions(+), 12 deletions(-)
> >  rename tools/{libinput-debug-events.1 => libinput-debug-events.man} (97%)
> >  rename tools/{libinput-debug-gui.1 => libinput-debug-gui.man} (94%)
> >  rename tools/{libinput-list-devices.1 => libinput-list-devices.man} (94%)
> >  rename tools/{libinput-measure-touchpad-tap.1 => 
> > libinput-measure-touchpad-tap.man} (96%)
> >  rename tools/{libinput-measure.1 => libinput-measure.man} (90%)
> >  rename tools/{libinput.1 => libinput.man} (95%)
> > 
> > diff --git a/configure.ac b/configure.ac
> > index 067c3e1a..a66371cd 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -46,6 +46,7 @@ AC_USE_SYSTEM_EXTENSIONS
> >  AC_PROG_CC_C99
> >  AC_PROG_CXX # Only used by build C++ test
> >  AC_PROG_GREP
> > +AC_PROG_SED
> >  
> >  # Only used for testing the hwdb
> >  AM_PATH_PYTHON([3.0],, [:])
> > diff --git a/meson.build b/meson.build
> > index bd9b6193..bc639718 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -357,6 +357,9 @@ lib_tools_shared = static_library('tools_shared',
> >  dep_tools_shared = declare_dependency(link_with : lib_tools_shared,
> >   dependencies : deps_tools_shared)
> >  
> > +man_config = configuration_data()
> > +man_config.set('LIBINPUT_VERSION', meson.project_version())
> > +
> >  deps_tools = [ dep_tools_shared, dep_libinput ]
> >  libinput_debug_events_sources = [ 'tools/libinput-debug-events.c' ]
> >  executable('libinput-debug-events',
> > @@ -366,7 +369,12 @@ executable('libinput-debug-events',
> >install_dir : libinput_tool_path,
> >install : true
> >)
> > -install_man('tools/libinput-debug-events.1')
> > +configure_file(input : 'tools/libinput-debug-events.man',
> > +  output : 'libinput-debug-events.1',
> > +  configuration : man_config,
> 
> Well, it's a shame install_man() doesn't have a `configuration:`
> argument :(
> 
> > +  install : true,
> > +  install_dir : join_paths(get_option('mandir'), 'man1')
> 
> Took me a minute to find that get_option() allows you to query builtin
> options as well [1]. Is there a list of those builtins somewhere?

Ha! found it: when you run `mesonconf` with no argument, you get a list
of all the options, including the directories :)

> 
> [1] http://mesonbuild.com/Build-options.html
> 
> Assuming 'mandir' is indeed in that list,
> Reviewed-by: Eric Engestrom 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] tools: add the libinput version to the man pages

[Eric Engestrom]

On Thursday, 2017-06-29 10:01:10 +1000, Peter Hutterer wrote:
> Signed-off-by: Peter Hutterer 
> ---
>  configure.ac   |  1 +
>  meson.build| 45 
> +++---
>  tools/Makefile.am  |  7 
>  ...ut-debug-events.1 => libinput-debug-events.man} |  2 +-
>  ...libinput-debug-gui.1 => libinput-debug-gui.man} |  2 +-
>  ...ut-list-devices.1 => libinput-list-devices.man} |  2 +-
>  ...pad-tap.1 => libinput-measure-touchpad-tap.man} |  2 +-
>  tools/{libinput-measure.1 => libinput-measure.man} |  2 +-
>  tools/{libinput.1 => libinput.man} |  2 +-
>  9 files changed, 53 insertions(+), 12 deletions(-)
>  rename tools/{libinput-debug-events.1 => libinput-debug-events.man} (97%)
>  rename tools/{libinput-debug-gui.1 => libinput-debug-gui.man} (94%)
>  rename tools/{libinput-list-devices.1 => libinput-list-devices.man} (94%)
>  rename tools/{libinput-measure-touchpad-tap.1 => 
> libinput-measure-touchpad-tap.man} (96%)
>  rename tools/{libinput-measure.1 => libinput-measure.man} (90%)
>  rename tools/{libinput.1 => libinput.man} (95%)
> 
> diff --git a/configure.ac b/configure.ac
> index 067c3e1a..a66371cd 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -46,6 +46,7 @@ AC_USE_SYSTEM_EXTENSIONS
>  AC_PROG_CC_C99
>  AC_PROG_CXX # Only used by build C++ test
>  AC_PROG_GREP
> +AC_PROG_SED
>  
>  # Only used for testing the hwdb
>  AM_PATH_PYTHON([3.0],, [:])
> diff --git a/meson.build b/meson.build
> index bd9b6193..bc639718 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -357,6 +357,9 @@ lib_tools_shared = static_library('tools_shared',
>  dep_tools_shared = declare_dependency(link_with : lib_tools_shared,
> dependencies : deps_tools_shared)
>  
> +man_config = configuration_data()
> +man_config.set('LIBINPUT_VERSION', meson.project_version())
> +
>  deps_tools = [ dep_tools_shared, dep_libinput ]
>  libinput_debug_events_sources = [ 'tools/libinput-debug-events.c' ]
>  executable('libinput-debug-events',
> @@ -366,7 +369,12 @@ executable('libinput-debug-events',
>  install_dir : libinput_tool_path,
>  install : true
>  )
> -install_man('tools/libinput-debug-events.1')
> +configure_file(input : 'tools/libinput-debug-events.man',
> +output : 'libinput-debug-events.1',
> +configuration : man_config,

Well, it's a shame install_man() doesn't have a `configuration:`
argument :(

> +install : true,
> +install_dir : join_paths(get_option('mandir'), 'man1')

Took me a minute to find that get_option() allows you to query builtin
options as well [1]. Is there a list of those builtins somewhere?

[1] http://mesonbuild.com/Build-options.html

Assuming 'mandir' is indeed in that list,
Reviewed-by: Eric Engestrom 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v5 1/2] Introduce keyboard grabbing protocol for Xwayland

[Olivier Fourdan]

Hi Jonas,

> > [...]
> > +
> > +
> > +  
> > +   The grab_keyboard request asks for a grab of the keyboard,
> > +   effectively reporting all key events to a surface.
> 
> I can't seem to find where "grab" is defined. Normally in other Wayland
> protocols, a "grab" means locking keyboard/pointer/touch focus on a
> certain focus, but reading the above specification, it sounds rather
> like here a "grab" doesn't affect keyboard focus, but rather where
> keyboard events are sent.
> 
> So, does this grab lock the keyboard focus on the given surface? Or
> should the compositor simply ignore the keyboard focus when routing
> events? If it's the latter, how would the client (Xwayland) know about
> pressed keys and things like that that comes with a wl_keyboard.enter
> event?

That would be the former, the compositor forces the keyboard focus onto the 
given surface.

In mutter terms, for example, it does a:

  meta_wayland_keyboard_set_focus (keyboard, active_grab->surface);

in the MetaWaylandKeyboardGrabInterface's "grab_keyboard_key" handler.

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

Re: [RFC PATCH wayland-protocols] Introduce logical output protocol for Xwayland

[Pekka Paalanen]

On Fri, 30 Jun 2017 04:38:07 -0400 (EDT)
Olivier Fourdan  wrote:

> Hi Jonas,
> 
> > On Thu, Jun 29, 2017 at 04:44:34PM +0200, Olivier Fourdan wrote:  
> > > This introduces a new protocol for the compositor to describe outputs
> > > size in a logical way for Xwayland.

> > Adding it to wl_output might be fine anyway, as we could refer to it
> > when talking about how clients should not rely on calculating its own
> > "output size" by looking at wl_output::mode, wl_output::transform and
> > wl_output::scale, but we could just as well clarify that they simply
> > shouldn't.  
> 
> Yes, on further consideration and as we discussed earlier today on
> irc, this might be of interest to some other clients as well, so
> adding it to the existing wl_output interface makes sense imho,
> rather than adding an Xwayland specific interface...

Hi,

please consider that it is impossible to have a stabilization period
for changes to the wl_output interface. What ever you add will be set
in stone immediately, before a considerable user base has had a chance
to try it. There will be no going back once it's there, AFAICT no way
to have it reasonably tested on the field beforehand.

In hindsight I think the position x,y arguments we already have in
wl_output do not belong there. Only traditional 2D desktops can
meaningfully set them. They already break down completely in IVI
systems, where the outputs may be independent in the sense that there
is no path in the logical coordinate system that you could take to
travel from one output to another in a way that would make sense. Not
all systems have a single connected area created from outputs, that
design is quite specific to desktops.

I would like us to be careful with not adding more desktop assumptions
to core Wayland interfaces. Whether this proposal would add some, I
cannot tell yet.


Thanks,
pq


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

[PATCH wayland] protocol: Add logical_size event to wl_output

[Olivier Fourdan]

With the introduction of fractional scaling in some compositors and due
to existing discrepancies between compositors on the way Xwayland
surfaces are scaled based on the wl_output scale, Xwayland and possibly
other Wayland clients need a way to know the size of the outputs in the
global compositor space regardless of the advertised scaling factor.

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

Signed-off-by: Olivier Fourdan 
---
 This is the follow-up on:
 https://lists.freedesktop.org/archives/wayland-devel/2017-June/034384.html

 protocol/wayland.xml | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 29b63be..524a2de 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -2338,7 +2338,7 @@
 
   
 
-  
+  
 
   An output describes part of the compositor geometry.  The
   compositor works in the 'compositor coordinate system' and an
@@ -2486,6 +2486,24 @@
use the output object anymore.
   
 
+
+
+
+
+  
+   The logical_size event describes the size of the output in the global
+   compositor space.
+
+   For example, a surface with the size matching the logical_size will
+   have the same size as the corresponding output when displayed.
+
+   Clients such as Xwayland need this to configure their surfaces in
+   the global compositor space as the compositor may apply a different
+   scale from what is advertised by the output scaling property (to
+   achieve fractional scaling for example).
+  
+
+
   
 
   
-- 
2.9.4

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

Re: [RFC PATCH wayland-protocols] Introduce logical output protocol for Xwayland

[Olivier Fourdan]

Hi Jonas,

> On Thu, Jun 29, 2017 at 04:44:34PM +0200, Olivier Fourdan wrote:
> > This introduces a new protocol for the compositor to describe outputs
> > size in a logical way for Xwayland.
> > 
> > This is needed for X11 applications that would want to configure an X11
> > window based on the size of the output, without knowing the output scale
> > factor applied by the compositor to the corresponding Xwayland surface.
> 
> So, yes, Xwayland needs this, and I see no way around it. On IRC you
> raised the question whether this should really be part of wl_output is a
> good question indeed. Would it ever be useful for a regular Wayland
> client to know about this?
> 
> For fullscreening, we already communicate the expected size (in the
> surface coordinate space) via the xdg_toplevel.configure event. Knowing
> how much space is available on a work space (i.e. possibly useful for
> avoiding too big windows) wouldn't be possible as this wouldn't include
> panels, launchers etc, nor would the client know on what output it'll be
> started (yet at least).
> 
> Adding it to wl_output might be fine anyway, as we could refer to it
> when talking about how clients should not rely on calculating its own
> "output size" by looking at wl_output::mode, wl_output::transform and
> wl_output::scale, but we could just as well clarify that they simply
> shouldn't.

Yes, on further consideration and as we discussed earlier today on irc, this 
might be of interest to some other clients as well, so adding it to the 
existing wl_output interface makes sense imho, rather than adding an Xwayland 
specific interface...

> 
> Anyway, some comments about this proposal below:
> 
> [...]
> 
> As mentioned, I'd say not talking about "scaled" is better, but rather
> talk about coordinate spaces, and how a surface size is represented in
> it. wl_output talks about the "compositor space" which is indeed what we
> are communicating here, but having an example about how the size of a
> surface normally will have corresponding size in the compositor space
> would be good.
> 
> For example, a surface with the same size as the size advertised here
> will normally have the same size as the monitor when displayed could be
> such an example.

I'll take this as an example in the wl_output addition indeed.

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

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Jonas Ådahl]

On Fri, Jun 30, 2017 at 09:56:57AM +0200, Philipp Kerling wrote:
> Am Freitag, den 30.06.2017, 15:42 +0800 schrieb Jonas Ådahl:
> > On Fri, Jun 30, 2017 at 08:48:58AM +0200, Philipp Kerling wrote:
> > > Hi,
> > > 
> > > Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> > > > Rename the interfaces according to the wayland-protocols policy.
> > > > Since
> > > > the name 'xdg_shell' as an interface was already taken (by
> > > > xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> > > > surface role related interfaces were not renamed, as naming
> > > > collision
> > > > is only unmanagable when exposed as globals via the registry.
> > > 
> > > What about clients that want to support both xdg_shell (unstable
> > > v5)
> > > and xdg_wm_base? Won't they have a problem with
> > >A. clashing type/function/macro names in the header files
> > > generated by
> > >   wayland-scanner, at least when they are including both
> > > headers in
> > >   one file?
> > >B. clashing interface global names (e.g.
> > > "xdg_toplevel_interface") at
> > >   link time even when they do not include both headers at the
> > > same
> > >   time?
> > 
> > Right. This means you can't have xdg_shell_unstable_v5 at the same
> > time
> > as xdg_wm_base, without messing around avoiding compiling and linking
> > issues.
> > 
> > Personally I'd rather not support v5 instead of coming up with new
> > names
> > for everything; it *is* (was) an unstable protocol version and it has
> > always been expected that support for it will be removed.
> Yes I know, but the situation is that this particular unstable protocol
> practically had to be implemented to have a somewhat usable desktop
> experience due to the shortcomings of wl_shell.
> 
> > Do you know of
> > any client out in the wild that still only supports xdg_shell
> > unstable
> > v5?
> I was thinking more of e.g. Qt (or any other toolkit) that supports
> wl_shell, xdg_shell unstable v5 and v6 (albeit to a wildly differing
> extent sadly) and would now have to drop unstable v5 in order to
> support xdg_wm_base. Also, I think both KWin and Qt did only support
> unstable v5 until very recently. wl_shell is always available as
> fallback though.

I see.

> Do note that I am not personally opposed to saying that that's the way
> it is going to be, I just wanted to point this out since the commit
> message was a bit brief on the implications of keeping the interface
> names. If you have considered this and decided that people will have to
> drop v5 support (compositors as well as clients I presume) if they had
> it before, everything is fine by me.

The compatibility issues raised in the commit message is about clients
discovering what a compositor supports, rather then what a compositor
can implement without too much trouble. FWIW, an alternative if is too
much of an issue is to add support to wayland-scanner to add a custom
prefix/postfix to symbols, so we can have the unstable v5 symbols not
look like stable ones.

It's a valid issue to raise though and should be properly documented
some how, I had not considered the linking issues.


Jonas

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

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Philipp Kerling]

Am Freitag, den 30.06.2017, 15:42 +0800 schrieb Jonas Ådahl:
> On Fri, Jun 30, 2017 at 08:48:58AM +0200, Philipp Kerling wrote:
> > Hi,
> > 
> > Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> > > Rename the interfaces according to the wayland-protocols policy.
> > > Since
> > > the name 'xdg_shell' as an interface was already taken (by
> > > xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> > > surface role related interfaces were not renamed, as naming
> > > collision
> > > is only unmanagable when exposed as globals via the registry.
> > 
> > What about clients that want to support both xdg_shell (unstable
> > v5)
> > and xdg_wm_base? Won't they have a problem with
> >A. clashing type/function/macro names in the header files
> > generated by
> >   wayland-scanner, at least when they are including both
> > headers in
> >   one file?
> >B. clashing interface global names (e.g.
> > "xdg_toplevel_interface") at
> >   link time even when they do not include both headers at the
> > same
> >   time?
> 
> Right. This means you can't have xdg_shell_unstable_v5 at the same
> time
> as xdg_wm_base, without messing around avoiding compiling and linking
> issues.
> 
> Personally I'd rather not support v5 instead of coming up with new
> names
> for everything; it *is* (was) an unstable protocol version and it has
> always been expected that support for it will be removed.
Yes I know, but the situation is that this particular unstable protocol
practically had to be implemented to have a somewhat usable desktop
experience due to the shortcomings of wl_shell.

> Do you know of
> any client out in the wild that still only supports xdg_shell
> unstable
> v5?
I was thinking more of e.g. Qt (or any other toolkit) that supports
wl_shell, xdg_shell unstable v5 and v6 (albeit to a wildly differing
extent sadly) and would now have to drop unstable v5 in order to
support xdg_wm_base. Also, I think both KWin and Qt did only support
unstable v5 until very recently. wl_shell is always available as
fallback though.
Do note that I am not personally opposed to saying that that's the way
it is going to be, I just wanted to point this out since the commit
message was a bit brief on the implications of keeping the interface
names. If you have considered this and decided that people will have to
drop v5 support (compositors as well as clients I presume) if they had
it before, everything is fine by me.

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

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Jonas Ådahl]

On Fri, Jun 30, 2017 at 08:48:58AM +0200, Philipp Kerling wrote:
> Hi,
> 
> Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> > Rename the interfaces according to the wayland-protocols policy.
> > Since
> > the name 'xdg_shell' as an interface was already taken (by
> > xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> > surface role related interfaces were not renamed, as naming collision
> > is only unmanagable when exposed as globals via the registry.
> What about clients that want to support both xdg_shell (unstable v5)
> and xdg_wm_base? Won't they have a problem with
>A. clashing type/function/macro names in the header files generated by
>   wayland-scanner, at least when they are including both headers in
>   one file?
>B. clashing interface global names (e.g. "xdg_toplevel_interface") at
>   link time even when they do not include both headers at the same
>   time?

Right. This means you can't have xdg_shell_unstable_v5 at the same time
as xdg_wm_base, without messing around avoiding compiling and linking
issues.

Personally I'd rather not support v5 instead of coming up with new names
for everything; it *is* (was) an unstable protocol version and it has
always been expected that support for it will be removed. Do you know of
any client out in the wild that still only supports xdg_shell unstable
v5?


Jonas


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

Re: [PATCH wayland-protocols v2 02/13] xdg-shell: Rename interfaces

[Philipp Kerling]

Hi,

Am Freitag, den 30.06.2017, 13:50 +0800 schrieb Jonas Ådahl:
> Rename the interfaces according to the wayland-protocols policy.
> Since
> the name 'xdg_shell' as an interface was already taken (by
> xdg-shell-unstable-v5) zxdg_shell_v6 was renamed xdg_wm_base. The
> surface role related interfaces were not renamed, as naming collision
> is only unmanagable when exposed as globals via the registry.
What about clients that want to support both xdg_shell (unstable v5)
and xdg_wm_base? Won't they have a problem with
   A. clashing type/function/macro names in the header files generated by
  wayland-scanner, at least when they are including both headers in
  one file?
   B. clashing interface global names (e.g. "xdg_toplevel_interface") at
  link time even when they do not include both headers at the same
  time?

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