[PATCH wayland-protocols 0/3] Replace autotools with meson (+ build tests)

[Jonas Ådahl]

Hi,

I wanted to add compile tests to all protocols, testing that we can
compile on C++ and pedantic C99. I didn't care for figuring out how to
do that with autotools so I ported wayland-protocols to meson instead
before adding build testing.

Note that I have not tested how this works in a cross compile
environment, so I'd appreciate if anyone depending on such system
configuration to test this series out.


Jonas


Jonas Ådahl (3):
  Add meson build system support
  tests: Add compile tests
  Remove autotools build system

 .gitignore| 16 
 Makefile.am   | 43 
 configure.ac  | 45 -
 m4/compat.m4  | 12 --
 meson.build   | 81 ++
 meson_options.txt |  4 ++
 tests/build-cxx.cc.in | 12 ++
 tests/build-pedantic.c.in | 10 +
 tests/meson.build | 99 +++
 tests/replace.py  | 23 +++
 wayland-protocols.pc.in   |  2 +-
 11 files changed, 230 insertions(+), 117 deletions(-)
 delete mode 100644 Makefile.am
 delete mode 100644 configure.ac
 delete mode 100644 m4/compat.m4
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 tests/build-cxx.cc.in
 create mode 100644 tests/build-pedantic.c.in
 create mode 100644 tests/meson.build
 create mode 100755 tests/replace.py

-- 
2.13.5

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

[PATCH wayland-protocols 1/3] Add meson build system support

[Jonas Ådahl]

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 meson.build | 81 +
 meson_options.txt   |  4 +++
 tests/meson.build   | 13 
 wayland-protocols.pc.in |  2 +-
 4 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 meson.build
 create mode 100644 meson_options.txt
 create mode 100644 tests/meson.build

diff --git a/meson.build b/meson.build
new file mode 100644
index 000..b7f2a5b
--- /dev/null
+++ b/meson.build
@@ -0,0 +1,81 @@
+project('wayland-protocols',
+version: '1.11',
+meson_version: '>= 0.36.0')
+wayland_protocols_version = meson.project_version()
+
+stable_protocols = [
+  'stable/presentation-time/presentation-time.xml',
+  'stable/viewporter/viewporter.xml',
+]
+
+unstable_protocols = [
+  'unstable/pointer-gestures/pointer-gestures-unstable-v1.xml',
+  'unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml',
+  'unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml',
+  'unstable/text-input/text-input-unstable-v1.xml',
+  'unstable/input-method/input-method-unstable-v1.xml',
+  'unstable/xdg-shell/xdg-shell-unstable-v5.xml',
+  'unstable/xdg-shell/xdg-shell-unstable-v6.xml',
+  'unstable/relative-pointer/relative-pointer-unstable-v1.xml',
+  'unstable/pointer-constraints/pointer-constraints-unstable-v1.xml',
+  'unstable/tablet/tablet-unstable-v1.xml',
+  'unstable/tablet/tablet-unstable-v2.xml',
+  'unstable/xdg-foreign/xdg-foreign-unstable-v1.xml',
+  'unstable/xdg-foreign/xdg-foreign-unstable-v2.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',
+  'unstable/xdg-output/xdg-output-unstable-v1.xml',
+]
+
+protocols = stable_protocols + unstable_protocols
+
+# Check that each protocol has a README
+foreach protocol : protocols
+  protocol_components = protocol.split('/')
+  stability = protocol_components[0]
+  protocol_name = protocol_components[1]
+  readme_path = join_paths(meson.source_root(),
+   stability,
+   protocol_name,
+   'README')
+  if run_command('[', '-f', readme_path, ']').returncode() != 0
+error('Missing README in @0@'.format(protocol))
+  endif
+endforeach
+
+wayland_scanner = find_program('wayland-scanner')
+
+foreach protocol : stable_protocols + unstable_protocols
+  protocol_components = protocol.split('/')
+  stability = protocol_components[0]
+  protocol_name = protocol_components[1]
+  xml_file = protocol_components[2]
+  protocol_install_dir = join_paths(get_option('datadir'),
+'wayland-protocols',
+stability,
+protocol_name)
+  install_data(protocol,
+   install_dir: protocol_install_dir)
+endforeach
+
+pkgconfig_configuration = configuration_data()
+pkgconfig_configuration.set('prefix', get_option('prefix'))
+pkgconfig_configuration.set('datadir', get_option('datadir'))
+pkgconfig_configuration.set('abs_top_srcdir', meson.source_root())
+pkgconfig_configuration.set('PACKAGE', 'wayland-protocols')
+pkgconfig_configuration.set('WAYLAND_PROTOCOLS_VERSION', 
wayland_protocols_version)
+
+pkg_install_dir = join_paths(get_option('datadir'), 'pkgconfig')
+configure_file(input: 'wayland-protocols.pc.in',
+   output: 'wayland-protocols.pc',
+   configuration: pkgconfig_configuration,
+   install_dir: pkg_install_dir)
+
+configure_file(input: 'wayland-protocols-uninstalled.pc.in',
+   output: 'wayland-protocols-uninstalled.pc',
+   configuration: pkgconfig_configuration)
+
+if get_option('tests')
+  subdir('tests')
+endif
diff --git a/meson_options.txt b/meson_options.txt
new file mode 100644
index 000..3ce457d
--- /dev/null
+++ b/meson_options.txt
@@ -0,0 +1,4 @@
+option('tests',
+   type: 'boolean',
+   value: true,
+   description: 'Build the tests [default=true]')
diff --git a/tests/meson.build b/tests/meson.build
new file mode 100644
index 000..267a36a
--- /dev/null
+++ b/tests/meson.build
@@ -0,0 +1,13 @@
+scan_sh = find_program('scan.sh')
+wayland_scanner = find_program('wayland-scanner')
+
+# Check that each protocol passes through the scanner
+foreach protocol : protocols
+  protocol_path = join_paths(meson.source_root(), protocol)
+  test_name = 'scan-@0@'.format('protocol_file')
+  test(test_name, scan_sh,
+   args: protocol_path,
+   env: [
+ 'SCANNER=@0@'.format(wayland_scanner.path()),
+   ])
+endforeach
diff --git a/wayland-protocols.pc.in b/wayland-protocols.pc.in
index 379be06..bd082e1 100644
--- a/wayland-protocols.pc.in
+++ b/wayland-protocols.pc.in
@@ -1,5 +1,5 @@
 prefix=@prefix@
-datarootdir=@datarootdir@
+datarootdir=${prefix}/@datadir@
 pkgdatadir=${pc_sysrootdir

[PATCH wayland-protocols 3/3] Remove autotools build system

[Jonas Ådahl]

It has been replaced by meson.
---
 .gitignore   | 16 
 Makefile.am  | 43 ---
 configure.ac | 45 -
 m4/compat.m4 | 12 
 4 files changed, 116 deletions(-)
 delete mode 100644 Makefile.am
 delete mode 100644 configure.ac
 delete mode 100644 m4/compat.m4

diff --git a/.gitignore b/.gitignore
index 794539b..e69de29 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,16 +0,0 @@
-Makefile
-Makefile.in
-configure
-config.guess
-config.log
-config.status
-config.sub
-compile
-install-sh
-missing
-*.pc
-autom4te.cache
-aclocal.m4
-*.trs
-*.log
-test-driver
diff --git a/Makefile.am b/Makefile.am
deleted file mode 100644
index 0296d5d..000
--- a/Makefile.am
+++ /dev/null
@@ -1,43 +0,0 @@
-unstable_protocols =   
\
-   unstable/pointer-gestures/pointer-gestures-unstable-v1.xml  
\
-   unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
-   unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
-   unstable/text-input/text-input-unstable-v1.xml  
\
-   unstable/input-method/input-method-unstable-v1.xml  
\
-   unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
-   unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
-   unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
-   unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
-   unstable/tablet/tablet-unstable-v1.xml  
\
-   unstable/tablet/tablet-unstable-v2.xml  
\
-   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
\
-   unstable/xdg-foreign/xdg-foreign-unstable-v2.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 \
-   unstable/xdg-output/xdg-output-unstable-v1.xml  
\
-   $(NULL)
-
-stable_protocols = 
\
-   stable/presentation-time/presentation-time.xml  
\
-   stable/viewporter/viewporter.xml
\
-   $(NULL)
-
-nobase_dist_pkgdata_DATA = 
\
-   $(unstable_protocols)   
\
-   $(stable_protocols) 
\
-   $(NULL)
-
-dist_noinst_DATA = 
\
-   $(sort $(foreach p,$(unstable_protocols),$(dir $p)README))  
\
-   $(sort $(foreach p,$(stable_protocols),$(dir $p)README))
\
-   $(NULL)
-
-noarch_pkgconfig_DATA = wayland-protocols.pc
-
-dist_check_SCRIPTS = tests/scan.sh
-
-TESTS = $(unstable_protocols) $(stable_protocols)
-TEST_EXTENSIONS = .xml
-AM_TESTS_ENVIRONMENT = SCANNER='$(wayland_scanner)'; export SCANNER;
-XML_LOG_COMPILER = $(srcdir)/tests/scan.sh
diff --git a/configure.ac b/configure.ac
deleted file mode 100644
index 39d54a9..000
--- a/configure.ac
+++ /dev/null
@@ -1,45 +0,0 @@
-AC_PREREQ([2.64])
-
-m4_define([wayland_protocols_major_version], [1])
-m4_define([wayland_protocols_minor_version], [11])
-m4_define([wayland_protocols_version],
-  [wayland_protocols_major_version.wayland_protocols_minor_version])
-
-AC_INIT([wayland-protocols],
-[wayland_protocols_version],
-
[https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland=wayland=unspecified],
-[wayland-protocols],
-[http://wayland.freedesktop.org/])
-
-AC_CONFIG_MACRO_DIR([m4])
-
-AC_SUBST([WAYLAND_PROTOCOLS_VERSION], [wayland_protocols_version])
-
-AC_ARG_VAR([wayland_scanner], [The wayland-scanner executable])
-AC_PATH_PROG([wayland_scanner], [wayland-scanner])
-if test x$wayland_scanner = x; then
-if test "x$cross_compiling" != "xyes"; then
-PKG_CHECK_MODULES(WAYLAND_SCANNER, [wayland-scanner])
-wayland_scanner=`$PKG_CONFIG --variable=wayland_scanner 
wayland-scanner`
-else
-AC_MSG_WARN([You are cross compiling without wayland-scanner 
in your path.  make check will fail.])
-fi
-fi
-
-AM_INIT_AUTOMAKE([1.11 foreign no-dist-gzip dist-xz tar-ustar])
-
-AM_SILENT_RULES([yes])
-
-PKG_NOARCH_INSTALLDIR
-
-AC_CONFIG_FILES([
-   Makefile
-   wayland-protocols.pc
-   wayland-protocols-uninstalled.pc
-   ])
-AC_OUTPUT
-
-AC_MSG_RESULT([
-   Version ${WAYLAND_PROTOCOLS_VERSION}
-   Prefix  ${prefix}
- 

[PATCH wayland-protocols 2/3] tests: Add compile tests

[Jonas Ådahl]

Only tested by the meson build system.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 tests/build-cxx.cc.in | 12 +++
 tests/build-pedantic.c.in | 10 ++
 tests/meson.build | 86 +++
 tests/replace.py  | 23 +
 4 files changed, 131 insertions(+)
 create mode 100644 tests/build-cxx.cc.in
 create mode 100644 tests/build-pedantic.c.in
 create mode 100755 tests/replace.py

diff --git a/tests/build-cxx.cc.in b/tests/build-cxx.cc.in
new file mode 100644
index 000..e92b155
--- /dev/null
+++ b/tests/build-cxx.cc.in
@@ -0,0 +1,12 @@
+#include "@PROTOCOL_CLIENT_INCLUDE_FILE@"
+#include "@PROTOCOL_SERVER_INCLUDE_FILE@"
+
+/* This is a build-test only */
+
+using namespace std;
+
+int
+main(int argc, char **argv)
+{
+   return 0;
+}
diff --git a/tests/build-pedantic.c.in b/tests/build-pedantic.c.in
new file mode 100644
index 000..51dfeac
--- /dev/null
+++ b/tests/build-pedantic.c.in
@@ -0,0 +1,10 @@
+#include "@PROTOCOL_CLIENT_INCLUDE_FILE@"
+#include "@PROTOCOL_SERVER_INCLUDE_FILE@"
+
+/* This is a build-test only */
+
+int
+main(int argc, char **argv)
+{
+   return 0;
+}
diff --git a/tests/meson.build b/tests/meson.build
index 267a36a..8113ab9 100644
--- a/tests/meson.build
+++ b/tests/meson.build
@@ -1,5 +1,7 @@
 scan_sh = find_program('scan.sh')
 wayland_scanner = find_program('wayland-scanner')
+libwayland = [dependency('wayland-client'),
+  dependency('wayland-server')]
 
 # Check that each protocol passes through the scanner
 foreach protocol : protocols
@@ -11,3 +13,87 @@ foreach protocol : protocols
  'SCANNER=@0@'.format(wayland_scanner.path()),
])
 endforeach
+
+# Check buildability
+
+add_languages('c', 'cpp')
+replace = find_program('replace.py')
+
+foreach protocol : protocols
+  protocol_path = join_paths(meson.source_root(), protocol)
+  protocol_components = protocol.split('/')
+  stability = protocol_components[0]
+  protocol_name = protocol_components[1]
+  xml_file = protocol_components[2]
+  xml_components = xml_file.split('.')
+  protocol_base_file_name = xml_components[0]
+
+  protocol_path = join_paths(meson.source_root(), protocol)
+  client_header_path = '@0@-client.h'.format(protocol_base_file_name)
+  server_header_path = '@0@-server.h'.format(protocol_base_file_name)
+  code_path = '@0@-code.c'.format(protocol_base_file_name)
+  client_header = custom_target(client_header_path,
+output: client_header_path,
+input: protocol_path,
+command: [ wayland_scanner, 'client-header',
+   '@INPUT@', '@OUTPUT@' ],
+install: false)
+  server_header = custom_target(server_header_path,
+output: server_header_path,
+input: protocol_path,
+command: [ wayland_scanner, 'server-header',
+   '@INPUT@', '@OUTPUT@' ],
+install: false)
+  code = custom_target(code_path,
+   output: code_path,
+   input: protocol_path,
+   command: [ wayland_scanner, 'code',
+  '@INPUT@', '@OUTPUT@' ],
+   install: false)
+
+  replace_command = [ replace, '@INPUT@', '@OUTPUT@',
+  'PROTOCOL_CLIENT_INCLUDE_FILE', 
client_header.full_path(),
+  'PROTOCOL_SERVER_INCLUDE_FILE', 
server_header.full_path(),
+]
+
+  # Check that header can be included by a pedantic C99 compiler
+  test_name = 'test-build-pedantic-@0@'.format(protocol.underscorify())
+  test_name_source = '@0@.c'.format(test_name)
+  test_source = custom_target(test_name_source,
+  input: 'build-pedantic.c.in',
+  output: test_name_source,
+  command: replace_command)
+  pedantic_test_executable = executable(test_name,
+[ test_source,
+  client_header,
+  server_header,
+  code ],
+dependencies: libwayland,
+c_args: [ '-std=c99',
+  '-pedantic',
+  '-Wall',
+  '-Werror' ],
+install: false)
+  test(test_name, pedantic_test_executable)
+
+  # Check that the header
+  if not protocol.contains('xdg-foreign-unstable-v1')
+test_name = 'test-build-cxx-@0@'.format(protocol.underscorify())
+  

Re: [PATCH] xdg-foreign-v2: Fix various documentation issues from the API change

[Jonas Ådahl]

Sorry again. I've been traveling for a bit more than two weeks, so time
has been extra limited recently. It's pushed now however, and 1.11 is
released.


Jonas

On Tue, Oct 10, 2017 at 01:16:09PM +0200, Marco Martin wrote:
> sorry i'm insisting on this.. what is still needed for those? can then
> be pushed?
> 
> --
> Marco Martin
> 
> On Mon, Oct 2, 2017 at 2:55 PM, Marco Martin <notm...@gmail.com> wrote:
> > ping? shouldn't the 3 patches in total be pushed now?
> >
> > --
> > Marco Martin
> >
> > On Tue, Sep 26, 2017 at 3:53 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> >> It stilled referred to the removed requests, so change those places to
> >> refer to the renamed ones.
> >>
> >> While at it, also change documentation to refer directly to
> >> xdg_toplevel, as that has now been introduced.
> >>
> >> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> >> ---
> >>
> >> Hi,
> >>
> >> On Tue, Sep 26, 2017 at 03:06:05PM +0200, Marco Martin wrote:
> >>> ping?
> >>>
> >>
> >> The API change looks good to me, but the documentation was left
> >> unchanged, thus incorrect. I fixed it in this patch. Please take a look.
> >>
> >> Locally I did some minor commit message changes to your patches. For
> >> example I changed the commit message to say 'xdg-foreign' not just
> >> 'foreign', as well as some minor similar cosmetic issues.
> >>
> >>
> >> Jonas
> >>
> >>
> >>
> >>
> >>  unstable/xdg-foreign/xdg-foreign-unstable-v2.xml | 30 
> >> 
> >>  1 file changed, 15 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml 
> >> b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
> >> index 8e824c1..bf46fa8 100644
> >> --- a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
> >> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
> >> @@ -32,12 +32,12 @@
> >>  some of its own surface above the other clients surface.
> >>
> >>  In order for a client A to get a reference of a surface of client B, 
> >> client
> >> -B must first export its surface using xdg_exporter.export. Upon doing 
> >> this,
> >> -client B will receive a handle (a unique string) that it may share 
> >> with
> >> -client A in some way (for example D-Bus). After client A has received 
> >> the
> >> -handle from client B, it may use xdg_importer.import to create a 
> >> reference
> >> -to the surface client B just exported. See the corresponding requests 
> >> for
> >> -details.
> >> +B must first export its surface using xdg_exporter.export_toplevel. 
> >> Upon
> >> +doing this, client B will receive a handle (a unique string) that it 
> >> may
> >> +share with client A in some way (for example D-Bus). After client A 
> >> has
> >> +received the handle from client B, it may use 
> >> xdg_importer.import_toplevel
> >> +to create a reference to the surface client B just exported. See the
> >> +corresponding requests for details.
> >>
> >>  A possible use case for this is out-of-process dialogs. For example 
> >> when a
> >>  sandboxed client without file system access needs the user to select 
> >> a file
> >> @@ -77,8 +77,8 @@
> >> corresponding interface and event for details.
> >>
> >> A surface may be exported multiple times, and each exported handle 
> >> may
> >> -   be used to create a xdg_imported multiple times. Only xdg_surface
> >> -   surfaces may be exported.
> >> +   be used to create a xdg_imported multiple times. Only xdg_toplevel
> >> +   equivalent surfaces may be exported.
> >>
> >> >>summary="the new xdg_exported object"/>
> >> @@ -104,8 +104,8 @@
> >>  
> >>
> >> The import_toplevel request imports a surface from any client 
> >> given a handle
> >> -   retrieved by exporting said surface using xdg_exporter.export. When
> >> -   called, a new xdg_imported object will be created. This new object
> >> +   retrieved by exporting said surface using 
> >> xdg_exporter.export_toplevel.
> >> +   When called, a new xd

[ANNOUNCE] wayland-protocols 1.11

[Jonas Ådahl]

wayland-protocols 1.11 is now available.

This version includes a new unstable version of the xdg-foreign protocol. The
new version fixes C++ incompatibility issues while making the interface request
naming a bit more descriptive.


Here is the shortlog:

Jonas Ådahl (1):
  configure.ac: Bump version to 1.11

Marco Martin (2):
  Add a new version of the xdg-foreign protocol
  xdg-foreign-v2: Rename export and import calls

Tomek Bury (1):
  Use sysroot prefix for pkgdatadir variable

git tag: 1.11

http://wayland.freedesktop.org/releases/wayland-protocols-1.11.tar.xz
MD5:  8d0338556d77ad86d7fca84ff086af88  wayland-protocols-1.11.tar.xz
SHA1: 2870a628fc0035c9932dd6475f04976bf86f2933  wayland-protocols-1.11.tar.xz
SHA256: 3afcee1d51c5b1d70b59da790c9830b354236324b19b2b7af9683bd3b7be6804  
wayland-protocols-1.11.tar.xz
PGP:  http://wayland.freedesktop.org/releases/wayland-protocols-1.11.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v3] protocol: add compositor-debug.xml

[Jonas Ådahl]

On Tue, Oct 03, 2017 at 11:45:41AM +0300, Pekka Paalanen wrote:
> On Fri, 22 Sep 2017 11:17:49 +0200
> Maniraj Devadoss  wrote:
> 
> > From: Pekka Paalanen 
> > 
> > This is a new debugging extension for non-production environments. The
> > aim is to replace all build-time choosable debug prints in the
> > compositor with runtime subscribable debug streams.
> > 
> > Signed-off-by: Pekka Paalanen 
> > Signed-off-by: Maniraj Devadoss 
> > ---
> >  Makefile.am|   1 +
> >  unstable/compositor-debug/README   |   7 ++
> >  .../compositor-debug-unstable-v1.xml   | 128 
> > +
> >  3 files changed, 136 insertions(+)
> >  create mode 100644 unstable/compositor-debug/README
> >  create mode 100644 
> > unstable/compositor-debug/compositor-debug-unstable-v1.xml
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index 5b5ae96..a0994d1 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -15,6 +15,7 @@ unstable_protocols =  
> > \
> > unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml  
> > \
> > 
> > unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> >  \
> > unstable/xdg-output/xdg-output-unstable-v1.xml  
> > \
> > +   unstable/compositor-debug/compositor-debug-unstable-v1.xml  
> > \
> > $(NULL)
> >  
> >  stable_protocols = 
> > \
> > diff --git a/unstable/compositor-debug/README 
> > b/unstable/compositor-debug/README
> > new file mode 100644
> > index 000..f1a7603
> > --- /dev/null
> > +++ b/unstable/compositor-debug/README
> > @@ -0,0 +1,7 @@
> > +Compositor Debug protocol
> > +
> > +Maintainers:
> > +Pekka Paalanen 
> > +Friedrich Eugen 
> > +Ucan Emre 
> > +Maniraj Devadoss 
> > diff --git a/unstable/compositor-debug/compositor-debug-unstable-v1.xml 
> > b/unstable/compositor-debug/compositor-debug-unstable-v1.xml
> > new file mode 100644
> > index 000..b81c630
> > --- /dev/null
> > +++ b/unstable/compositor-debug/compositor-debug-unstable-v1.xml
> > @@ -0,0 +1,128 @@
> > +
> > +
> > +
> > +  
> > +Copyright © 2017 Pekka Paalanen pq at iki.fi
> 
> Hi Maniraj,
> 
> it wasn't necessary to "obfuscate" the email addresses, we don't tend
> to do that. Anyway, this patch is fine by me.
> 
> Jonas, would you like to give an Acked-by and maybe cut a
> wayland-protocols release so we have a version number for Weston to
> depend on? Or if you have anything you'd like changed?

For me this is out of scope for wayland-protocols. The idea behind
wayland-protocols is to have a place for protocols that can/should be
used between any compositor and "normal" client. So far (and my opinion
is that it will continue to be so) this has meant that things like debug
protocols (like the infamous "wl_randr" protocol) and desktop
environment components (like a generic "panel" protocol) have been out
of scope.

They may not be out of scope for Wayland as a whole (for example
wayland-wall tries to fill the hole regarding DE environment
components). I discussed this with Pekka on IRC, and for this particular
protocol, I think it makes more sense to keep it a weston extension.
Weston can however install the XML file and third party clients and
compositors can depend on it in any way they want.


Jonas

> 
> 
> Thanks,
> pq
> 
> > +
> > +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 is a generic debugging interface for the compositor 
> > internals,the global
> > +  object advertized through 

Re: [PATCH] documentation: clarify the need for wl_surface.damage

[Jonas Ådahl]

On Tue, Oct 03, 2017 at 10:02:03AM +0300, Pekka Paalanen wrote:
> On Mon,  2 Oct 2017 17:39:56 +0200
> Mahdi Khanalizadeh  wrote:
> 
> > Add an explanation for wl_surface.attach why a wl_surface.damage request
> > is necessary. Explicitly declare it implementation defined behaviour if the
> > wl_surface.damage request is omitted to give the compositor some leeway
> > on how it handles attaches.
> > 
> > Signed-off-by: Mahdi Khanalizadeh 
> > ---
> >  protocol/wayland.xml | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index aabc7ae..6f6cc11 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1365,6 +1365,11 @@
> > wl_buffer before receiving the wl_buffer.release event, the surface
> > contents become undefined immediately.
> >  
> > +   Attaching a buffer should always be accompanied by a
> > +   wl_surface.damage request to signal the compositor that the
> > +   contents of the buffer have changed. Otherwise it is implementation
> > +   defined whether the wl_surface.attach request has any visible effect.
> 
> Hi,
> 
> thank you for the clarification, I assume this is as a response to our
> IRC discussion.
> 
> How about phrasing it: "Attaching a buffer should always be accompanied
> by at least one wl_surface.damage request to signal the compositor
> which parts of the surface contents are changed."?
> 
> - There can be multiple damage requests to build up a complex region.
> - It's not about buffer contents, it is about surface contents.
> - We don't want to imply that you must always give full surface-sized
>   damage when the buffer is swapped.
> 
> However, most of the new paragraph are redundant with the first
> paragraph for the damage request. Could you instead add one more
> sentence to the first paragraph explaining that the compositor has no
> obligation to use the new contents outside of the given damage?

In a way, the compositor MAY be obliged to use the new content if it
didn't make a copy of the previous one. As in, it must switch to the new
buffer and send the corrpesponding wl_buffer::release events on the old
one, even if there was no damage, if the buffers are used in a zero-copy
manner. If it already made a copy, there is of course no obligation to use
the new content, as the wl_buffer::release event would probably already
be sent after having made the copy.

I don't think we should imply that it is illegal to not attach damage
anyhow, as there may be valid use cases. We should rather make it clear
that there the regular semantics are still applied (regarding use count
etc) and that it also means the the client are saying the buffers are
equal pixel by pixel.


Jonas

> 
> There is also the request damage_buffer which is otherwise the same but
> uses a different coordinate system.
> 
> > +
> > If wl_surface.attach is sent with a NULL wl_buffer, the
> > following wl_surface.commit will remove the surface content.
> >
> 
> Thanks,
> pq



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

[PATCH] xdg-foreign-v2: Fix various documentation issues from the API change

[Jonas Ådahl]

It stilled referred to the removed requests, so change those places to
refer to the renamed ones.

While at it, also change documentation to refer directly to
xdg_toplevel, as that has now been introduced.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---

Hi,

On Tue, Sep 26, 2017 at 03:06:05PM +0200, Marco Martin wrote:
> ping?
> 

The API change looks good to me, but the documentation was left
unchanged, thus incorrect. I fixed it in this patch. Please take a look.

Locally I did some minor commit message changes to your patches. For
example I changed the commit message to say 'xdg-foreign' not just
'foreign', as well as some minor similar cosmetic issues.


Jonas




 unstable/xdg-foreign/xdg-foreign-unstable-v2.xml | 30 
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml 
b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
index 8e824c1..bf46fa8 100644
--- a/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
+++ b/unstable/xdg-foreign/xdg-foreign-unstable-v2.xml
@@ -32,12 +32,12 @@
 some of its own surface above the other clients surface.
 
 In order for a client A to get a reference of a surface of client B, client
-B must first export its surface using xdg_exporter.export. Upon doing this,
-client B will receive a handle (a unique string) that it may share with
-client A in some way (for example D-Bus). After client A has received the
-handle from client B, it may use xdg_importer.import to create a reference
-to the surface client B just exported. See the corresponding requests for
-details.
+B must first export its surface using xdg_exporter.export_toplevel. Upon
+doing this, client B will receive a handle (a unique string) that it may
+share with client A in some way (for example D-Bus). After client A has
+received the handle from client B, it may use xdg_importer.import_toplevel
+to create a reference to the surface client B just exported. See the
+corresponding requests for details.
 
 A possible use case for this is out-of-process dialogs. For example when a
 sandboxed client without file system access needs the user to select a file
@@ -77,8 +77,8 @@
corresponding interface and event for details.
 
A surface may be exported multiple times, and each exported handle may
-   be used to create a xdg_imported multiple times. Only xdg_surface
-   surfaces may be exported.
+   be used to create a xdg_imported multiple times. Only xdg_toplevel
+   equivalent surfaces may be exported.
   
   
@@ -104,8 +104,8 @@
 
   
The import_toplevel request imports a surface from any client given a 
handle
-   retrieved by exporting said surface using xdg_exporter.export. When
-   called, a new xdg_imported object will be created. This new object
+   retrieved by exporting said surface using xdg_exporter.export_toplevel.
+   When called, a new xdg_imported object will be created. This new object
represents the imported surface, and the importing client can
manipulate its relationship using it. See xdg_imported for details.
   
@@ -136,8 +136,8 @@
   
The handle event contains the unique handle of this exported surface
reference. It may be shared with any client, which then can use it to
-   import the surface by calling xdg_importer.import. A handle may be
-   used to import the surface multiple times.
+   import the surface by calling xdg_importer.import_toplevel. A handle
+   may be used to import the surface multiple times.
   
   
 
@@ -161,9 +161,9 @@
 
   
Set the imported surface as the parent of some surface of the client.
-   The passed surface must be a toplevel xdg_surface. Calling this function
-   sets up a surface to surface relation with the same stacking and 
positioning
-   semantics as xdg_surface.set_parent.
+   The passed surface must be a xdg_toplevel equivalent. Calling this
+   function sets up a surface to surface relation with the same stacking
+   and positioning semantics as xdg_toplevel.set_parent.
   
   
-- 
2.13.5

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

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Jonas Ådahl]

On Tue, Sep 12, 2017 at 08:44:39PM +0200, Marco Martin wrote:
> On Tue, Aug 22, 2017 at 6:07 PM, Marco Martin  wrote:
> >> You'll need to create an "unstable v2" version, as this is a
> >> non-backward compatible change. To do that, copy the XML file, changing
> >
> > attached a patch that adds the new v2 file, comments adressed
> 
> ping? do i still need to do something on it?

Thanks for the ping, and sorry about the delay. The change to the
protocol looks good to me, I only have three things to comment on:

In general, it's a good idea to first copy (and maybe bump the numbers
as you did), then in a follow up commit make the changes to the
protocol. That would make it possible to review the actual changes,
without having to compare manually.

The other thing is that you also need to add the new file to
Makefile.am, so that it'll be installed properly.

And lastly, the patch submission procedure we use is sending
patches to the E-mail list directly, not as attachments. You can do this
for example with git-send-email.


Jonas

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

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Jonas Ådahl]

On Thu, Aug 17, 2017 at 05:05:35PM +0200, Marco Martin wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> >
> > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the 
> > only
> > thing we allow exporting anyway) seems fine to me. The "import" request
> > should be renamed in a similar manner as well then.
> 
> here attached a patch to rename the calls to export_toplevel and
> import_toplevel, is that ok?

You'll need to create an "unstable v2" version, as this is a
non-backward compatible change. To do that, copy the XML file, changing
the v1 to v2 - then make the change. Some comments inline below too:

> 
> --
> Marco Martin

> From 79a050a0a22cb9f04d7679fe2fcd28e797e6957c Mon Sep 17 00:00:00 2001
> From: Marco Martin <notm...@gmail.com>
> Date: Thu, 17 Aug 2017 16:58:33 +0200
> Subject: [PATCH] rename export and import calls
> 
> as export is a reserved keyword in C++, in order for the
> output generated by wayland_scanner to compile correctly
> rename export to export_toplevel and import to import_toplevel
> 
> Signed-off-by: Marco Martin <notm...@gmail.com>
> ---
>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml 
> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> index 062b090..6d5e1f1 100644
> --- a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -69,7 +69,7 @@
>
>  
>  
> -
> +

Would be good to adapt the text below (and in import too) to reflect
this change.


Jonas

>
>   The export request exports the passed surface so that it can later be
>   imported via xdg_importer. When called, a new xdg_exported object will
> @@ -101,7 +101,7 @@
>
>  
>  
> -
> +
>
>   The import request imports a surface from any client given a handle
>   retrieved by exporting said surface using xdg_exporter.export. When
> -- 
> 2.7.4
> 

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

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Jonas Ådahl]

On Thu, Aug 10, 2017 at 10:44:30AM +0200, Marco Martin wrote:
> On Thu, Aug 10, 2017 at 3:47 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> > On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
> >> On Wednesday 27 July 2016 15:54:58 Jonas Ĺdahl wrote:
> >> > xdg-foreign is a protocol meant to enable setting up inter surface
> >> > relationships across clients. Potential use cases are out-of-process
> >> > dialogs, such as file dialogs, meant to be used by sandboxed processes
> >> > that may not have the access it needs to implement such dialogs.
> >>
> >> a quick feedback while trying on implementing it in kde side.
> >> since we use c++, the file generated by wayland-scanner, won't compile due 
> >> to
> >> the request called "export" which is a reserved keyword in c++11.
> >> could the request be renamed to something else, even just a bit more 
> >> redundant
> >> as export_surface which would be safer as compilers are concerned?
> >
> > Ah. Would make sense with a test case for this in wayland-scanner I'd
> > say, so we don't add other things that would make it not compile with a
> > c++ compiler.
> >
> > Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the 
> > only
> > thing we allow exporting anyway) seems fine to me. The "import" request
> > should be renamed in a similar manner as well then.
> >
> 
> yeah, export_toplevel/import_toplevel sounds good.
> if there is a continuous integration somewhere, could be nice just
> make it try compiling the file resulting from wayland-scanner with g++
> -std=c++14 or something like that

There is a very tiny test suite in wayland-protocols. It could be
extended to test build for various variants of C and C++. Currently it
just tests that wayland-scanner doesn't complain.


Jonas

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

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Jonas Ådahl]

On Wed, Aug 09, 2017 at 01:42:51PM +0200, Marco Martin wrote:
> On Wednesday 27 July 2016 15:54:58 Jonas Ådahl wrote:
> > xdg-foreign is a protocol meant to enable setting up inter surface
> > relationships across clients. Potential use cases are out-of-process
> > dialogs, such as file dialogs, meant to be used by sandboxed processes
> > that may not have the access it needs to implement such dialogs.
> 
> a quick feedback while trying on implementing it in kde side.
> since we use c++, the file generated by wayland-scanner, won't compile due to 
> the request called "export" which is a reserved keyword in c++11.
> could the request be renamed to something else, even just a bit more 
> redundant 
> as export_surface which would be safer as compilers are concerned?

Ah. Would make sense with a test case for this in wayland-scanner I'd
say, so we don't add other things that would make it not compile with a
c++ compiler.

Anyhow, "export_surface" or maybe even "export_toplevel" (as that is the only
thing we allow exporting anyway) seems fine to me. The "import" request
should be renamed in a similar manner as well then.


Jonas

> 
> -- 
> Marco Martin
> ___
> 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: [PATCH] libweston-desktop: add signals for title, app_id

[Jonas Ådahl]

On Tue, Aug 08, 2017 at 09:13:42AM -0500, Matt Hoosier wrote:
> On Sun, Aug 6, 2017 at 11:11 PM, Jonas Ådahl <jad...@gmail.com> wrote:

... snip ...

> 
> Okay. Well, I'm not sure how you'd like this to proceed. Are you planning
> to update the spec to require that set_title and set_app_id are buffered?
> Or is that too much effort and you'd rather than libweston-desktop just
> gets a patch like what I proposed to allow the state-change to become
> visible when it arrives?

The patch looks fine to me. This discussion was really about whether to
change the next protocol version. The patch you provided is correct for
the versions implemented in libweston-desktop.


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

Re: [PATCH] libweston-desktop: add signals for title, app_id

[Jonas Ådahl]

On Tue, Jul 25, 2017 at 08:07:01AM -0600, Matt Hoosier wrote:
> On Tue, Jul 25, 2017 at 7:26 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > On Tue, Jul 25, 2017 at 06:42:34AM -0600, Matt Hoosier wrote:
> > > I'd find it a little bit inconvenient for the title, class, and app-id to
> > > be treated as buffered state. They make a great poor-man's way of
> > > identifying surfaces for embedded systems that implement simple layer
> > > management policies without wholesale adopting IVI shell (whose lack of
> > > wl_shell makes it difficult to integrate off-the-rack Wayland libraries
> > and
> > > apps). Since the surface title doesn't have anything to do with correct
> > > graphical presentation, it'd be nicer if that data is just available
> > > immediately to the rest of the shell rather than being something that
> > only
> > > trickles in whenever the app happens to post a buffer next.
> >
> > There is no need to attach a new buffer to commit a new state. One could
> > for example commit a state only changing the title and nothing else, and
> > it'd be completely correct. The benefit of synchronizing it is for
> > example that a shell can synchronously change some overlay with the
> > content.
> >
> 
> Yes, agreed. But that's not the way that the Wayland backends of big
> programming frameworks like Qt, Gtk+, etc work. In practice, you need to
> trigger rendering if you want a commit to happen.

Toolkits could make this work (i.e. just call wl_surface_commit() after
setting the title), I'm sure of, but indeed it could complicate things,
as they need to make sure not to set any pending state too early. For
example gtk did this poorly before, but has since been improved.

Not sure this slight complication is a reason to not apply the title on
commit though.

> 
> 
> >
> > Regarding the app_id, the app_id should normally only ever be set once,
> > as part of the initial state that doesn't have a buffer attached yet.
> >
> 
> That's a fair point. The title can still change at will though, can't it?

Yes it can.

> Isn't the regular old window title what gets used to show things like the
> working directly in an xterm or the name of the currently-edited document
> in a word processor?

Right. The potential purpose of making set_title etc be applied on
commit would be to update for example the window title text in the gnome
shell overview (or any equivalent presentation) at the exact same time
as the content of the document is updated.


Jonas

> 
> 
> >
> >
> > Jonas
> >
> > >
> > > On Tue, Jul 25, 2017 at 12:17 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> > >
> > > > On Fri, Jul 21, 2017 at 05:21:38PM +0200, Quentin Glidic wrote:
> > > > > On 7/20/17 4:33 PM, Matt Hoosier wrote:
> > > > > > It's useful for the shell implementation to know when these change,
> > > > > > for example to relay the information on to taskbars or similar.
> > > > >
> > > > > The idea is good, we need something like that. (But maybe not, see
> > > > below).
> > > > >
> > > > >
> > > > > > To avoid ABI changes or the need to make the weston_desktop_surface
> > > > > > definition public, new functions are introduced for attaching
> > > > > > listeners to these signals.
> > > > >
> > > > > We don’t care that much about ABI changes, but you’re right that I do
> > > > care
> > > > > about the struct staying private.
> > > > >
> > > > >
> > > > > > Signed-off-by: Matt Hoosier <matt.hoos...@gmail.com>
> > > > > > ---
> > > > > >   libweston-desktop/libweston-desktop.h |  6 ++
> > > > > >   libweston-desktop/surface.c   | 21 +
> > > > > >   2 files changed, 27 insertions(+)
> > > > > >
> > > > > > diff --git a/libweston-desktop/libweston-desktop.h
> > > > b/libweston-desktop/libweston-desktop.h
> > > > > > index 03b04c7..e38257e 100644
> > > > > > --- a/libweston-desktop/libweston-desktop.h
> > > > > > +++ b/libweston-desktop/libweston-desktop.h
> > > > > > @@ -164,6 +164,12 @@ weston_desktop_surface_set_size(struct
> > > > weston_desktop_surface *surface,
> > > > > > int32_t width, int32_t height);
> > > > > >   void
> > > > > >   weston_desktop_surface_close(stru

Re: [RFC PATCH wayland] protocol: add wl_pointer's axis relative physical direction

[Jonas Ådahl]

On Tue, Aug 01, 2017 at 11:35:55AM +0100, Peter Hutterer wrote:
> This event adds the physical direction of the axis motion, relative to the
> axis event we get. Right now, when natural scrolling is enabled things like
> volume sliders move the wrong way round.
> 
> By adding the axis motion direction, we can have toolkits swap the scroll
> direction for applicable widgets, getting the right behavior on all widgets.
> 
> Signed-off-by: Peter Hutterer 
> ---
>  protocol/wayland.xml | 76 
> ++--
>  1 file changed, 68 insertions(+), 8 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 29b63be..4c58589 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1651,7 +1651,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1760,7 +1760,7 @@
>  
>
>  
> -  
> +  
>  
>The wl_pointer interface represents one or more input devices,
>such as mice, which control the pointer location and pointer_focus
> @@ -2022,8 +2022,9 @@
>   axis event sequence, no event is sent.
>   Only one wl_pointer.axis_source event is permitted per frame.
>  
> - The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
> - not guaranteed.
> + The order of wl_pointer.axis_relative_direction,
> + wl_pointer.axis_discrete and wl_pointer.axis_source is not
> + guaranteed.
>
>
>  
> @@ -2075,15 +2076,74 @@
>   The axis number is identical to the axis number in the associated
>   axis event.
>  
> - The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
> - not guaranteed.
> + The order of wl_pointer.axis_relative_direction,
> + wl_pointer.axis_discrete and wl_pointer.axis_source is not
> + guaranteed.
>
>
>
>  
> +
> +
> +
> +  
> + This specifies the direction of the physical motion that caused a
> +wl_pointer.axis event, relative to the wl_pointer.axis direction.
> +  
> +   +  summary="physical motion matches axis direction"/>
> +   +  summary="physical motion is the inverse of the axis direction"/>
> +
> +
> +
> +  
> + Relative directional information of the entity causing the axis
> + motion.
> +
> + For a wl_pointer.axis event, the wl_pointer.axis_relative_direction
> + event specifies the movement direction of the entity causing the
> + wl_pointer.axis event. For example:
> + - if a user's fingers on a touchpad move down and this
> +   causes a wl_pointer.axis vertical_scroll down event, the physical
> +   direction is 'identical'
> +  - if a user's fingers on a touchpad move down and this causes a
> +   wl_pointer.axis vertical_scroll up scroll up event ('natural
> +   scrolling'), the physical direction is 'parallel'.

I guess you mean inverted here.

> +
> + A client may use this information to adjust scroll motion of
> + components. Specifically, enabling natural scrolling causes the
> + content to change direction compared to traditional scrolling.
> + Some widgets like volume control sliders should match the physical

Could loosen up the wording here I guess, and say "may want to" as this
should be no UI designing guideline.

> + direction regardless of whether natural scrolling is active.
> + This event enables clients to match the scroll direction of a widget
> + to the physical direction.
> +
> + This event does not occur on its own, it is coupled with a
> + wl_pointer.axis event that represents this axis value.
> + The protocol guarantees that each axis_relative_direction event is
> + always followed by exactly one axis event with the same
> + axis number within the same wl_pointer.frame. Note that the protocol
> + allows for other events to occur between the axis_relative_direction
> + and its coupled axis event.
> +
> + This event is optional, when not present a client should assume a
> + relative direction of 'identical'.

I think we discussed this offline, but for the record one point
regarding this paragraph is leaving this undefined in a "should not make
any physical direction assumptions" kind of way.

Otherwise, I think this makes sense.

(There are also a couple of tabs vs spaces wars in this patch).


Jonas

> +
> + The axis number is identical to the axis number in the associated
> + axis event.
> +
> + The order of wl_pointer.axis_relative_direction,
> + wl_pointer.axis_discrete and wl_pointer.axis_source is not
> + guaranteed.
> +  
> +  
> +   +   summary="physical direction relative to axis motion"/>
> +
>
>  
> -  
> +  
>  
>The wl_keyboard interface represents one or more 

Re: [PATCH RFC xserver] xwayland: Add xdg-output support

[Jonas Ådahl]

On Tue, Aug 01, 2017 at 10:26:54AM +0200, Olivier Fourdan wrote:
> This was added in  wayland-protocols 1.10.
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  Note: This has not been tested with an actual compositor supporting 
> xdg-output
> 
>  configure.ac  |  2 +-
>  hw/xwayland/Makefile.am   |  9 +-
>  hw/xwayland/xwayland-output.c | 71 
> +++
>  hw/xwayland/xwayland.c|  4 +++
>  hw/xwayland/xwayland.h|  3 ++
>  meson.build   |  2 +-
>  6 files changed, 82 insertions(+), 9 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 8d3c3b55b..3a8c61f69 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2353,7 +2353,7 @@ AM_CONDITIONAL(XEPHYR, [test "x$KDRIVE" = xyes && test 
> "x$XEPHYR" = xyes])
>  
>  dnl Xwayland DDX
>  
> -XWAYLANDMODULES="wayland-client >= 1.3.0 wayland-protocols >= 1.9 $LIBDRM 
> epoxy"
> +XWAYLANDMODULES="wayland-client >= 1.3.0 wayland-protocols >= 1.10 $LIBDRM 
> epoxy"
>  if test "x$XF86VIDMODE" = xyes; then
>   XWAYLANDMODULES="$XWAYLANDMODULES $VIDMODEPROTO"
>  fi
> diff --git a/hw/xwayland/Makefile.am b/hw/xwayland/Makefile.am
> index c14b95b7c..a1eee3e8e 100644
> --- a/hw/xwayland/Makefile.am
> +++ b/hw/xwayland/Makefile.am
> @@ -59,7 +59,10 @@ Xwayland_built_sources +=  
> \
>   tablet-unstable-v2-client-protocol.h\
>   tablet-unstable-v2-protocol.c   \
>   xwayland-keyboard-grab-unstable-v1-protocol.c   \
> - xwayland-keyboard-grab-unstable-v1-client-protocol.h
> + xwayland-keyboard-grab-unstable-v1-client-protocol.h\
> + xdg-output-unstable-v1-protocol.c   \
> + xdg-output-unstable-v1-client-protocol.h
> +
>  
>  nodist_Xwayland_SOURCES = $(Xwayland_built_sources)
>  CLEANFILES = $(Xwayland_built_sources)
> @@ -89,6 +92,10 @@ xwayland-keyboard-grab-unstable-v1-protocol.c : 
> $(WAYLAND_PROTOCOLS_DATADIR)/uns
>   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
>  xwayland-keyboard-grab-unstable-v1-client-protocol.h : 
> $(WAYLAND_PROTOCOLS_DATADIR)/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml
>   $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
> +xdg-output-unstable-v1-protocol.c : 
> $(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
> + $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
> +xdg-output-unstable-v1-client-protocol.h : 
> $(WAYLAND_PROTOCOLS_DATADIR)/unstable/xdg-output/xdg-output-unstable-v1.xml
> + $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
>  
>  %-protocol.c : %.xml
>   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
> diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c
> index 460caaf56..1f3eb4f59 100644
> --- a/hw/xwayland/xwayland-output.c
> +++ b/hw/xwayland/xwayland-output.c
> @@ -93,9 +93,12 @@ output_handle_geometry(void *data, struct wl_output 
> *wl_output, int x, int y,
>  physical_width, physical_height);
>  RROutputSetSubpixelOrder(xwl_output->randr_output,
>   wl_subpixel_to_xrandr(subpixel));
> -xwl_output->x = x;
> -xwl_output->y = y;
>  
> +/* Apply the change from wl_output only if xdg-output is not supported */
> +if (!xwl_output->xdg_output) {
> +xwl_output->x = x;
> +xwl_output->y = y;
> +}
>  xwl_output->rotation = wl_transform_to_xrandr(transform);
>  }
>  
> @@ -108,8 +111,11 @@ output_handle_mode(void *data, struct wl_output 
> *wl_output, uint32_t flags,
>  if (!(flags & WL_OUTPUT_MODE_CURRENT))
>  return;
>  
> -xwl_output->width = width;
> -xwl_output->height = height;
> +/* Apply the change from wl_output only if xdg-output is not supported */
> +if (!xwl_output->xdg_output) {
> +xwl_output->width = width;
> +xwl_output->height = height;
> +}
>  xwl_output->refresh = refresh;
>  }
>  
> @@ -200,10 +206,10 @@ update_screen_size(struct xwl_output *xwl_output, int 
> width, int height)
>  }
>  
>  static void
> -output_handle_done(void *data, struct wl_output *wl_output)
> +apply_output_change(struct xwl_output *xwl_output)
>  {
> -struct xwl_output *it, *xwl_output = data;
>  struct xwl_screen *xwl_screen = xwl_output->xwl_screen;
> +struct xwl_output *it;
>  int width = 0, height = 0, has_this_output = 0;
>  RRModePtr randr_mode;
>  
> @@ -238,6 +244,16 @@ output_handle_done(void *data, struct wl_output 
> *wl_output)
>  }
>  
>  static void
> +output_handle_done(void *data, struct wl_output *wl_output)
> +{
> +struct xwl_output *xwl_output = data;
> +
> +/* Apply the change from wl_output only if xdg-output is not supported */
> +if (!xwl_output->xdg_output)
> +apply_output_change(xwl_output);
> +}
> +
> +static void
>  output_handle_scale(void *data, struct wl_output 

[ANNOUNCE] wayland-protocols 1.10

[Jonas Ådahl]

wayland-protocols 1.10 is now available.

This version introduces one new unstable protocol:

 - xdg-output - a protocol meant for providing desktop centric concepts related
   to output and monitors to clients. It's for example intended to be used by
   Xwayland to be able to layout outputs on a logical pixel grid.


Here is the shortlog:

Jonas Ådahl (1):
  configure.ac: Bump version to 1.10

Olivier Fourdan (2):
  Add xdg-output protocol
  configure.ac: force autotool to use star


git tag: 1.10

http://wayland.freedesktop.org/releases/wayland-protocols-1.10.tar.xz
MD5:  84a7846c2b6a6a3e265fc9be36453e60  wayland-protocols-1.10.tar.xz
SHA1: 4f1322f03fa8b2e6467b8f71471f53eff82728a4  wayland-protocols-1.10.tar.xz
SHA256: 5719c51d7354864983171c5083e93a72ac99229e2b460c4bb10513de08839c0a  
wayland-protocols-1.10.tar.xz
PGP:  http://wayland.freedesktop.org/releases/wayland-protocols-1.10.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 wayland 2/3] scanner: Allow adding a prefix to exported symbols

[Jonas Ådahl]

On Wed, Jul 26, 2017 at 09:28:45AM +0100, Daniel Stone wrote:
> Hi,
> 
> On 25 July 2017 at 10:24, Pekka Paalanen  wrote:
> > recapping the discussion from IRC, we pretty much agreed that prefixing
> > is not a nice solution. Jonas found out that we cannot actually prefix
> > everything, because there usually are references to other protocol
> > things (like you would never want to prefix wl_surface). So it becomes
> > very hard to prefix things appropriately.
> >
> > The alternative we discussed is solving a different problem: scanner
> > makes all the public symbols in the generated .c files WL_EXPORT, which
> > makes them leak into DSO ABI, which is bad. In my opinion, it should
> > have never happened in the first place. But we missed it, and now it has
> > spread, so we cannot just fix scanner to stop exporting, the decision
> > must be with the consumers. So we need a scanner option to stop
> > exporting.
> >
> > Quentin proposed we add a scanner option
> > --visibility={static|compiler|export}. It would affect all the symbols
> > exported from the generated .c files as follows:
> >
> > - static: the symbols will be static.
> > - compiler: the symbols will get whatever the default visibility is
> >   with the compiler, i.e. not explicitly static and not exported
> > - export: the symbols are exported (this the old behaviour, and will be
> >   the default)
> >
> > Obviously, the only way to actually make use of the 'static' option is
> > for the consumer to #include the generated .c file. It's ugly, yes, but
> > it solves the conflicting symbol names issue Jonas was looking into.
> >
> > In my opinion, the prefixing approach where we still cannot prefix
> > everything in a way that one could use conflicting protocols in the
> > same compilation unit, and where e.g. the static inline functions are
> > not prefixed, is more ugly than the 'static' option.
> >
> > We are going to need an option to stop the exports anyway, and it seems
> > like we can piggyback on that solution for the problem underlying the
> > prefixing proposal as well.
> 
> This sounds really good to me.
> 
> Unfortunately, the release just went out last night without waiting
> for any of these patches (or even pinging to see what their status
> was?), so I guess we're not able to make xdg-shell stable for another
> cycle. >:(

Well, we can still, just that anyone wanting to implement it in
parallel to xdg-shell unstable v5 would have to wait.

> 
> It's either that or just merge it post-beta anyway - which I wouldn't
> actually mind to be honest.

That's an option too. I don't have any objections really.


Jonas

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

[PATCH wayland v2 1/4] scanner: Add --visibility flag for setting symbol visibility

[Jonas Ådahl]

Add a --visibility flag that enables the user to tweak the visibility
of the symbols generated by wayland-scanner. Three alternatives are
exposed:

'export': as has always been done up until now, export the symbols
using WL_EXPORT, making making them exposed externally. This is the
default in order to not break backward compatibility.

'compiler-default': use whatever visibility the compiler defaults to.
This is most likely the most visibility that protocol implementations
or users actually wants, as it doesn't expose any unwanted
implementation details.

'static': each symbol will only be visible to the compilation unit it
is included in. This means that a protocol implementations and users
needs to include both the 'code' file and either the 'client-header' or
'server-header' (or both) in the source file implementing or using the
protocol in question.

Using 'static' is a method to avoid situations where otherwise exposed
symbols of different protocols would conflict, for example if they have
the same interface name.

When no visibility is specified, 'export' is assumed, but a warning is
printed to stderr, as it is unlikely that 'export' is what is actually
desired.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---

Changes since v1:

- Use 'extern' tag also for compiler default declarations.

- "see --help" message to the warning

- Added 'what visibility to choose' kind of documentation to --help


 Makefile.am   |  10 ++---
 src/scanner.c | 135 +++---
 2 files changed, 125 insertions(+), 20 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index d0c8bd3..d570525 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -97,19 +97,19 @@ nodist_libwayland_client_la_SOURCES =   \
 pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
 
 protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport code < 
$< > $@
 
 protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
server-header < $< > $@
 
 protocol/%-client-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
client-header < $< > $@
 
 protocol/%-server-protocol-core.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header -c 
< $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
server-header -c < $< > $@
 
 protocol/%-client-protocol-core.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header -c 
< $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
client-header -c < $< > $@
 
 BUILT_SOURCES =\
$(nodist_libwayland_server_la_SOURCES)  \
diff --git a/src/scanner.c b/src/scanner.c
index 517068c..3e43f90 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -57,6 +57,12 @@ enum side {
SERVER,
 };
 
+enum visibility {
+   VISIBILITY_EXPORT,
+   VISIBILITY_COMPILER_DEFAULT,
+   VISIBILITY_STATIC
+};
+
 static int
 usage(int ret)
 {
@@ -72,7 +78,30 @@ usage(int ret)
" the scanner was built 
against.\n"
"-c,  --include-core-only include the core 
version of the headers,\n"
" that is e.g. 
wayland-client-core.h instead\n"
-   " of 
wayland-client.h.\n");
+   " of 
wayland-client.h.\n"
+   "-V,  
--visibility=[export|compiler-default|static]\n"
+   " select what type of 
visibility protocol\n"
+   " symbols should have. 
'export' will cause the\n"
+   " symbols to be 
exported, 'compiler-default'\n"
+   " will use the compiler 
default (often visible\n"
+   " only within the same 
DSO), 'static' will make\n"
+   " all symbols static 
(note that the fi

[PATCH wayland v2 2/4] tests: Test static symbol visibility

[Jonas Ådahl]

Test that it is possible to inline the protocol 'code' file generated
by wayland-scanner in the source code files using it.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---

Changes since v1: none.


 .gitignore|   5 ++
 Makefile.am   |  32 -
 tests/data/tiny.xml   |  38 ++
 tests/static-symbol-test-client.c |  78 
 tests/static-symbol-test-server.c | 147 ++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 tests/data/tiny.xml
 create mode 100644 tests/static-symbol-test-client.c
 create mode 100644 tests/static-symbol-test-server.c

diff --git a/.gitignore b/.gitignore
index 8da9861..553ffd0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,3 +45,8 @@ exec-fd-leak-checker
 fixed-benchmark
 /wayland-scanner
 protocol/*.[ch]
+static-tiny-protocol.inc
+static-tiny-server-protocol-core.h
+static-tiny-client-protocol-core.h
+static-symbol-test-server
+static-symbol-test-client
diff --git a/Makefile.am b/Makefile.am
index d570525..bbd5107 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -114,7 +114,10 @@ protocol/%-client-protocol-core.h : 
$(top_srcdir)/protocol/%.xml
 BUILT_SOURCES =\
$(nodist_libwayland_server_la_SOURCES)  \
$(nodist_libwayland_client_la_SOURCES)  \
-   $(nodist_headers_test_SOURCES)
+   $(nodist_headers_test_SOURCES)  \
+   $(nodist_static_symbol_test_server_SOURCES) \
+   $(nodist_static_symbol_test_client_SOURCES) \
+   static-tiny-protocol.inc
 
 CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db
 DISTCLEANFILES = src/wayland-version.h
@@ -164,7 +167,11 @@ built_test_programs =  \
message-test\
headers-test\
compositor-introspection-test   \
-   protocol-logger-test
+   protocol-logger-test\
+   static-symbol-test-server
+
+built_test_program_helpers =   \
+   static-symbol-test-client
 
 if ENABLE_CPP_TEST
 built_test_programs += cpp-compile-test
@@ -172,6 +179,7 @@ endif
 
 AM_TESTS_ENVIRONMENT = \
export WAYLAND_SCANNER='$(top_builddir)/wayland-scanner'\
+   export TOP_BUILDDIR='$(top_builddir)'   \
TEST_DATA_DIR='$(top_srcdir)/tests/data'\
TEST_OUTPUT_DIR='$(top_builddir)/tests/output'  \
SED=$(SED)  \
@@ -182,6 +190,7 @@ TESTS = $(built_test_programs)  \
 
 noinst_PROGRAMS =  \
$(built_test_programs)  \
+   $(built_test_program_helpers)   \
exec-fd-leak-checker\
fixed-benchmark
 
@@ -200,6 +209,14 @@ libtest_runner_la_LIBADD = \
libwayland-server.la\
-lrt -ldl $(FFI_LIBS)
 
+static-tiny-protocol.inc : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic code $< $@
+
+static-tiny-server-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic server-header $< $@
+
+static-tiny-client-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic client-header $< $@
 
 array_test_SOURCES = tests/array-test.c
 array_test_LDADD = libtest-runner.la
@@ -245,6 +262,14 @@ headers_test_LDADD = libtest-runner.la
 nodist_headers_test_SOURCES =  \
protocol/wayland-server-protocol-core.h \
protocol/wayland-client-protocol-core.h
+static_symbol_test_server_SOURCES = tests/static-symbol-test-server.c
+nodist_static_symbol_test_server_SOURCES = \
+   static-tiny-server-protocol-core.h
+static_symbol_test_server_LDADD = libtest-runner.la
+static_symbol_test_client_SOURCES = tests/static-symbol-test-client.c
+nodist_static_symbol_test_client_SOURCES = \
+   static-tiny-client-protocol-core.h
+static_symbol_test_client_LDADD = libtest-runner.la
 
 if ENABLE_CPP_TEST
 cpp_compile_test_SOURCES = tests/cpp-compile-test.cpp
@@ -270,7 +295,8 @@ EXTRA_DIST += tests/scanner-test.sh \
tests/data/small-server.h   \
tests/data/small-code-core.c\
tests/data/small-client-core.h  \
-   tests/data/small-server-core.h
+   tests/data/small-server-core.h  \
+   tests/data/tiny.xml
 
 tests/scanner-test.sh: $(top_builddir)/wayland-scanner
 
diff --git a/tests/data/tiny.xml b/tests/data/tiny.xml
new file mode 100644
index 000..0b8cdde
--- /dev/null
+++ b/tests/data/tiny.xml
@@ -0,0 +1,38 @@
+
+
+
+  
+Copyright © 2017 Red Hat Inc.
+
+Permission is hereby granted, free of charge

[PATCH wayland v2 4/4] tests/scanner-test: Add tests for visibility

[Jonas Ådahl]

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 tests/data/noexport-small-client-core.h | 195 
 tests/data/noexport-small-code-core.c   |  61 ++
 tests/data/noexport-small-server-core.h | 154 +
 tests/data/static-small-client-core.h   | 195 
 tests/data/static-small-code-core.c |  61 ++
 tests/data/static-small-server-core.h   | 154 +
 tests/scanner-test.sh   |  12 ++
 7 files changed, 832 insertions(+)
 create mode 100644 tests/data/noexport-small-client-core.h
 create mode 100644 tests/data/noexport-small-code-core.c
 create mode 100644 tests/data/noexport-small-server-core.h
 create mode 100644 tests/data/static-small-client-core.h
 create mode 100644 tests/data/static-small-code-core.c
 create mode 100644 tests/data/static-small-server-core.h

diff --git a/tests/data/noexport-small-client-core.h 
b/tests/data/noexport-small-client-core.h
new file mode 100644
index 000..c85cca6
--- /dev/null
+++ b/tests/data/noexport-small-client-core.h
@@ -0,0 +1,195 @@
+/* SCANNER TEST */
+
+#ifndef SMALL_TEST_CLIENT_PROTOCOL_H
+#define SMALL_TEST_CLIENT_PROTOCOL_H
+
+#include 
+#include 
+#include "wayland-client-core.h"
+
+#ifdef  __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @page page_small_test The small_test protocol
+ * @section page_ifaces_small_test Interfaces
+ * - @subpage page_iface_intf_A - the thing A
+ * @section page_copyright_small_test Copyright
+ * 
+ *
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * 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.
+ * 
+ */
+struct another_intf;
+struct intf_A;
+struct intf_not_here;
+
+/**
+ * @page page_iface_intf_A intf_A
+ * @section page_iface_intf_A_desc Description
+ *
+ * A useless example trying to tickle the scanner.
+ * @section page_iface_intf_A_api API
+ * See @ref iface_intf_A.
+ */
+/**
+ * @defgroup iface_intf_A The intf_A interface
+ *
+ * A useless example trying to tickle the scanner.
+ */
+extern const struct wl_interface intf_A_interface;
+
+#ifndef INTF_A_FOO_ENUM
+#define INTF_A_FOO_ENUM
+enum intf_A_foo {
+   /**
+* this is the first
+*/
+   INTF_A_FOO_FIRST = 0,
+   /**
+* this is the second
+*/
+   INTF_A_FOO_SECOND = 1,
+   /**
+* this is the third
+* @since 2
+*/
+   INTF_A_FOO_THIRD = 2,
+};
+/**
+ * @ingroup iface_intf_A
+ */
+#define INTF_A_FOO_THIRD_SINCE_VERSION 2
+#endif /* INTF_A_FOO_ENUM */
+
+/**
+ * @ingroup iface_intf_A
+ * @struct intf_A_listener
+ */
+struct intf_A_listener {
+   /**
+*/
+   void (*hey)(void *data,
+   struct intf_A *intf_A);
+};
+
+/**
+ * @ingroup iface_intf_A
+ */
+static inline int
+intf_A_add_listener(struct intf_A *intf_A,
+   const struct intf_A_listener *listener, void *data)
+{
+   return wl_proxy_add_listener((struct wl_proxy *) intf_A,
+(void (**)(void)) listener, data);
+}
+
+#define INTF_A_RQ1 0
+#define INTF_A_RQ2 1
+#define INTF_A_DESTROY 2
+
+/**
+ * @ingroup iface_intf_A
+ */
+#define INTF_A_HEY_SINCE_VERSION 1
+
+/**
+ * @ingroup iface_intf_A
+ */
+#define INTF_A_RQ1_SINCE_VERSION 1
+/**
+ * @ingroup iface_intf_A
+ */
+#define INTF_A_RQ2_SINCE_VERSION 1
+/**
+ * @ingroup iface_intf_A
+ */
+#define INTF_A_DESTROY_SINCE_VERSION 1
+
+/** @ingroup iface_intf_A */
+static inline void
+intf_A_set_user_data(struct intf_A *intf_A, void *user_data)
+{
+   wl_proxy_set_user_data((struct wl_proxy *) intf_A, user_data);
+}
+
+/** @ingroup iface_intf_A */
+static inline void *
+intf_A_get_user_data(struct intf_A *intf_A)
+{
+   return wl_proxy_get_user_data((struct wl_proxy *) intf_A);
+}
+
+static inline uint32_t
+intf_A_get_version(struct intf_A *intf_A)
+{
+   return w

[PATCH wayland v2 3/4] tests: Test compiler-default symbol visibility

[Jonas Ådahl]

Test that it is possible to not export protocol symbols.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 .gitignore  |   5 ++
 Makefile.am |  27 ++-
 tests/noexport-symbol-test-client.c |  77 +++
 tests/noexport-symbol-test-server.c | 146 
 4 files changed, 253 insertions(+), 2 deletions(-)
 create mode 100644 tests/noexport-symbol-test-client.c
 create mode 100644 tests/noexport-symbol-test-server.c

diff --git a/.gitignore b/.gitignore
index 553ffd0..e61d193 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,3 +50,8 @@ static-tiny-server-protocol-core.h
 static-tiny-client-protocol-core.h
 static-symbol-test-server
 static-symbol-test-client
+noexport-tiny-protocol.c
+noexport-tiny-server-protocol-core.h
+noexport-tiny-client-protocol-core.h
+noexport-symbol-test-server
+noexport-symbol-test-client
diff --git a/Makefile.am b/Makefile.am
index bbd5107..40f73d6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -117,6 +117,8 @@ BUILT_SOURCES = \
$(nodist_headers_test_SOURCES)  \
$(nodist_static_symbol_test_server_SOURCES) \
$(nodist_static_symbol_test_client_SOURCES) \
+   $(nodist_noexport_symbol_test_server_SOURCES)   \
+   $(nodist_noexport_symbol_test_client_SOURCES)   \
static-tiny-protocol.inc
 
 CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db
@@ -168,10 +170,12 @@ built_test_programs = \
headers-test\
compositor-introspection-test   \
protocol-logger-test\
-   static-symbol-test-server
+   static-symbol-test-server   \
+   noexport-symbol-test-server
 
 built_test_program_helpers =   \
-   static-symbol-test-client
+   static-symbol-test-client   \
+   noexport-symbol-test-client
 
 if ENABLE_CPP_TEST
 built_test_programs += cpp-compile-test
@@ -218,6 +222,15 @@ static-tiny-server-protocol-core.h : tests/data/tiny.xml
 static-tiny-client-protocol-core.h : tests/data/tiny.xml
$(AM_V_GEN)$(wayland_scanner) -c -Vstatic client-header $< $@
 
+noexport-tiny-protocol.c : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vcompiler-default code $< $@
+
+noexport-tiny-server-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vcompiler-default server-header $< $@
+
+noexport-tiny-client-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vcompiler-default client-header $< $@
+
 array_test_SOURCES = tests/array-test.c
 array_test_LDADD = libtest-runner.la
 client_test_SOURCES = tests/client-test.c
@@ -270,6 +283,16 @@ static_symbol_test_client_SOURCES = 
tests/static-symbol-test-client.c
 nodist_static_symbol_test_client_SOURCES = \
static-tiny-client-protocol-core.h
 static_symbol_test_client_LDADD = libtest-runner.la
+noexport_symbol_test_server_SOURCES = tests/noexport-symbol-test-server.c
+nodist_noexport_symbol_test_server_SOURCES = \
+   noexport-tiny-protocol.c \
+   noexport-tiny-server-protocol-core.h
+noexport_symbol_test_server_LDADD = libtest-runner.la
+noexport_symbol_test_client_SOURCES = tests/noexport-symbol-test-client.c
+nodist_noexport_symbol_test_client_SOURCES = \
+   noexport-tiny-protocol.c \
+   noexport-tiny-client-protocol-core.h
+noexport_symbol_test_client_LDADD = libtest-runner.la
 
 if ENABLE_CPP_TEST
 cpp_compile_test_SOURCES = tests/cpp-compile-test.cpp
diff --git a/tests/noexport-symbol-test-client.c 
b/tests/noexport-symbol-test-client.c
new file mode 100644
index 000..11e02b9
--- /dev/null
+++ b/tests/noexport-symbol-test-client.c
@@ -0,0 +1,77 @@
+/*
+ * 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

Re: [PATCH 1/2] scanner: Add --visibility flag for setting symbol visibility

[Jonas Ådahl]

On Tue, Jul 25, 2017 at 02:44:29PM +0300, Pekka Paalanen wrote:
> On Tue, 25 Jul 2017 18:39:56 +0800
> Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > Add a --visibility flag that enables the user to tweak the visibility
> > of the symbols generated by wayland-scanner. Three alternatives are
> > exposed:
> > 
> > 'export': as has always been done up until now, export the symbols
> > using WL_EXPORT, making making them exposed externally. This is the
> > default in order to not break backward compatibility.
> > 
> > 'compiler-default': use whatever visibility the compiler defaults to.
> > This is most likely the most visibility that protocol implementations
> > or users actually wants, as it doesn't expose any unwanted
> > implementation details.
> > 
> > 'static': each symbol will only be visible to the compilation unit it
> > is included in. This means that a protocol implementations and users
> > needs to include both the 'code' file and either the 'client-header' or
> > 'server-header' (or both) in the source file implementing or using the
> > protocol in question.
> > 
> > Using 'static' is a method to avoid situations where otherwise exposed
> > symbols of different protocols would conflict, for example if they have
> > the same interface name.
> > 
> > When no visibility is specified, 'export' is assumed, but a warning is
> > printed to stderr, as it is unlikely that 'export' is what is actually
> > desired.
> > 
> > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > ---
> >  Makefile.am   |  10 ++---
> >  src/scanner.c | 124 
> > +++---
> >  2 files changed, 114 insertions(+), 20 deletions(-)
> 
> Hi Jonas,
> 
> thanks for writing this patch. The commit message is well written.
> 
> I wonder where we could write down the guidelines on what visiblity to
> prefer:
> 
> - always go for 'compiler-default' unless...
> 
> - you already exported the symbols previously and cannot stop exporting
>   them so choose 'export' to stop the warnings, or
> 
> - you have to support protocols with conflicting symbol names and you
>   have no choice but to use 'static' with the caveat it implies.
> 
> Maybe this could be a new paragraph in usage()?

I don't see why not.

> 
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index d0c8bd3..d570525 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -97,19 +97,19 @@ nodist_libwayland_client_la_SOURCES =   \
> >  pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
> >  
> >  protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
> > -   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
> > +   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport code < 
> > $< > $@
> >  
> >  protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
> > -   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < 
> > $< > $@
> > +   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
> > server-header < $< > $@
> >  
> >  protocol/%-client-protocol.h : $(top_srcdir)/protocol/%.xml
> > -   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header < 
> > $< > $@
> > +   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
> > client-header < $< > $@
> >  
> >  protocol/%-server-protocol-core.h : $(top_srcdir)/protocol/%.xml
> > -   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header -c 
> > < $< > $@
> > +   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
> > server-header -c < $< > $@
> >  
> >  protocol/%-client-protocol-core.h : $(top_srcdir)/protocol/%.xml
> > -   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header -c 
> > < $< > $@
> > +   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
> > client-header -c < $< > $@
> >  
> >  BUILT_SOURCES =\
> > $(nodist_libwayland_server_la_SOURCES)  \
> > diff --git a/src/scanner.c b/src/scanner.c
> > index 517068c..d9152e3 100644
> > --- a/src/scanner.c
> > +++ b/src/scanner.c
> > @@ -57,6 +57,12 @@ enum side {
> > SERVER,
> >  };
> >  
> > +enum visibility {
> > +   VISIBILITY_EXPORT,
> > +   VISIBILITY_COMPILER_DEFAULT,
> > +   VISIBILITY_STAT

Re: [PATCH] libweston-desktop: add signals for title, app_id

[Jonas Ådahl]

On Tue, Jul 25, 2017 at 06:42:34AM -0600, Matt Hoosier wrote:
> I'd find it a little bit inconvenient for the title, class, and app-id to
> be treated as buffered state. They make a great poor-man's way of
> identifying surfaces for embedded systems that implement simple layer
> management policies without wholesale adopting IVI shell (whose lack of
> wl_shell makes it difficult to integrate off-the-rack Wayland libraries and
> apps). Since the surface title doesn't have anything to do with correct
> graphical presentation, it'd be nicer if that data is just available
> immediately to the rest of the shell rather than being something that only
> trickles in whenever the app happens to post a buffer next.

There is no need to attach a new buffer to commit a new state. One could
for example commit a state only changing the title and nothing else, and
it'd be completely correct. The benefit of synchronizing it is for
example that a shell can synchronously change some overlay with the
content.

Regarding the app_id, the app_id should normally only ever be set once,
as part of the initial state that doesn't have a buffer attached yet.


Jonas

> 
> On Tue, Jul 25, 2017 at 12:17 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > On Fri, Jul 21, 2017 at 05:21:38PM +0200, Quentin Glidic wrote:
> > > On 7/20/17 4:33 PM, Matt Hoosier wrote:
> > > > It's useful for the shell implementation to know when these change,
> > > > for example to relay the information on to taskbars or similar.
> > >
> > > The idea is good, we need something like that. (But maybe not, see
> > below).
> > >
> > >
> > > > To avoid ABI changes or the need to make the weston_desktop_surface
> > > > definition public, new functions are introduced for attaching
> > > > listeners to these signals.
> > >
> > > We don’t care that much about ABI changes, but you’re right that I do
> > care
> > > about the struct staying private.
> > >
> > >
> > > > Signed-off-by: Matt Hoosier <matt.hoos...@gmail.com>
> > > > ---
> > > >   libweston-desktop/libweston-desktop.h |  6 ++
> > > >   libweston-desktop/surface.c   | 21 +
> > > >   2 files changed, 27 insertions(+)
> > > >
> > > > diff --git a/libweston-desktop/libweston-desktop.h
> > b/libweston-desktop/libweston-desktop.h
> > > > index 03b04c7..e38257e 100644
> > > > --- a/libweston-desktop/libweston-desktop.h
> > > > +++ b/libweston-desktop/libweston-desktop.h
> > > > @@ -164,6 +164,12 @@ weston_desktop_surface_set_size(struct
> > weston_desktop_surface *surface,
> > > > int32_t width, int32_t height);
> > > >   void
> > > >   weston_desktop_surface_close(struct weston_desktop_surface
> > *surface);
> > > > +void
> > > > +weston_desktop_surface_add_title_listener(struct
> > weston_desktop_surface *surface,
> > > > + struct wl_listener *listener);
> > > > +void
> > > > +weston_desktop_surface_add_app_id_listener(struct
> > weston_desktop_surface *surface,
> > > > +  struct wl_listener *listener);
> > > >   void *
> > > >   weston_desktop_surface_get_user_data(struct weston_desktop_surface
> > *surface);
> > > > diff --git a/libweston-desktop/surface.c b/libweston-desktop/surface.c
> > > > index d3be936..97a455c 100644
> > > > --- a/libweston-desktop/surface.c
> > > > +++ b/libweston-desktop/surface.c
> > > > @@ -64,6 +64,8 @@ struct weston_desktop_surface {
> > > > char *title;
> > > > char *app_id;
> > > > pid_t pid;
> > > > +   struct wl_signal title_signal;
> > > > +   struct wl_signal app_id_signal;
> > > > };
> > > > struct {
> > > > struct weston_desktop_surface *parent;
> > > > @@ -287,6 +289,9 @@ weston_desktop_surface_create(struct
> > weston_desktop *desktop,
> > > > wl_list_init(>view_list);
> > > > wl_list_init(>grab_link);
> > > > +   wl_signal_init(>title_signal);
> > > > +   wl_signal_init(>app_id_signal);
> > > > +
> > > > return surface;
> > > >   }
> > > > @@ -511,6 +516,20 @@ weston_desktop_surface_close(struct
> > weston_desktop_surface *surface)
> > > >
> > surface->

[PATCH 2/2] tests: Test static symbol visibility

[Jonas Ådahl]

Test that it is possible to inline the protocol 'code' file generated
by wayland-scanner in the source code files using it.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 .gitignore|   5 ++
 Makefile.am   |  32 -
 tests/data/tiny.xml   |  38 ++
 tests/static-symbol-test-client.c |  78 
 tests/static-symbol-test-server.c | 147 ++
 5 files changed, 297 insertions(+), 3 deletions(-)
 create mode 100644 tests/data/tiny.xml
 create mode 100644 tests/static-symbol-test-client.c
 create mode 100644 tests/static-symbol-test-server.c

diff --git a/.gitignore b/.gitignore
index 8da9861..553ffd0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,3 +45,8 @@ exec-fd-leak-checker
 fixed-benchmark
 /wayland-scanner
 protocol/*.[ch]
+static-tiny-protocol.inc
+static-tiny-server-protocol-core.h
+static-tiny-client-protocol-core.h
+static-symbol-test-server
+static-symbol-test-client
diff --git a/Makefile.am b/Makefile.am
index d570525..bbd5107 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -114,7 +114,10 @@ protocol/%-client-protocol-core.h : 
$(top_srcdir)/protocol/%.xml
 BUILT_SOURCES =\
$(nodist_libwayland_server_la_SOURCES)  \
$(nodist_libwayland_client_la_SOURCES)  \
-   $(nodist_headers_test_SOURCES)
+   $(nodist_headers_test_SOURCES)  \
+   $(nodist_static_symbol_test_server_SOURCES) \
+   $(nodist_static_symbol_test_client_SOURCES) \
+   static-tiny-protocol.inc
 
 CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db
 DISTCLEANFILES = src/wayland-version.h
@@ -164,7 +167,11 @@ built_test_programs =  \
message-test\
headers-test\
compositor-introspection-test   \
-   protocol-logger-test
+   protocol-logger-test\
+   static-symbol-test-server
+
+built_test_program_helpers =   \
+   static-symbol-test-client
 
 if ENABLE_CPP_TEST
 built_test_programs += cpp-compile-test
@@ -172,6 +179,7 @@ endif
 
 AM_TESTS_ENVIRONMENT = \
export WAYLAND_SCANNER='$(top_builddir)/wayland-scanner'\
+   export TOP_BUILDDIR='$(top_builddir)'   \
TEST_DATA_DIR='$(top_srcdir)/tests/data'\
TEST_OUTPUT_DIR='$(top_builddir)/tests/output'  \
SED=$(SED)  \
@@ -182,6 +190,7 @@ TESTS = $(built_test_programs)  \
 
 noinst_PROGRAMS =  \
$(built_test_programs)  \
+   $(built_test_program_helpers)   \
exec-fd-leak-checker\
fixed-benchmark
 
@@ -200,6 +209,14 @@ libtest_runner_la_LIBADD = \
libwayland-server.la\
-lrt -ldl $(FFI_LIBS)
 
+static-tiny-protocol.inc : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic code $< $@
+
+static-tiny-server-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic server-header $< $@
+
+static-tiny-client-protocol-core.h : tests/data/tiny.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -Vstatic client-header $< $@
 
 array_test_SOURCES = tests/array-test.c
 array_test_LDADD = libtest-runner.la
@@ -245,6 +262,14 @@ headers_test_LDADD = libtest-runner.la
 nodist_headers_test_SOURCES =  \
protocol/wayland-server-protocol-core.h \
protocol/wayland-client-protocol-core.h
+static_symbol_test_server_SOURCES = tests/static-symbol-test-server.c
+nodist_static_symbol_test_server_SOURCES = \
+   static-tiny-server-protocol-core.h
+static_symbol_test_server_LDADD = libtest-runner.la
+static_symbol_test_client_SOURCES = tests/static-symbol-test-client.c
+nodist_static_symbol_test_client_SOURCES = \
+   static-tiny-client-protocol-core.h
+static_symbol_test_client_LDADD = libtest-runner.la
 
 if ENABLE_CPP_TEST
 cpp_compile_test_SOURCES = tests/cpp-compile-test.cpp
@@ -270,7 +295,8 @@ EXTRA_DIST += tests/scanner-test.sh \
tests/data/small-server.h   \
tests/data/small-code-core.c\
tests/data/small-client-core.h  \
-   tests/data/small-server-core.h
+   tests/data/small-server-core.h  \
+   tests/data/tiny.xml
 
 tests/scanner-test.sh: $(top_builddir)/wayland-scanner
 
diff --git a/tests/data/tiny.xml b/tests/data/tiny.xml
new file mode 100644
index 000..0b8cdde
--- /dev/null
+++ b/tests/data/tiny.xml
@@ -0,0 +1,38 @@
+
+
+
+  
+Copyright © 2017 Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person
+o

[PATCH 1/2] scanner: Add --visibility flag for setting symbol visibility

[Jonas Ådahl]

Add a --visibility flag that enables the user to tweak the visibility
of the symbols generated by wayland-scanner. Three alternatives are
exposed:

'export': as has always been done up until now, export the symbols
using WL_EXPORT, making making them exposed externally. This is the
default in order to not break backward compatibility.

'compiler-default': use whatever visibility the compiler defaults to.
This is most likely the most visibility that protocol implementations
or users actually wants, as it doesn't expose any unwanted
implementation details.

'static': each symbol will only be visible to the compilation unit it
is included in. This means that a protocol implementations and users
needs to include both the 'code' file and either the 'client-header' or
'server-header' (or both) in the source file implementing or using the
protocol in question.

Using 'static' is a method to avoid situations where otherwise exposed
symbols of different protocols would conflict, for example if they have
the same interface name.

When no visibility is specified, 'export' is assumed, but a warning is
printed to stderr, as it is unlikely that 'export' is what is actually
desired.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 Makefile.am   |  10 ++---
 src/scanner.c | 124 +++---
 2 files changed, 114 insertions(+), 20 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index d0c8bd3..d570525 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -97,19 +97,19 @@ nodist_libwayland_client_la_SOURCES =   \
 pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
 
 protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport code < 
$< > $@
 
 protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
server-header < $< > $@
 
 protocol/%-client-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
client-header < $< > $@
 
 protocol/%-server-protocol-core.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header -c 
< $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
server-header -c < $< > $@
 
 protocol/%-client-protocol-core.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header -c 
< $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) -Vexport 
client-header -c < $< > $@
 
 BUILT_SOURCES =\
$(nodist_libwayland_server_la_SOURCES)  \
diff --git a/src/scanner.c b/src/scanner.c
index 517068c..d9152e3 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -57,6 +57,12 @@ enum side {
SERVER,
 };
 
+enum visibility {
+   VISIBILITY_EXPORT,
+   VISIBILITY_COMPILER_DEFAULT,
+   VISIBILITY_STATIC
+};
+
 static int
 usage(int ret)
 {
@@ -72,7 +78,16 @@ usage(int ret)
" the scanner was built 
against.\n"
"-c,  --include-core-only include the core 
version of the headers,\n"
" that is e.g. 
wayland-client-core.h instead\n"
-   " of 
wayland-client.h.\n");
+   " of 
wayland-client.h.\n"
+   "-V,  
--visibility=[export|compiler-default|static]\n"
+   " select what type of 
visibility protocol\n"
+   " symbols should have. 
'export' will cause the\n"
+   " symbols to be 
exported, 'compiler-default'\n"
+   " will use the compiler 
default (often visible\n"
+   " only within the same 
DSO), 'static' will make\n"
+   " all symbols static 
(note that the file\n"
+   " generated with 'code' 
must be included in the\n"
+   " same file 

Re: [PATCH wayland 2/3] scanner: Allow adding a prefix to exported symbols

[Jonas Ådahl]

On Mon, Jul 24, 2017 at 02:16:04PM +0300, Pekka Paalanen wrote:
> On Mon,  3 Jul 2017 17:16:45 +0800
> Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > Two different protocols may use interfaces with identical names.
> > Implementing support for both those protocols would result in symbol
> > clashes, as wayland-scanner generates symbols from the interface names.
> > 
> > Make it possible to avoiding these clashes by adding a way to add a
> > prefix to the symbols generated by wayland-scanner. Implementations
> > (servers and clients) can then use these prefix:ed symbols to implement
> > different objects with the same name.
> > 
> > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > ---
> > 
> > Something like this would be needed if a compositor/client wants to 
> > implement
> > xdg-shell unstable v5 alongside xdg-shell stable, unless we want to rename 
> > all
> > our xdg-shell interfaces. Implementing xdg-shell unstable v6 alongside
> > xdg-shell stable does not have this issue.
> > 
> > See issue raised here:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-June/034380.html
> > 
> > 
> > Jonas
> > 
> > 
> >  src/scanner.c | 94 
> > ++-
> >  1 file changed, 73 insertions(+), 21 deletions(-)
> 
> 
> Hi,
> 
> while this seems to change the ABI symbol names, it does not change the
> names in the documentation, and it does not change the names of
> #defines of enums, or the inline functions. That means that this is not
> enough to fulfill the purpose: being able to use two similarly named
> but different protocols by adding a prefix.

The idea I had was rather that one would avoid changing any names on
non-symbols. It'd still be possible to implement both by doing it in
separate C files. I can see the point in adding the prefix on everything
though, so I'll provide a patch for that.


Jonas

> 
> For the idea:
> Acked-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> 
> But I think it needs to apply the prefix to *everything*, both ABI and
> API.
> 
> 
> Thanks,
> pq


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

Re: [PATCH] libweston-desktop: add signals for title, app_id

[Jonas Ådahl]

On Fri, Jul 21, 2017 at 05:21:38PM +0200, Quentin Glidic wrote:
> On 7/20/17 4:33 PM, Matt Hoosier wrote:
> > It's useful for the shell implementation to know when these change,
> > for example to relay the information on to taskbars or similar.
> 
> The idea is good, we need something like that. (But maybe not, see below).
> 
> 
> > To avoid ABI changes or the need to make the weston_desktop_surface
> > definition public, new functions are introduced for attaching
> > listeners to these signals.
> 
> We don’t care that much about ABI changes, but you’re right that I do care
> about the struct staying private.
> 
> 
> > Signed-off-by: Matt Hoosier 
> > ---
> >   libweston-desktop/libweston-desktop.h |  6 ++
> >   libweston-desktop/surface.c   | 21 +
> >   2 files changed, 27 insertions(+)
> > 
> > diff --git a/libweston-desktop/libweston-desktop.h 
> > b/libweston-desktop/libweston-desktop.h
> > index 03b04c7..e38257e 100644
> > --- a/libweston-desktop/libweston-desktop.h
> > +++ b/libweston-desktop/libweston-desktop.h
> > @@ -164,6 +164,12 @@ weston_desktop_surface_set_size(struct 
> > weston_desktop_surface *surface,
> > int32_t width, int32_t height);
> >   void
> >   weston_desktop_surface_close(struct weston_desktop_surface *surface);
> > +void
> > +weston_desktop_surface_add_title_listener(struct weston_desktop_surface 
> > *surface,
> > + struct wl_listener *listener);
> > +void
> > +weston_desktop_surface_add_app_id_listener(struct weston_desktop_surface 
> > *surface,
> > +  struct wl_listener *listener);
> >   void *
> >   weston_desktop_surface_get_user_data(struct weston_desktop_surface 
> > *surface);
> > diff --git a/libweston-desktop/surface.c b/libweston-desktop/surface.c
> > index d3be936..97a455c 100644
> > --- a/libweston-desktop/surface.c
> > +++ b/libweston-desktop/surface.c
> > @@ -64,6 +64,8 @@ struct weston_desktop_surface {
> > char *title;
> > char *app_id;
> > pid_t pid;
> > +   struct wl_signal title_signal;
> > +   struct wl_signal app_id_signal;
> > };
> > struct {
> > struct weston_desktop_surface *parent;
> > @@ -287,6 +289,9 @@ weston_desktop_surface_create(struct weston_desktop 
> > *desktop,
> > wl_list_init(>view_list);
> > wl_list_init(>grab_link);
> > +   wl_signal_init(>title_signal);
> > +   wl_signal_init(>app_id_signal);
> > +
> > return surface;
> >   }
> > @@ -511,6 +516,20 @@ weston_desktop_surface_close(struct 
> > weston_desktop_surface *surface)
> >surface->implementation_data);
> >   }
> > +WL_EXPORT void
> > +weston_desktop_surface_add_title_listener(struct weston_desktop_surface 
> > *surface,
> > + struct wl_listener *listener)
> > +{
> > +   wl_signal_add(>title_signal, listener);
> > +}
> > +
> > +WL_EXPORT void
> > +weston_desktop_surface_add_app_id_listener(struct weston_desktop_surface 
> > *surface,
> > +  struct wl_listener *listener)
> > +{
> > +   wl_signal_add(>app_id_signal, listener);
> > +}
> > +
> >   struct weston_desktop_surface *
> >   weston_desktop_surface_from_client_link(struct wl_list *link)
> >   {
> > @@ -687,6 +706,7 @@ weston_desktop_surface_set_title(struct 
> > weston_desktop_surface *surface,
> > free(surface->title);
> > surface->title = tmp;
> > +   wl_signal_emit(>title_signal, surface->title);
> 
> I would rather pass the surface as the signal data. Just in case we have in
> the future a value that doesn’t fit in a pointer. And calling a getter is
> not that bad.
> 
> Also, I prefer to have one signal only, it would reduce the API size (and
> avoid it growing too much in the future, since it could work in this case).
> We can move the free() to keep both pointer around until after the signal
> fired, and a simple pointer comparison will work (if you stored the "const
> char *" directly, which you should as with the signal, we guarantee it will
> exist until destroy or signal).
> 
> 
> But it raised a question : Jonas, are set_title() and set_app_id() supposed
> to be active without a commit()?

No. As per specification they are not tied to wl_surface.commit(). I
suppose it is something we can change though, while we can, if it makes
any sense. Opinions?


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

Re: Possible to run an xorg desktop in Wayland?

[Jonas Ådahl]

On Thu, Jul 20, 2017 at 04:05:21PM -0600, Jeff Sadowski wrote:
> So from what I gather wayland can run xorg under it right?
> If I'm running xorg I should be able to run something like x11vnc to
> connect to that xorg correct?
> and run stuff like xdotool on that xorg as well right?

Not really. Normally when running a Wayland compositor, X11 clients
connect to a Xwayland instance, that, to simplify things, translates X11
to Wayland. However, since Wayland has a lot more isolation (for example
no way to inject input affecting other clients, eaves dropping on input
events sent to other clients or read the screen content) certain things
that clients like xdotool (inject input) and x11vnc (inject input + read
screen content) will not work.

X11 clients injecting and eaves dropping input events amongst each other
might still work though, but regular Wayland will be completely
unaffected.

They would work if you run the clients in a rootful complete Xorg server
on top of Wayland (such as Xnest and Xephyr), but in effect that will be
a like running a separate session with a separate window manager and
background etc inside a window, much like how virtual machines are
presented, and they (x11vnc, xdotool, clients in the nested X server)
will only be displayed in and aware of what is inside that nested x
server.


Jonas

> 
> I'm testing out wayland under a virtualbox vm that I have running under
> xorg.
> My vm is running Fedora rawhide.
> 
> 
> echo -e "$(loginctl|grep -v -i SESSION|awk '{print $1}')"|while read
> session; do
> loginctl show-session ${session} -p Type
> done
> 
> shows
> 
> Type=tty
> Type=wayland
> 
> Yay I'm running wayland.
> 
> If I run xterm in wayland I can run xdotool to type stuff to it. This
> didn't work in gnome-terminal
> 
> xrandr
> Screen 0: minimum 320 x 200, current 800 x 600, maximum 8192 x 8192
> XWAYLAND0 connected 800x600+0+0 (normal left inverted right x axis y axis)
> 0mm x 0mm
>800x600   59.86*+
> 
> /usr/bin/x11vnc -o ~/x11vnc/x11vnc.log -capslock -loop -forever -shared
> -noxfixes -usepw -passwdfile ~/x11vnc/passwd
> 
>  --- x11vnc loop: 1 ---
> 
>  --- x11vnc loop: waiting for: 2863
> 
> 
>  --- x11vnc loop: sleeping 2000 ms ---
> 
> 
>  --- x11vnc loop: 2 ---
> 
>  --- x11vnc loop: waiting for: 2864
> 
> 
>  --- x11vnc loop: sleeping 2000 ms ---
> ...
> 
> My goal is to at least see and control a subset of windows with vnc under
> wayland.

> ___
> 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: [PATCH weston v4] libweston-desktop/xdg-shell: Properly handle ack_configure

[Jonas Ådahl]

On Thu, Jul 20, 2017 at 10:45:38AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic <sardemff7+...@sardemff7.net>
> 
> Now we keep track of serial->state association and we discard the states
> that the client ignored.
> 
> Signed-off-by: Quentin Glidic <sardemff7+...@sardemff7.net>

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

> ---
> 
> On 7/20/17 10:24 AM, Jonas Ådahl wrote:
> > Noticed one more thing I missed in the previous review: cleanup of the
> > pending configure allocations on surface destruction.
> 
> Oh, good catch, thanks.
> 
> v3:
>  Fixed a tiny style issue
>  Now send an error on wrong serial
> v4:
>  Free configure_list on destroy
> 
>  libweston-desktop/xdg-shell-v5.c | 60 ++
>  libweston-desktop/xdg-shell-v6.c | 79 
> +++-
>  2 files changed, 122 insertions(+), 17 deletions(-)
> 
> diff --git a/libweston-desktop/xdg-shell-v5.c 
> b/libweston-desktop/xdg-shell-v5.c
> index b32b7812..c91c2590 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -46,6 +46,13 @@ struct weston_desktop_xdg_surface_state {
>   bool activated;
>  };
>  
> +struct weston_desktop_xdg_surface_configure {
> + struct wl_list link; /* weston_desktop_xdg_surface::configure_list */
> + uint32_t serial;
> + struct weston_desktop_xdg_surface_state state;
> + struct weston_size size;
> +};
> +
>  struct weston_desktop_xdg_surface {
>   struct wl_resource *resource;
>   struct weston_desktop_surface *surface;
> @@ -53,7 +60,7 @@ struct weston_desktop_xdg_surface {
>   bool added;
>   struct wl_event_source *add_idle;
>   struct wl_event_source *configure_idle;
> - uint32_t configure_serial;
> + struct wl_list configure_list; /* 
> weston_desktop_xdg_surface_configure::link */
>   struct {
>   struct weston_desktop_xdg_surface_state state;
>   struct weston_size size;
> @@ -94,13 +101,26 @@ static void
>  weston_desktop_xdg_surface_send_configure(void *data)
>  {
>   struct weston_desktop_xdg_surface *surface = data;
> + struct weston_desktop_xdg_surface_configure *configure;
>   uint32_t *s;
>   struct wl_array states;
>  
>   surface->configure_idle = NULL;
>  
> - surface->configure_serial =
> + configure = zalloc(sizeof(struct weston_desktop_xdg_surface_configure));
> + if (configure == NULL) {
> + struct weston_desktop_client *client =
> + weston_desktop_surface_get_client(surface->surface);
> + struct wl_client *wl_client =
> + weston_desktop_client_get_client(client);
> + wl_client_post_no_memory(wl_client);
> + return;
> + }
> + wl_list_insert(surface->configure_list.prev, >link);
> + configure->serial =
>   
> wl_display_next_serial(weston_desktop_get_display(surface->desktop));
> + configure->state = surface->pending.state;
> + configure->size = surface->pending.size;
>  
>   wl_array_init();
>   if (surface->pending.state.maximized) {
> @@ -124,7 +144,7 @@ weston_desktop_xdg_surface_send_configure(void *data)
>  surface->pending.size.width,
>  surface->pending.size.height,
>  ,
> -surface->configure_serial);
> +configure->serial);
>  
>   wl_array_release();
>  };
> @@ -325,6 +345,7 @@ weston_desktop_xdg_surface_destroy(struct 
> weston_desktop_surface *dsurface,
>  void *user_data)
>  {
>   struct weston_desktop_xdg_surface *surface = user_data;
> + struct weston_desktop_xdg_surface_configure *configure, *temp;
>  
>   if (surface->added)
>   weston_desktop_api_surface_removed(surface->desktop,
> @@ -336,6 +357,9 @@ weston_desktop_xdg_surface_destroy(struct 
> weston_desktop_surface *dsurface,
>   if (surface->configure_idle != NULL)
>   wl_event_source_remove(surface->configure_idle);
>  
> + wl_list_for_each_safe(configure, temp, >configure_list, link)
> + free(configure);
> +
>   free(surface);
>  }
>  
> @@ -443,12 +467,34 @@ 
> weston_desktop_xdg_surface_protocol_ack_configure(struct wl_client *wl_client,
>   wl_resource_get_user_data(resource);
>   struct weston_desktop_xdg_surface *surface =
>   weston_desktop_surface_get_implementa

Re: [PATCH weston v3] libweston-desktop/xdg-shell: Properly handle ack_configure

[Jonas Ådahl]

On Thu, Jul 20, 2017 at 09:17:23AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic 
> 
> Now we keep track of serial->state association and we discard the states
> that the client ignored.
> 
> Signed-off-by: Quentin Glidic 
> ---
> v3:
>  Fixed a tiny style issue
>  Now send an error on wrong serial

Noticed one more thing I missed in the previous review: cleanup of the
pending configure allocations on surface destruction.


Jonas

> 
>  libweston-desktop/xdg-shell-v5.c | 56 ++
>  libweston-desktop/xdg-shell-v6.c | 75 
> ++--
>  2 files changed, 114 insertions(+), 17 deletions(-)
> 
> diff --git a/libweston-desktop/xdg-shell-v5.c 
> b/libweston-desktop/xdg-shell-v5.c
> index b32b7812..f428e02e 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -46,6 +46,13 @@ struct weston_desktop_xdg_surface_state {
>   bool activated;
>  };
>  
> +struct weston_desktop_xdg_surface_configure {
> + struct wl_list link; /* weston_desktop_xdg_surface::configure_list */
> + uint32_t serial;
> + struct weston_desktop_xdg_surface_state state;
> + struct weston_size size;
> +};
> +
>  struct weston_desktop_xdg_surface {
>   struct wl_resource *resource;
>   struct weston_desktop_surface *surface;
> @@ -53,7 +60,7 @@ struct weston_desktop_xdg_surface {
>   bool added;
>   struct wl_event_source *add_idle;
>   struct wl_event_source *configure_idle;
> - uint32_t configure_serial;
> + struct wl_list configure_list; /* 
> weston_desktop_xdg_surface_configure::link */
>   struct {
>   struct weston_desktop_xdg_surface_state state;
>   struct weston_size size;
> @@ -94,13 +101,26 @@ static void
>  weston_desktop_xdg_surface_send_configure(void *data)
>  {
>   struct weston_desktop_xdg_surface *surface = data;
> + struct weston_desktop_xdg_surface_configure *configure;
>   uint32_t *s;
>   struct wl_array states;
>  
>   surface->configure_idle = NULL;
>  
> - surface->configure_serial =
> + configure = zalloc(sizeof(struct weston_desktop_xdg_surface_configure));
> + if (configure == NULL) {
> + struct weston_desktop_client *client =
> + weston_desktop_surface_get_client(surface->surface);
> + struct wl_client *wl_client =
> + weston_desktop_client_get_client(client);
> + wl_client_post_no_memory(wl_client);
> + return;
> + }
> + wl_list_insert(surface->configure_list.prev, >link);
> + configure->serial =
>   
> wl_display_next_serial(weston_desktop_get_display(surface->desktop));
> + configure->state = surface->pending.state;
> + configure->size = surface->pending.size;
>  
>   wl_array_init();
>   if (surface->pending.state.maximized) {
> @@ -124,7 +144,7 @@ weston_desktop_xdg_surface_send_configure(void *data)
>  surface->pending.size.width,
>  surface->pending.size.height,
>  ,
> -surface->configure_serial);
> +configure->serial);
>  
>   wl_array_release();
>  };
> @@ -443,12 +463,34 @@ 
> weston_desktop_xdg_surface_protocol_ack_configure(struct wl_client *wl_client,
>   wl_resource_get_user_data(resource);
>   struct weston_desktop_xdg_surface *surface =
>   weston_desktop_surface_get_implementation_data(dsurface);
> -
> - if (surface->configure_serial != serial)
> + struct weston_desktop_xdg_surface_configure *configure, *temp;
> + bool found = false;
> +
> + wl_list_for_each_safe(configure, temp, >configure_list, link) {
> + if (configure->serial < serial) {
> + wl_list_remove(>link);
> + free(configure);
> + } else if (configure->serial == serial) {
> + wl_list_remove(>link);
> + found = true;
> + }
> + break;
> + }
> + if (!found) {
> + struct weston_desktop_client *client =
> + weston_desktop_surface_get_client(dsurface);
> + struct wl_resource *client_resource =
> + weston_desktop_client_get_resource(client);
> + wl_resource_post_error(client_resource,
> +XDG_SHELL_ERROR_DEFUNCT_SURFACES,
> +"Wrong configure serial: %u", serial);
>   return;
> + }
> +
> + surface->next.state = configure->state;
> + surface->next.size = configure->size;
>  
> - surface->next.state = surface->pending.state;
> - surface->next.size = surface->pending.size;
> + free(configure);
>  }
>  
>  static void
> diff --git 

Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

There is already this paragraph added to xdg_toplevel:

+  Unmapping an xdg_toplevel means that the surface cannot be shown
+  by the compositor until it is explicitly mapped again.
+  All active operations (e.g., move, resize) are canceled and all
+  attributes (e.g. title, state, stacking, ...) are discarded for
+  an xdg_toplevel surface when it is unmapped.

Is that enough? We could probably add something about remapping should
be indistinguishable from destroying, creating then mapping, but the
above should mean the same thing.

FWIW, for popups we don't allow remapping.


Jonas

Oe Mon, Jul 17, 2017 at 03:09:14PM -0700, Jasper St. Pierre wrote:
> Then I'd like some stronger wording in this patch that dictates that
> unmapping and remapping a surface by either destroying the xdg_surface or
> attaching a NULL buffer should be indistinguishable. No "hidden state",
> either accessible or inaccessible to the app (such as stacking order,
> window position, or user-added hints or settings) should leak through an
> unmap/map cycle, if such wording hasn't been added already.
> 
> On Sun, Jul 16, 2017 at 11:32 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote:
> > > (Coming into this one late)
> > >
> > > When I first wrote xdg-shell, I maintained that attaching a NULL buffer
> > > should be illegal since it has no benefit compared to destroying the
> > > surface, but compositors might not reset all data attached to the
> > surface,
> > > making a weird exception where clients depend on bugs where state isn't
> > > always reset. And the "resetting of all data" might seem like strange
> > > behavior to clients.
> > >
> > > Has this rationale changed?
> >
> > Pretty much. It was never specified anywhere so implementations
> > differed (weston and mutter implemented it like that but not sure
> > anyone else did), it contradicted some wording in wayland.xml and it was
> > a behaviour disliked by some, thus a middle ground was reached that
> > clearly defines it as no state should be kept. I intend to try to make
> > sure at least libweston-desktop and mutter respects this fully.
> >
> >
> > Jonas
> >
> > >
> > > On Tue, Jul 11, 2017 at 8:11 PM, David Edmundson <davidedmund...@kde.org
> > >
> > > wrote:
> > >
> > > >
> > > >
> > > >> The idea is that having unmapped by null-attach means the
> > > >> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
> > > >> had when first created, thus to map again, one would do what one would
> > > >> do the same as when mapping it for the first time: set up the state
> > > >> (set_title, (set_maximized?), set_app_id), commit, wait for configure,
> > > >> then attach a new buffer given the configure event data.
> > > >>
> > > >>
> > > >> Thanks, I'd totally forgotten the commit as I was only looking in this
> > > > interface.
> > > > It's clear now.
> > > >
> > > > David
> > > >
> > > > ___
> > > > wayland-devel mailing list
> > > > wayland-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > > >
> > > >
> > >
> > >
> > > --
> > >   Jasper
> >
> 
> 
> 
> -- 
>   Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

On Sun, Jul 16, 2017 at 11:16:25PM -0700, Jasper St. Pierre wrote:
> (Coming into this one late)
> 
> When I first wrote xdg-shell, I maintained that attaching a NULL buffer
> should be illegal since it has no benefit compared to destroying the
> surface, but compositors might not reset all data attached to the surface,
> making a weird exception where clients depend on bugs where state isn't
> always reset. And the "resetting of all data" might seem like strange
> behavior to clients.
> 
> Has this rationale changed?

Pretty much. It was never specified anywhere so implementations
differed (weston and mutter implemented it like that but not sure
anyone else did), it contradicted some wording in wayland.xml and it was
a behaviour disliked by some, thus a middle ground was reached that
clearly defines it as no state should be kept. I intend to try to make
sure at least libweston-desktop and mutter respects this fully.


Jonas

> 
> On Tue, Jul 11, 2017 at 8:11 PM, David Edmundson 
> wrote:
> 
> >
> >
> >> The idea is that having unmapped by null-attach means the
> >> xdg_surface/xdg_toplevel etc is reset to the exact same state that it
> >> had when first created, thus to map again, one would do what one would
> >> do the same as when mapping it for the first time: set up the state
> >> (set_title, (set_maximized?), set_app_id), commit, wait for configure,
> >> then attach a new buffer given the configure event data.
> >>
> >>
> >> Thanks, I'd totally forgotten the commit as I was only looking in this
> > interface.
> > It's clear now.
> >
> > David
> >
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> >
> >
> 
> 
> -- 
>   Jasper
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH v3] Add xdg-output protocol

[Jonas Ådahl]

On Thu, Jul 06, 2017 at 04:01:25PM +0200, Olivier Fourdan wrote:
> This protocol aims at describing outputs in way which is more in line
> with the concept of an output on desktop oriented systems.
> 
> Some information are more specific to the concept of an output for a
> desktop oriented system and may not make sense in other applications,
> such as IVI systems for example.
> 
> The goal is to gradually move the desktop specific concepts out of the
> core wl_output protocol.
> 
> For now it just features the position and logical size which describe
> the output position and size in the global compositor space.
> 
> Signed-off-by: Olivier Fourdan <ofour...@redhat.com>

This one is 

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

but I'll wait with landing to see whether a consensus can be reached in
the E-mail thread.


Jonas

> ---
>  v2: use "destroy" instead of "release" for destructor
>  v3: adopt a more conventional global factory interface with a 
>  get_xdg_output() method, add some clarification and example.
> 
>  Makefile.am|   1 +
>  unstable/xdg-output/README |   4 +
>  unstable/xdg-output/xdg-output-unstable-v1.xml | 160 
> +
>  3 files changed, 165 insertions(+)
>  create mode 100644 unstable/xdg-output/README
>  create mode 100644 unstable/xdg-output/xdg-output-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index e693afa..6c696aa 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/xdg-output/xdg-output-unstable-v1.xml  
> \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xdg-output/README b/unstable/xdg-output/README
> new file mode 100644
> index 000..e42b711
> --- /dev/null
> +++ b/unstable/xdg-output/README
> @@ -0,0 +1,4 @@
> +xdg_output protocol
> +
> +Maintainers:
> +Olivier Fourdan <ofour...@redhat.com>
> diff --git a/unstable/xdg-output/xdg-output-unstable-v1.xml 
> b/unstable/xdg-output/xdg-output-unstable-v1.xml
> new file mode 100644
> index 000..74b5762
> --- /dev/null
> +++ b/unstable/xdg-output/xdg-output-unstable-v1.xml
> @@ -0,0 +1,160 @@
> +
> +
> +
> +  
> +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 aims at describing outputs in a way which is more in line
> +with the concept of an output on desktop oriented systems.
> +
> +Some information are more specific to the concept of an output for
> +a desktop oriented system and may not make sense in other applications,
> +such as IVI systems for example.
> +
> +Typically, the global compositor space on a desktop system is made of
> +a contiguous or overlapping set of rectangular regions.
> +
> +Some of the information provided in this protocol might be identical
> +to their counterparts already available from wl_output, in which case
> +the information provided by this protocol should be preferred to their
> +equivalent in wl_output. The

Re: [PATCH weston 3/3] libweston-desktop/xdg-shell: Check surface size against acknowledged size

[Jonas Ådahl]

On Wed, Jul 12, 2017 at 09:53:04AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic 
> 
> We were checking against the pending size, which lead some clients
> (simple-egl) to crash because they sent a buffer before acknowledging
> the latest configure event.
> 
> Signed-off-by: Quentin Glidic 
> ---
>  libweston-desktop/xdg-shell-v5.c | 6 --
>  libweston-desktop/xdg-shell-v6.c | 6 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/libweston-desktop/xdg-shell-v5.c 
> b/libweston-desktop/xdg-shell-v5.c
> index 0fb067ab..b32b7812 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -60,6 +60,7 @@ struct weston_desktop_xdg_surface {
>   } pending;
>   struct {
>   struct weston_desktop_xdg_surface_state state;
> + struct weston_size size;
>   } next;
>   struct {
>   struct weston_desktop_xdg_surface_state state;
> @@ -244,8 +245,8 @@ weston_desktop_xdg_surface_committed(struct 
> weston_desktop_surface *dsurface,
>   bool reconfigure = false;
>  
>   if (surface->next.state.maximized || surface->next.state.fullscreen)
> - reconfigure = surface->pending.size.width != wsurface->width ||
> -   surface->pending.size.height != wsurface->height;
> + reconfigure = surface->next.size.width != wsurface->width ||
> +   surface->next.size.height != wsurface->height;
>  
>   if (reconfigure) {
>   weston_desktop_xdg_surface_schedule_configure(surface, true);
> @@ -447,6 +448,7 @@ weston_desktop_xdg_surface_protocol_ack_configure(struct 
> wl_client *wl_client,
>   return;
>  
>   surface->next.state = surface->pending.state;
> + surface->next.size = surface->pending.size;
>  }
>  
>  static void
> diff --git a/libweston-desktop/xdg-shell-v6.c 
> b/libweston-desktop/xdg-shell-v6.c
> index db894d4a..f5e46daa 100644
> --- a/libweston-desktop/xdg-shell-v6.c
> +++ b/libweston-desktop/xdg-shell-v6.c
> @@ -95,6 +95,7 @@ struct weston_desktop_xdg_toplevel {
>   } pending;
>   struct {
>   struct weston_desktop_xdg_toplevel_state state;
> + struct weston_size size;
>   struct weston_size min_size, max_size;
>   } next;
>   struct {
> @@ -424,6 +425,7 @@ static void
>  weston_desktop_xdg_toplevel_ack_configure(struct weston_desktop_xdg_toplevel 
> *toplevel)
>  {
>   toplevel->next.state = toplevel->pending.state;
> + toplevel->next.size = toplevel->pending.size;
>  }
>  
>  static void
> @@ -626,8 +628,8 @@ weston_desktop_xdg_toplevel_committed(struct 
> weston_desktop_xdg_toplevel *toplev
>   return;
>  
>   if ((toplevel->next.state.maximized || toplevel->next.state.fullscreen) 
> &&
> - (toplevel->pending.size.width != wsurface->width ||
> -  toplevel->pending.size.height != wsurface->height)) {
> + (toplevel->next.size.width != wsurface->width ||
> +  toplevel->next.size.height != wsurface->height)) {

Unrelated to this patch, but wsurface->width/height should rather be the
geometry, not the size, because IIRC the surface size comes from the
buffer or wp_viewporter, while the next.size.width/height is window
geometry size. We only enforce the window geometry.

Shouldn't we also compare the serial here? If I understand things
correctly, "next" is the state+size the last time a client
ack_configure:ed a serial without any more pending one on the way.

So if that next state is fullscreen+WxH from when the client acked that
at some point in time, then we quickly went toplevel->fullscreen but
fullscreen on another output. In the intermediate state, the client acks
the old configure, thus we won't update next, end next will still be
fullscreen+WxH, while the surface size will be wxh (w != W, h != H).

Maybe could be fixed by adding the serial to the next and pending
structsand only enforce if the next (that is being committed) state is
the pending one.


Jonas

>   struct weston_desktop_client *client =
>   
> weston_desktop_surface_get_client(toplevel->base.desktop_surface);
>   struct wl_resource *client_resource =
> -- 
> 2.13.2
> 
> ___
> 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: [PATCH weston 2/3] libweston-desktop/xdg-shell: Add pending/next/current structs

[Jonas Ådahl]

On Wed, Jul 12, 2017 at 09:53:03AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic <sardemff7+...@sardemff7.net>
> 
> Signed-off-by: Quentin Glidic <sardemff7+...@sardemff7.net>

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

> ---
>  libweston-desktop/xdg-shell-v5.c | 80 ++---
>  libweston-desktop/xdg-shell-v6.c | 97 
> ++--
>  2 files changed, 98 insertions(+), 79 deletions(-)
> 
> diff --git a/libweston-desktop/xdg-shell-v5.c 
> b/libweston-desktop/xdg-shell-v5.c
> index 161a4891..0fb067ab 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -39,6 +39,13 @@
>  
>  #define WD_XDG_SHELL_PROTOCOL_VERSION 1
>  
> +struct weston_desktop_xdg_surface_state {
> + bool maximized;
> + bool fullscreen;
> + bool resizing;
> + bool activated;
> +};
> +
>  struct weston_desktop_xdg_surface {
>   struct wl_resource *resource;
>   struct weston_desktop_surface *surface;
> @@ -47,13 +54,16 @@ struct weston_desktop_xdg_surface {
>   struct wl_event_source *add_idle;
>   struct wl_event_source *configure_idle;
>   uint32_t configure_serial;
> - struct weston_size pending_size;
>   struct {
> - bool maximized;
> - bool fullscreen;
> - bool resizing;
> - bool activated;
> - } pending_state, next_state, state;
> + struct weston_desktop_xdg_surface_state state;
> + struct weston_size size;
> + } pending;
> + struct {
> + struct weston_desktop_xdg_surface_state state;
> + } next;
> + struct {
> + struct weston_desktop_xdg_surface_state state;
> + } current;
>   bool has_next_geometry;
>   struct weston_geometry next_geometry;
>  };
> @@ -92,26 +102,26 @@ weston_desktop_xdg_surface_send_configure(void *data)
>   
> wl_display_next_serial(weston_desktop_get_display(surface->desktop));
>  
>   wl_array_init();
> - if (surface->pending_state.maximized) {
> + if (surface->pending.state.maximized) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_MAXIMIZED;
>   }
> - if (surface->pending_state.fullscreen) {
> + if (surface->pending.state.fullscreen) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_FULLSCREEN;
>   }
> - if (surface->pending_state.resizing) {
> + if (surface->pending.state.resizing) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_RESIZING;
>   }
> - if (surface->pending_state.activated) {
> + if (surface->pending.state.activated) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_ACTIVATED;
>   }
>  
>   xdg_surface_send_configure(surface->resource,
> -surface->pending_size.width,
> -surface->pending_size.height,
> +surface->pending.size.width,
> +surface->pending.size.height,
>  ,
>  surface->configure_serial);
>  
> @@ -124,21 +134,21 @@ weston_desktop_xdg_surface_state_compare(struct 
> weston_desktop_xdg_surface *surf
>   struct weston_surface *wsurface =
>   weston_desktop_surface_get_surface(surface->surface);
>  
> - if (surface->pending_state.activated != surface->state.activated)
> + if (surface->pending.state.activated != 
> surface->current.state.activated)
>   return false;
> - if (surface->pending_state.fullscreen != surface->state.fullscreen)
> + if (surface->pending.state.fullscreen != 
> surface->current.state.fullscreen)
>   return false;
> - if (surface->pending_state.maximized != surface->state.maximized)
> + if (surface->pending.state.maximized != 
> surface->current.state.maximized)
>   return false;
> - if (surface->pending_state.resizing != surface->state.resizing)
> + if (surface->pending.state.resizing != surface->current.state.resizing)
>   return false;
>  
> - if (wsurface->width == surface->pending_size.width &&
> - wsurface->height == surface->pending_size.height)
> + if (wsurface->width == surface->pending.size.width &&
> + wsurface->height == surface->pending.size.height)
> 

Re: [PATCH weston 1/3] libweston-desktop/xdg-shell: Rename requested_ to pending_

[Jonas Ådahl]

On Wed, Jul 12, 2017 at 09:53:02AM +0200, Quentin Glidic wrote:
> From: Quentin Glidic <sardemff7+...@sardemff7.net>
> 
> Signed-off-by: Quentin Glidic <sardemff7+...@sardemff7.net>

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

> ---
>  libweston-desktop/xdg-shell-v5.c | 56 +++---
>  libweston-desktop/xdg-shell-v6.c | 58 
> 
>  2 files changed, 57 insertions(+), 57 deletions(-)
> 
> diff --git a/libweston-desktop/xdg-shell-v5.c 
> b/libweston-desktop/xdg-shell-v5.c
> index 1ec796e1..161a4891 100644
> --- a/libweston-desktop/xdg-shell-v5.c
> +++ b/libweston-desktop/xdg-shell-v5.c
> @@ -47,13 +47,13 @@ struct weston_desktop_xdg_surface {
>   struct wl_event_source *add_idle;
>   struct wl_event_source *configure_idle;
>   uint32_t configure_serial;
> - struct weston_size requested_size;
> + struct weston_size pending_size;
>   struct {
>   bool maximized;
>   bool fullscreen;
>   bool resizing;
>   bool activated;
> - } requested_state, next_state, state;
> + } pending_state, next_state, state;
>   bool has_next_geometry;
>   struct weston_geometry next_geometry;
>  };
> @@ -92,26 +92,26 @@ weston_desktop_xdg_surface_send_configure(void *data)
>   
> wl_display_next_serial(weston_desktop_get_display(surface->desktop));
>  
>   wl_array_init();
> - if (surface->requested_state.maximized) {
> + if (surface->pending_state.maximized) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_MAXIMIZED;
>   }
> - if (surface->requested_state.fullscreen) {
> + if (surface->pending_state.fullscreen) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_FULLSCREEN;
>   }
> - if (surface->requested_state.resizing) {
> + if (surface->pending_state.resizing) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_RESIZING;
>   }
> - if (surface->requested_state.activated) {
> + if (surface->pending_state.activated) {
>   s = wl_array_add(, sizeof(uint32_t));
>   *s = XDG_SURFACE_STATE_ACTIVATED;
>   }
>  
>   xdg_surface_send_configure(surface->resource,
> -surface->requested_size.width,
> -surface->requested_size.height,
> +surface->pending_size.width,
> +surface->pending_size.height,
>  ,
>  surface->configure_serial);
>  
> @@ -124,21 +124,21 @@ weston_desktop_xdg_surface_state_compare(struct 
> weston_desktop_xdg_surface *surf
>   struct weston_surface *wsurface =
>   weston_desktop_surface_get_surface(surface->surface);
>  
> - if (surface->requested_state.activated != surface->state.activated)
> + if (surface->pending_state.activated != surface->state.activated)
>   return false;
> - if (surface->requested_state.fullscreen != surface->state.fullscreen)
> + if (surface->pending_state.fullscreen != surface->state.fullscreen)
>   return false;
> - if (surface->requested_state.maximized != surface->state.maximized)
> + if (surface->pending_state.maximized != surface->state.maximized)
>   return false;
> - if (surface->requested_state.resizing != surface->state.resizing)
> + if (surface->pending_state.resizing != surface->state.resizing)
>   return false;
>  
> - if (wsurface->width == surface->requested_size.width &&
> - wsurface->height == surface->requested_size.height)
> + if (wsurface->width == surface->pending_size.width &&
> + wsurface->height == surface->pending_size.height)
>   return true;
>  
> - if (surface->requested_size.width == 0 &&
> - surface->requested_size.height == 0)
> + if (surface->pending_size.width == 0 &&
> + surface->pending_size.height == 0)
>   return true;
>  
>   return false;
> @@ -150,17 +150,17 @@ weston_desktop_xdg_surface_schedule_configure(struct 
> weston_desktop_xdg_surface
>  {
>   struct wl_display *display = 
> weston_desktop_get_display(surface->desktop);
>   struct wl_event_loop *loop = wl_display_get_event_loop(display);
> - bool requested_same =
>

Re: [PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

On Tue, Jul 11, 2017 at 11:30:11PM +0100, David Edmundson wrote:
> Can you clarify something here.
> 
> >A newly-unmapped surface is considered to have met condition (1) out
> +  of the 3 required conditions for mapping a surface if its role
> surface
> +  has not been destroyed.
> 
> Attaching a null buffer unmaps the surface
> Unmapping the surface resets the state
> 
> The above implies if we haven't deleted the xdg_toplevel we don't need to
> call get_toplevel again.
> 
> When the client wants to remap, what prompts the server to send a new
> configure event? If it doesn't, how does the client know what the state is
> before it reattaches a buffer.

The idea is that having unmapped by null-attach means the
xdg_surface/xdg_toplevel etc is reset to the exact same state that it
had when first created, thus to map again, one would do what one would
do the same as when mapping it for the first time: set up the state
(set_title, (set_maximized?), set_app_id), commit, wait for configure,
then attach a new buffer given the configure event data.


Jonas

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

[ANNOUNCE] wayland-protocols 1.8 and wayland-protocols 1.9

[Jonas Ådahl]

wayland-protocols 1.8 has been available for some time wayland-protocols 1.9 is
now available.

Version 1.8 bumped the linux dmabuf protocol version, introducing a new request
for creating a buffer from a dmabuf without having to wait for an event, as
well as an event advertising supported fourcc modifiers along with the
supported formats.

A pkg-config file meant for when wayland-protocols is used as a git
submodule (or otherwise not installed) was added.

Various grammar fixes and clarifications were also included in this release.


Version 1.9 introduced two new unstable protocols:

 - Keyboard shortcut inhibitation - a protocol meant for making it possible for
   virtual machine viewers, remote desktop clients etc, to be able to forward
   keyboard combinations such as Alt-Tab etc.
 - Xwayland keyboard grabbing - a protocol specifically targeted at enabling
   Xwayland to implement keyboard grabs.

See the corresponding XML files for details.


Here is the shortlog for 1.8:

Bryce Harrington (3):
  input-method: Correct grammar
  input-method: Lead with a verb in request descriptions
  idle-inhibit: Lead with a verb in request description

Daniel Stone (2):
  linux-dmabuf: Bump main protocol version
  Bump version to 1.8

Mike Blumenkrantz (1):
  xdg-shell: require popups to intersect with or be adjacent to parent 
surfaces

Reynaldo H. Verdejo Pinochet (1):
  buildsystem: add -uninstalled.pc pkg-config file

Varad Gautam (3):
  linux-dmabuf: clarify format event description
  linux-dmabuf: add immediate dmabuf import path
  linux-dmabuf: advertise format modifiers with modifier event

Yong Bakos (6):
  text-input: Fix indentation and paragraph whitespace
  text-input: Rename text-input to text_input
  text-input: Correct grammar
  xdg-shell: Correct grammar
  (multiple): Remove inconsistent line breaks
  linux-dmabuf-unstable: Use standard copyright notice


Here is the shortlog for 1.9:

Jonas Ådahl (1):
  configure.ac: Bump version to 1.9

Olivier Fourdan (2):
  Introduce keyboard grabbing protocol for Xwayland
  Add keyboard shortcuts inhibitor


git tag: 1.8

http://wayland.freedesktop.org/releases/wayland-protocols-1.8.tar.xz
MD5:  769f93b312b1323a8012565c3973cf7d  wayland-protocols-1.8.tar.xz
SHA1: 8a0f548d85476e4b289373c3e738e3d5a97e5a8c  wayland-protocols-1.8.tar.xz
SHA256: e3fa5f2812cfec3c1c2573bd34adfe37d4d8950dba572d9ec6c52adcc5fe4b9a  
wayland-protocols-1.8.tar.xz
PGP:  http://wayland.freedesktop.org/releases/wayland-protocols-1.8.tar.xz.sig

git tag: 1.9

http://wayland.freedesktop.org/releases/wayland-protocols-1.9.tar.xz
MD5:  d9a3c93aac1f423501a33e7a9804b3b3  wayland-protocols-1.9.tar.xz
SHA1: 66954853df10e144bb3c4f6facf0e7a49ff391e2  wayland-protocols-1.9.tar.xz
SHA256: 666b72de30ca3b70c2b54ccc9e8114cb520e76db224c816b5e23501099174f75  
wayland-protocols-1.9.tar.xz
PGP:  http://wayland.freedesktop.org/releases/wayland-protocols-1.9.tar.xz.sig
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v8 2/2] Add keyboard shortcuts inhibitor

[Jonas Ådahl]

On Fri, Jun 30, 2017 at 06:13:52PM +0200, Olivier Fourdan wrote:
> 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 <ofour...@redhat.com>
> Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

and push this one as well.


Jonas

> ---
>  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 <ofour...@redhat.com>
> 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
> +ch

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

[Jonas Ådahl]

On Fri, Jun 30, 2017 at 06:10:01PM +0200, Olivier Fourdan wrote:
> 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 <ofour...@redhat.com>
> Reviewed-by: Peter Hutterer <peter.hutte...@who-t.net>

Reviewed-by: Jonas Ådahl <jad...@gmail.com>

and pushed.

Thanks!

> ---
>  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 <ofour...@redhat.com>
> 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 do

[PATCH wayland 1/3] Pass input/output files as arguments to wayland-scanner

[Jonas Ådahl]

When input/output files are passed as arguments to wayland-scanner,
instead of using stdin/stdout, warning and error messages will contain
the file name, together with line number, of the warning/error. Doing
this helps IDEs jump to the correct line.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 Makefile.am| 6 +++---
 src/scanner.mk | 6 +++---
 wayland-scanner.mk | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index d0c8bd3..fdc5689 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -97,13 +97,13 @@ nodist_libwayland_client_la_SOURCES =   \
 pkgconfig_DATA += src/wayland-client.pc src/wayland-server.pc
 
 protocol/%-protocol.c : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code < $< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) code $< $@
 
 protocol/%-server-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header $< 
$@
 
 protocol/%-client-protocol.h : $(top_srcdir)/protocol/%.xml
-   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header < 
$< > $@
+   $(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) client-header $< 
$@
 
 protocol/%-server-protocol-core.h : $(top_srcdir)/protocol/%.xml
$(AM_V_GEN)$(MKDIR_P) $(dir $@) && $(wayland_scanner) server-header -c 
< $< > $@
diff --git a/src/scanner.mk b/src/scanner.mk
index 1b6963c..e01b839 100644
--- a/src/scanner.mk
+++ b/src/scanner.mk
@@ -1,8 +1,8 @@
 %-protocol.c : $(protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) code $< $@
 
 %-server-protocol.h : $(protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) server-header $< $@
 
 %-client-protocol.h : $(protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) client-header < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) client-header $< $@
diff --git a/wayland-scanner.mk b/wayland-scanner.mk
index 0a72062..c174e6b 100644
--- a/wayland-scanner.mk
+++ b/wayland-scanner.mk
@@ -1,8 +1,8 @@
 %-protocol.c : $(wayland_protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) code < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) code $< $@
 
 %-server-protocol.h : $(wayland_protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) server-header < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) server-header $< $@
 
 %-client-protocol.h : $(wayland_protocoldir)/%.xml
-   $(AM_V_GEN)$(wayland_scanner) client-header < $< > $@
+   $(AM_V_GEN)$(wayland_scanner) client-header $< $@
-- 
2.13.0

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

[PATCH wayland 3/3] tests: Add scanner symbol prefix test

[Jonas Ådahl]

Test that it is possible to implement and use an interface with a
symbol prefix.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 .gitignore|   5 ++
 Makefile.am   |  30 +++-
 tests/symbol-prefix-test-client.c |  77 
 tests/symbol-prefix-test-server.c | 145 ++
 4 files changed, 255 insertions(+), 2 deletions(-)
 create mode 100644 tests/symbol-prefix-test-client.c
 create mode 100644 tests/symbol-prefix-test-server.c

diff --git a/.gitignore b/.gitignore
index 8da9861..d2f59e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -45,3 +45,8 @@ exec-fd-leak-checker
 fixed-benchmark
 /wayland-scanner
 protocol/*.[ch]
+prefixed-wayland-protocol.c
+prefixed-wayland-server-protocol-core.h
+prefixed-wayland-client-protocol-core.h
+symbol-prefix-test-server
+symbol-prefix-test-client
diff --git a/Makefile.am b/Makefile.am
index fdc5689..dcb93a6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -114,7 +114,9 @@ protocol/%-client-protocol-core.h : 
$(top_srcdir)/protocol/%.xml
 BUILT_SOURCES =\
$(nodist_libwayland_server_la_SOURCES)  \
$(nodist_libwayland_client_la_SOURCES)  \
-   $(nodist_headers_test_SOURCES)
+   $(nodist_headers_test_SOURCES)  \
+   $(nodist_symbol_prefix_test_server_SOURCES) \
+   $(nodist_symbol_prefix_test_client_SOURCES)
 
 CLEANFILES = $(BUILT_SOURCES) doc/doxygen/doxygen_sqlite3.db
 DISTCLEANFILES = src/wayland-version.h
@@ -164,7 +166,11 @@ built_test_programs =  \
message-test\
headers-test\
compositor-introspection-test   \
-   protocol-logger-test
+   protocol-logger-test\
+   symbol-prefix-test-server
+
+built_test_program_helpers =   \
+   symbol-prefix-test-client
 
 if ENABLE_CPP_TEST
 built_test_programs += cpp-compile-test
@@ -172,6 +178,7 @@ endif
 
 AM_TESTS_ENVIRONMENT = \
export WAYLAND_SCANNER='$(top_builddir)/wayland-scanner'\
+   export TOP_BUILDDIR='$(top_builddir)'   \
TEST_DATA_DIR='$(top_srcdir)/tests/data'\
TEST_OUTPUT_DIR='$(top_builddir)/tests/output'  \
SED=$(SED)  \
@@ -182,6 +189,7 @@ TESTS = $(built_test_programs)  \
 
 noinst_PROGRAMS =  \
$(built_test_programs)  \
+   $(built_test_program_helpers)   \
exec-fd-leak-checker\
fixed-benchmark
 
@@ -200,6 +208,14 @@ libtest_runner_la_LIBADD = \
libwayland-server.la\
-lrt -ldl $(FFI_LIBS)
 
+prefixed-wayland-protocol.c : protocol/wayland.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -p prefix_ code $< $@
+
+prefixed-wayland-server-protocol-core.h : protocol/wayland.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -p prefix_ server-header $< $@
+
+prefixed-wayland-client-protocol-core.h : protocol/wayland.xml
+   $(AM_V_GEN)$(wayland_scanner) -c -p prefix_ client-header $< $@
 
 array_test_SOURCES = tests/array-test.c
 array_test_LDADD = libtest-runner.la
@@ -245,6 +261,16 @@ headers_test_LDADD = libtest-runner.la
 nodist_headers_test_SOURCES =  \
protocol/wayland-server-protocol-core.h \
protocol/wayland-client-protocol-core.h
+symbol_prefix_test_server_SOURCES = tests/symbol-prefix-test-server.c
+nodist_symbol_prefix_test_server_SOURCES = \
+   prefixed-wayland-protocol.c \
+   prefixed-wayland-server-protocol-core.h
+symbol_prefix_test_server_LDADD = libtest-runner.la
+symbol_prefix_test_client_SOURCES = tests/symbol-prefix-test-client.c
+nodist_symbol_prefix_test_client_SOURCES = \
+   prefixed-wayland-protocol.c \
+   prefixed-wayland-client-protocol-core.h
+symbol_prefix_test_client_LDADD = libtest-runner.la
 
 if ENABLE_CPP_TEST
 cpp_compile_test_SOURCES = tests/cpp-compile-test.cpp
diff --git a/tests/symbol-prefix-test-client.c 
b/tests/symbol-prefix-test-client.c
new file mode 100644
index 000..6de1f53
--- /dev/null
+++ b/tests/symbol-prefix-test-client.c
@@ -0,0 +1,77 @@
+/*
+ * 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 per

[PATCH wayland 2/3] scanner: Allow adding a prefix to exported symbols

[Jonas Ådahl]

Two different protocols may use interfaces with identical names.
Implementing support for both those protocols would result in symbol
clashes, as wayland-scanner generates symbols from the interface names.

Make it possible to avoiding these clashes by adding a way to add a
prefix to the symbols generated by wayland-scanner. Implementations
(servers and clients) can then use these prefix:ed symbols to implement
different objects with the same name.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---

Something like this would be needed if a compositor/client wants to implement
xdg-shell unstable v5 alongside xdg-shell stable, unless we want to rename all
our xdg-shell interfaces. Implementing xdg-shell unstable v6 alongside
xdg-shell stable does not have this issue.

See issue raised here:
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034380.html


Jonas


 src/scanner.c | 94 ++-
 1 file changed, 73 insertions(+), 21 deletions(-)

diff --git a/src/scanner.c b/src/scanner.c
index 517068c..00b5a84 100644
--- a/src/scanner.c
+++ b/src/scanner.c
@@ -228,6 +228,7 @@ struct entry {
 struct parse_context {
struct location loc;
XML_Parser parser;
+   char *symbol_prefix;
struct protocol *protocol;
struct interface *interface;
struct message *message;
@@ -1041,7 +1042,9 @@ emit_type(struct arg *a)
 }
 
 static void
-emit_stubs(struct wl_list *message_list, struct interface *interface)
+emit_stubs(struct parse_context *ctx,
+  struct wl_list *message_list,
+  struct interface *interface)
 {
struct message *m;
struct arg *a, *ret;
@@ -1168,11 +1171,12 @@ emit_stubs(struct wl_list *message_list, struct 
interface *interface)
printf("\tstruct wl_proxy *%s;\n\n"
   "\t%s = wl_proxy_marshal_constructor("
   "(struct wl_proxy *) %s,\n"
-  "\t\t\t %s_%s, &%s_interface",
+  "\t\t\t %s_%s, &%s%s_interface",
   ret->name, ret->name,
   interface->name,
   interface->uppercase_name,
   m->uppercase_name,
+  ctx->symbol_prefix,
   ret->interface_name);
} else {
/* No args have type="new_id" */
@@ -1507,7 +1511,7 @@ emit_mainpage_blurb(const struct protocol *protocol, enum 
side side)
 }
 
 static void
-emit_header(struct protocol *protocol, enum side side)
+emit_header(struct parse_context *ctx, struct protocol *protocol, enum side 
side)
 {
struct interface *i, *i_next;
struct wl_array types;
@@ -1576,7 +1580,7 @@ emit_header(struct protocol *protocol, enum side side)
format_text_to_comment(i->description->text, false);
printf(" */\n");
printf("extern const struct wl_interface "
-  "%s_interface;\n", i->name);
+  "%s%s_interface;\n", ctx->symbol_prefix, i->name);
}
 
printf("\n");
@@ -1596,7 +1600,7 @@ emit_header(struct protocol *protocol, enum side side)
emit_opcodes(>request_list, i);
emit_opcode_versions(>event_list, i);
emit_opcode_versions(>request_list, i);
-   emit_stubs(>request_list, i);
+   emit_stubs(ctx, >request_list, i);
}
 
free_interface(i);
@@ -1619,7 +1623,9 @@ emit_null_run(struct protocol *protocol)
 }
 
 static void
-emit_types(struct protocol *protocol, struct wl_list *message_list)
+emit_types(struct parse_context *ctx,
+  struct protocol *protocol,
+  struct wl_list *message_list)
 {
struct message *m;
struct arg *a;
@@ -1639,7 +1645,8 @@ emit_types(struct protocol *protocol, struct wl_list 
*message_list)
case NEW_ID:
case OBJECT:
if (a->interface_name)
-   printf("\t&%s_interface,\n",
+   printf("\t&%s%s_interface,\n",
+  ctx->symbol_prefix,
   a->interface_name);
else
printf("\tNULL,\n");
@@ -1713,7 +1720,7 @@ emit_messages(struct wl_list *message_list,
 }
 
 static void
-emit_code(struct protocol *protocol)
+emit_code(struct parse_context *ctx, struct protocol 

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

[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

[PATCH wayland-protocols v2 13/13] xdg-shell/positioner: Clarify flip semantics with anchor offset

[Jonas Ådahl]

While there is no currently known usages of setting an anchor offset on
the same axis as the 'flip' constraint action is set, it must still be
specified so compositors behave the same.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/xdg-shell.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 366c7a6..4cad982 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -298,6 +298,10 @@
  surface is constrained, the gravity is 'bottom' and the anchor is
  'bottom', change the gravity to 'top' and the anchor to 'top'.
 
+ The adjusted position is calculated given the original anchor
+ rectangle and offset, but with the new flipped anchor and gravity
+ values.
+
  If the adjusted position also ends up being constrained, the resulting
  position of the flip_y adjustment will be the one before the
  adjustment.
-- 
2.13.0

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

[PATCH wayland-protocols v2 10/13] xdg-shell/popup: Allow custom parent by passing null as parent

[Jonas Ådahl]

Allow using some other protocol (custom, or future xdg_* based) to set
up the parent-child relationship of a popup. This allows future
protocols to use xdg_popup when mapping popups over surfaces not based
on xdg_surface.

An example use case for this is the window menu, where a shells UI
client can use xdg_popup to create popup menus over windows it does not
have a xdg_surface of by having a custom protocol setting up the proper
parent-child relationship.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 4c4c66b..77ce886 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -424,14 +424,17 @@
 
 
   
-   This creates an xdg_popup object for the given xdg_surface and gives the
-   associated wl_surface the xdg_popup role.
+   This creates an xdg_popup object for the given xdg_surface and gives
+   the associated wl_surface the xdg_popup role.
+
+   If null is passed as a parent, a parent surface must be specified using
+   some other protocol, before committing the initial state.
 
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
   
   
-  
+  
   
 
 
-- 
2.13.0

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

[PATCH wayland-protocols v2 09/13] xdg-shell/toplevel: Chain multiple parent-child relationships

[Jonas Ådahl]

Change the semantics of xdg_toplevel.set_parent to allow chaining
multiple parent-child relationships together, while allowing
arbitrarily unmapping parents, while keeping what is left over of the
chain intact.

This makes things easier to manage when parent-child relationships
cross client borders, for example when using xdg_foreign.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index b119cff..4c4c66b 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -540,9 +540,8 @@
 
 
   
-   Set the "parent" of this surface. This window should be stacked
-   above a parent. The parent surface must be mapped as long as this
-   surface is mapped.
+   Set the "parent" of this surface. This surface should be stacked
+   this above the parent surface and all other ancestor surfaces.
 
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
@@ -551,6 +550,12 @@
Setting a null parent for a child window removes any parent-child
relationship for the child. Setting a null parent for a window which
currently has no parent is a no-op.
+
+   If the parent is unmapped then its children are managed as
+   though the parent of the now-unmapped parent has become the
+   parent of this surface. If no parent exists for the now-unmapped
+   parent then the children are managed as though they have no
+   parent surface.
   
   
 
-- 
2.13.0

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

[PATCH wayland-protocols v2 12/13] xdg-shell/positioner: Replace edge bitfield with extended enum

[Jonas Ådahl]

From: David Edmundson <davidedmund...@kde.org>

Bitfields allowed for impossible combinations of anchor edges, such as
being on the left and right edge. Use of explicit enumerations means we
don't need to handle that case.

Signed-off-by: David Edmundson <davidedmund...@kde.org>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/xdg-shell.xml | 77 +++---
 1 file changed, 34 insertions(+), 43 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 29a2b46..366c7a6 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -179,63 +179,54 @@
   
 
 
-
-  
-  
-  
-  
-  
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
 
 
 
-  
-   Defines a set of edges for the anchor rectangle. These are used to
-   derive an anchor point that the child surface will be positioned
-   relative to. If two orthogonal edges are specified (e.g. 'top' and
-   'left'), then the anchor point will be the intersection of the edges
-   (e.g. the top left position of the rectangle); otherwise, the derived
-   anchor point will be centered on the specified edge, or in the center of
-   the anchor rectangle if no edge is specified.
-
-   If two parallel anchor edges are specified (e.g. 'left' and 'right'),
-   the invalid_input error is raised.
+  
+   Defines the anchor point for the anchor rectangle. The specified anchor
+   is used derive an anchor point that the child surface will be
+   positioned relative to. If a corner anchor is set (e.g. 'top_left' or
+   'bottom_right'), the anchor point will be at the specified corner;
+   otherwise, the derived anchor point will be centered on the specified
+   edge, or in the center of the anchor rectangle if no edge is specified.
   
   
+  summary="anchor"/>
 
 
-
-  
-  
-  
-  
-  
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
 
 
 
   
Defines in what direction a surface should be positioned, relative to
-   the anchor point of the parent surface. If two orthogonal gravities are
-   specified (e.g. 'bottom' and 'right'), then the child surface will be
-   placed in the specified direction; otherwise, the child surface will be
-   centered over the anchor point on any axis that had no gravity
-   specified.
-
-   If two parallel gravities are specified (e.g. 'left' and 'right'), the
-   invalid_input error is raised.
+   the anchor point of the parent surface. If a corner gravity is
+   specified (e.g. 'bottom_right' or 'top_left'), then the child surface
+   will be placed towards the specified gravity; otherwise, the child
+   surface will be centered over the anchor point on any axis that had no
+   gravity specified.
   
   
+  summary="gravity direction"/>
 
 
 
-- 
2.13.0

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

[PATCH wayland-protocols v2 11/13] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

From: Mike Blumenkrantz <zm...@osg.samsung.com>

ensure that this is as precise and explicit as possible for all useful
cases and also define previously-unspecified behavior

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/xdg-shell.xml | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 77ce886..29a2b46 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -391,11 +391,20 @@
   manipulate a buffer prior to the first xdg_surface.configure call must
   also be treated as errors.
 
-  For a surface to be mapped by the compositor, the following conditions
-  must be met: (1) the client has assigned a xdg_surface based role to the
-  surface, (2) the client has set and committed the xdg_surface state and
-  the role dependent state to the surface and (3) the client has committed 
a
-  buffer to the surface.
+  Mapping an xdg_surface-based role surface is defined as making it
+  possible for the surface to be shown by the compositor. Note that
+  a mapped surface is not guaranteed to be visible once it is mapped.
+
+  For an xdg_surface to be mapped by the compositor, the following
+  conditions must be met:
+  (1) the client has assigned an xdg_surface-based role to the surface
+  (2) the client has set and committed the xdg_surface state and the
+ role-dependent state to the surface
+  (3) the client has committed a buffer to the surface
+
+  A newly-unmapped surface is considered to have met condition (1) out
+  of the 3 required conditions for mapping a surface if its role surface
+  has not been destroyed.
 
 
 
@@ -531,13 +540,20 @@
   fullscreen, and minimize, set application-specific metadata like title 
and
   id, and well as trigger user interactive operations such as interactive
   resize and move.
+
+  Unmapping an xdg_toplevel means that the surface cannot be shown
+  by the compositor until it is explicitly mapped again.
+  All active operations (e.g., move, resize) are canceled and all
+  attributes (e.g. title, state, stacking, ...) are discarded for
+  an xdg_toplevel surface when it is unmapped.
+
+  Attaching a null buffer to a toplevel unmaps the surface.
 
 
 
   
-   Unmap and destroy the window. The window will be effectively
-   hidden from the user's point of view, and all state like
-   maximization, fullscreen, and so on, will be lost.
+   This request destroys the role surface and unmaps the surface;
+   see "Unmapping" behavior in interface section for details.
   
 
 
-- 
2.13.0

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

[PATCH wayland-protocols v2 08/13] xdg-shell/toplevel: Clarify xdg_toplevel.set_parent(null)

[Jonas Ådahl]

Setting a null-surface as a toplevel parent should unset the
parent-child relationship. This was not specified, so lets do that.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index c7dd6dd..b119cff 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -547,6 +547,10 @@
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
is raised.
+
+   Setting a null parent for a child window removes any parent-child
+   relationship for the child. Setting a null parent for a window which
+   currently has no parent is a no-op.
   
   
 
-- 
2.13.0

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

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

[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.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 1c0f924..da8d6d4 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -1,5 +1,5 @@
 
-
+
 
   
 Copyright © 2008-2013 Kristian Høgsberg
@@ -27,9 +27,9 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
-  xdg_shell allows clients to turn a wl_surface into a "real window"
+  xdg_wm_base allows clients to turn a wl_surface into a "real window"
   which can be dragged, resized, stacked, and moved around by the
   user. Everything about this interface is suited towards traditional
   desktop environments.
@@ -38,7 +38,7 @@
 
   
   
+summary="xdg_wm_base was destroyed before children"/>
   
   
 
 
-  
-   Destroy this xdg_shell object.
+  
+   Destroy this xdg_wm_base object.
 
-   Destroying a bound xdg_shell object while there are surfaces
-   still alive created by this xdg_shell object instance is illegal
+   Destroying a bound xdg_wm_base object while there are surfaces
+   still alive created by this xdg_wm_base object instance is illegal
and will result in a protocol error.
   
 
@@ -65,7 +65,7 @@
surfaces relative to some parent surface. See the interface description
and xdg_surface.get_popup for details.
   
-  
+  
 
 
 
@@ -82,14 +82,14 @@
See the documentation of xdg_surface for more details about what an
xdg_surface is and how it is used.
   
-  
+  
   
 
 
 
   
A client must respond to a ping event with a pong request or
-   the client may be deemed unresponsive. See xdg_shell.ping.
+   the client may be deemed unresponsive. See xdg_wm_base.ping.
   
   
 
@@ -98,7 +98,7 @@
   
The ping event asks the client if it's still alive. Pass the
serial specified in the event back to the compositor by sending
-   a "pong" request back with the specified serial. See xdg_shell.ping.
+   a "pong" request back with the specified serial. See xdg_wm_base.ping.
 
Compositors can use this to determine if the client is still
alive. It's unspecified what will happen if the client doesn't
@@ -106,13 +106,13 @@
try to respond in a reasonable amount of time.
 
A compositor is free to ping in any way it wants, but a client must
-   always respond to any xdg_shell object it created.
+   always respond to any xdg_wm_base object it created.
   
   
 
   
 
-  
+  
 
   The xdg_positioner provides a collection of rules for the placement of a
   child surface relative to a parent surface. Rules can be defined to 
ensure
@@ -361,7 +361,7 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -416,7 +416,7 @@
See the documentation of xdg_toplevel for more details about what an
xdg_toplevel is and how it is used.
   
-  
+  
 
 
 
@@ -427,9 +427,9 @@
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
   
-  
-  
-  
+  
+  
+  
 
 
 
@@ -513,7 +513,7 @@
 
   
 
-  
+  
 
   This interface defines an xdg_surface role which allows a surface to,
   among other things, set window-like properties such as maximize,
@@ -540,7 +540,7 @@
"auxiliary" surfaces, so that the parent is raised when the dialog
is raised.
   
-  
+  
 
 
 
@@ -913,7 +913,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.13.0

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

[PATCH wayland-protocols v2 06/13] xdg-shell: Replace 'monitor' with 'output'

[Jonas Ådahl]

There is no such thing as 'monitor' in Wayland, only outputs.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index e64bd3e..3d19f62 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -255,7 +255,7 @@
   

  Don't alter the surface position even if it is constrained on some
- axis, for example partially outside the edge of a monitor.
+ axis, for example partially outside the edge of an output.

   
   
@@ -847,7 +847,7 @@
 
 
 
-  
+  
Make the surface fullscreen.
 
You can specify an output that you would prefer to be fullscreen.
-- 
2.13.0

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

[PATCH wayland-protocols v2 01/13] Add xdg-shell to stable/

[Jonas Ådahl]

Add a copy of xdg-shell unstable v6 to stable/xdg-shell/xdg-shell.xml.
Folliwing this commit, it will go through a set of changes, before
being declared stable.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/README|5 +
 stable/xdg-shell/xdg-shell.xml | 1044 
 2 files changed, 1049 insertions(+)
 create mode 100644 stable/xdg-shell/README
 create mode 100644 stable/xdg-shell/xdg-shell.xml

diff --git a/stable/xdg-shell/README b/stable/xdg-shell/README
new file mode 100644
index 000..2769abb
--- /dev/null
+++ b/stable/xdg-shell/README
@@ -0,0 +1,5 @@
+xdg shell protocol
+
+Maintainers:
+Jonas Ådahl <jad...@gmail.com>
+Mike Blumenkrantz <zm...@osg.samsung.com>
diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
new file mode 100644
index 000..1c0f924
--- /dev/null
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -0,0 +1,1044 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 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.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards traditional
+  desktop environments.
+
+
+
+  
+  
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Create a positioner object. A positioner object is used to position
+   surfaces relative to some parent surface. See the interface description
+   and xdg_surface.get_popup for details.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface. While xdg_surface
+   itself is not a role, the corresponding surface may only be assigned
+   a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
+
+   This creates an xdg_surface for the given surface. An xdg_surface is
+   used as basis to define a role to a given surface, such as xdg_toplevel
+   or xdg_popup. It also manages functionality shared between xdg_surface
+   based surface roles.
+
+   See the documentation of xdg_surface for more details about what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   A client must respond to a ping event with a pong request or
+   the client may be deemed unresponsive. See xdg_shell.ping.
+  
+  
+
+
+
+  
+   The ping event asks the client if it's still alive. Pass the
+   serial specified in the event back to the compositor by sending
+   a "pong" request back with the specified serial. See xdg_shell.ping.
+
+   Compositors can use this to determine if the client is still
+   alive. It's unspecified what will happen if the client doesn't
+   respond to the ping request, or in what timeframe. Clients should
+   try to respond in a reasonable amount of time.
+
+   A compositor is free to ping in any way it wants, but a client must
+   always respond to any xdg_shell object it created.
+  
+  
+
+  
+
+  
+
+  The xdg_positioner provides a collection of rules for the placement of a
+  child surface relative to a parent surface. Rules can be defined to 
ensure
+  the child surface remains within the visible area's borders, and to
+  specify how the child surface changes its position, such as sliding along
+ 

[PATCH wayland-protocols v2 04/13] xdg-shell: Reword the xdg_wm_base introduction

[Jonas Ådahl]

Don't refer to things as "traditional desktop" as it is not defined
nor clear what that refers to; instead reword things in a more explicit
way. A reason for this is that xdg-shell is not strictly meant only for
traditional window stacking based desktop environments, but should be
equally suitable for stacking, tiling and potentially other styles as
well.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---

Changes since v1:

Commit message was updated - less explicit was changed to more explicit, since
it did list things explicitly instead of relying on the term "traditional
desktop" which is arguably more explicit.

 stable/xdg-shell/xdg-shell.xml | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index ec70073..2be4599 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -31,10 +31,11 @@
 
   
 
-  xdg_wm_base allows clients to turn a wl_surface into a "real window"
-  which can be dragged, resized, stacked, and moved around by the
-  user. Everything about this interface is suited towards traditional
-  desktop environments.
+  The xdg_wm_base interface is exposed as a global object enabling clients
+  to turn their wl_surfaces into windows in a desktop environment. It
+  defines the basic functionality needed for clients and the compositor to
+  create windows that can be dragged, resized, maximized, etc, as well as
+  creating transient windows such as popup menus.
 
 
 
-- 
2.13.0

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

[PATCH wayland-protocols v2 07/13] xdg-shell/surface: Add note about window position and geometry

[Jonas Ådahl]

A client might want to change the window geometry without wanting the
window to be moved, for example when changing the width of the border.
Point out that the compositor should treat the (x,y) coordinate of the
geometry as the top-left corner of the window, and not change the
position of the window as it appears on the screen if the (x,y)
coordinate changes.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 3d19f62..c7dd6dd 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -445,6 +445,11 @@
The window geometry is double buffered, and will be applied at the
time wl_surface.commit of the corresponding wl_surface is called.
 
+   When maintaining a position, the compositor should treat the (x, y)
+   coordinate of the window geometry as the top left corner of the window.
+   A client changing the (x, y) window geometry coordinate should in
+   general not alter the position of the window.
+
Once the window geometry of the surface is set, it is not possible to
unset it, and it will remain the same until set_window_geometry is
called again, even if a new subsurface or buffer is attached.
-- 
2.13.0

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

[PATCH wayland-protocols v2 05/13] xdg-shell/positioner: Allow empty anchor_rect

[Jonas Ådahl]

Allow setting an empty anchor rectangle, so that one can map a popup
against a coordinate, not a pixel.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---

Changes since v1:

Had missed one part where it still required at least 1x1 sized anchor
rectangle.

 stable/xdg-shell/xdg-shell.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 2be4599..e64bd3e 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -165,13 +165,13 @@
Specify the anchor rectangle within the parent surface that the child
surface will be placed relative to. The rectangle is relative to the
window geometry as defined by xdg_surface.set_window_geometry of the
-   parent surface. The rectangle must be at least 1x1 large.
+   parent surface.
 
When the xdg_positioner object is used to position a child surface, the
anchor rectangle may not extend outside the window geometry of the
positioned child's parent surface.
 
-   If a zero or negative size is set the invalid_input error is raised.
+   If a negative size is set the invalid_input error is raised.
   
   
   
-- 
2.13.0

___
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

[Jonas Ådahl]

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.

Anyway, some comments about this proposal below:

> 
> https://bugs.freedesktop.org/show_bug.cgi?id=101436
> 
> Signed-off-by: Olivier Fourdan 
> ---
>  Note: This is what Jonas called "wp_xwayland_configure_screen"
>  in https://bugs.freedesktop.org/show_bug.cgi?id=101436#c5
> 
>  Makefile.am|   1 +
>  unstable/xwayland-logical-output/README|   5 +
>  .../xwayland-logical-output-unstable-v1.xml| 101 
> +
>  3 files changed, 107 insertions(+)
>  create mode 100644 unstable/xwayland-logical-output/README
>  create mode 100644 
> unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index e693afa..e198362 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-logical-output/xwayland-logical-output-unstable-v1.xml  
>   \
>   $(NULL)
>  
>  stable_protocols =   
> \
> diff --git a/unstable/xwayland-logical-output/README 
> b/unstable/xwayland-logical-output/README
> new file mode 100644
> index 000..efcaf69
> --- /dev/null
> +++ b/unstable/xwayland-logical-output/README
> @@ -0,0 +1,5 @@
> +Xwayland logical output protocol
> +
> +Maintainers:
> +Olivier Fourdan 
> +
> diff --git 
> a/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml 
> b/unstable/xwayland-logical-output/xwayland-logical-output-unstable-v1.xml
> new file mode 100644
> index 000..2b1d537
> --- /dev/null
> +++ b/unstable/xwayland-logical-output/xwayland-logical-output-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 optional protocol is application-specific to describe the logical
> +output setup for Xwayland. It provides a way for the compositor to
> +provide Xwayland with a specific pre-computed scaled size of the outputs.
> +
> +The core Wayland interface wl_output lists all outputs and their
> +modes in hardware units along with the output scaling 

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

[Jonas Ådahl]

On Fri, Jun 02, 2017 at 11:06:25AM +0200, Olivier Fourdan wrote:
> 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 
> ---
>  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..974547a
> --- /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. 

Re: [PATCH wayland-protocols v7 2/2] Add keyboard shortcuts inhibitor

[Jonas Ådahl]

On Tue, Jun 06, 2017 at 02:03:39PM +0200, Olivier Fourdan wrote:
> 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 
> ---
>  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...
> 
>  Makefile.am|   1 +
>  unstable/keyboard-shortcuts-inhibit/README |   4 +
>  .../keyboard-shortcuts-inhibit-unstable-v1.xml | 141 
> +
>  3 files changed, 146 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..290c9d2
> --- /dev/null
> +++ 
> b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> @@ -0,0 +1,141 @@
> +
> +
> +
> +  
> +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.
> +  
> 

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Thu, Jun 22, 2017 at 06:38:00PM +0100, David Edmundson wrote:
> >
> > For flipping, it's a bit more non straight forward, as
> > flipping and the offset are not very useful in combination,
> >
> 
> Yes, I think it's only when flipped where we need some additional
> clarification.
> 
> 
> > How about we add the following paragraph to the flip_x/y descriptions:
> >
> >   The adjusted position is calculated given the original anchor
> >   rectangle and offset, but with the new flipped anchor and gravity
> >   values.
> >
> 
> 
> I'm not sure that's what we want. In the case of a combobox where we want
> the dropdown to appear beneath the main UI controls with a gap, if we don't
> flip the offset we'll end up now overlapping the controls.
> 
> To hopefully explain what I mean:
> http://static.davidedmundson.co.uk/not_flipped.png   - some popup anchored
> to the text box (anchor bottom, gravity bottom) some +y offset.
> 
> Now for some reason that's constrained and it has flipY.
> http://static.davidedmundson.co.uk/flipped.png   - now flipped (anchor top,
> gravity top) but because we have a positive offset, we end up overlapping
> the control we're anchored round.

I see. You use the offset to add "padding" to the anchor rect? If I
understand things correctly, you could achieve the same thing with
including the padding on the anchor rect here.

> 
> I don't fully grasp what the anchor offset is for. A toolkit can acheive
> the same functionality by simply making the anchor rect bigger and that
> implicitly also gives the client the flexibility on how an offset when
> flipped should be handled.

The offset is mostly a convenience method for placing a combo box on top
of a anchor rectangle, without having to move around the anchor
rectangle in ways that would require us to allow the anchor rect to be
outside of the window region.

For example, shown with ASCII art:

   ++  - - - -
   ||^
  +-+   +--||-+  |  -y-offset
  |     |   |  || |_ _ _ v
  |  || |   |  || |
  | |   |  || |
  +-+   +--||-+
   ++


This tries to illustrate where we have a button that when clicked opens
a combo box with the already selected entry placed on top of the button
that opened it. The issue here being that the popup might extend outside
of the parent window, meaning we can't place it "against" any anchor
rectangle within the window. This is what the offset was added for.

With that said, I have yet to think of a use case where an offset is
useful together with flipping, at least not when there is an offset on
the same axis that is flipped.


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

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Tue, Jun 20, 2017 at 06:54:34PM +0100, David Edmundson wrote:
> You missed a line in "xdg-shell/positioner: Allow empty anchor_rect"
> You might want to squash this with that.

> From 0a21378302d63a83a10723b41adf35e605fb35f5 Mon Sep 17 00:00:00 2001
> From: David Edmundson 
> Date: Tue, 20 Jun 2017 18:29:59 +0100
> Subject: [PATCH 1/2] Fix xdg-shell/positioner: Allow empty anchor_rect
> 
> ---
>  stable/xdg-shell/xdg-shell.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index 2e845fa..ffba86d 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -165,7 +165,7 @@
>   Specify the anchor rectangle within the parent surface that the child
>   surface will be placed relative to. The rectangle is relative to the
>   window geometry as defined by xdg_surface.set_window_geometry of the
> - parent surface. The rectangle must be at least 1x1 large.
> + parent surface.

Thanks, i'll squash this the commit that missed this change.


Jonas

>  
>   When the xdg_positioner object is used to position a child surface, the
>   anchor rectangle may not extend outside the window geometry of the
> -- 
> 2.12.0
> 

> ___
> 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: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Tue, Jun 20, 2017 at 06:55:41PM +0100, David Edmundson wrote:
> ​

> From 093ed1a17a483792e316f932e15a566ab2653838 Mon Sep 17 00:00:00 2001
> From: David Edmundson 
> Date: Tue, 20 Jun 2017 18:51:45 +0100
> Subject: [PATCH 2/2] xdg-shell/positioner: Replace edge bitfield with extended
>  enum
> 
> Bitfields allowed for impossible combinations of anchor edges, such as
> being on the left and right edge. Use of explicit enumerations means we
> don't need to handle that case.

Although it is not a requirement, we usually add Signed-off-by here. Do
you want to add it?

> ---
>  stable/xdg-shell/xdg-shell.xml | 71 
> ++
>  1 file changed, 30 insertions(+), 41 deletions(-)
> 
> diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
> index ffba86d..020af9e 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -179,63 +179,52 @@
>
>  
>  
> -
> -   -  summary="the center of the anchor rectangle"/>
> -   -  summary="the top edge of the anchor rectangle"/>
> -   -  summary="the bottom edge of the anchor rectangle"/>
> -   -  summary="the left edge of the anchor rectangle"/>
> -   -  summary="the right edge of the anchor rectangle"/>
> +

nit: extra newline

> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
>  
>  
>  
>
>   Defines a set of edges for the anchor rectangle. These are used to
>   derive an anchor point that the child surface will be positioned
> - relative to. If two orthogonal edges are specified (e.g. 'top' and
> - 'left'), then the anchor point will be the intersection of the edges
> - (e.g. the top left position of the rectangle); otherwise, the derived
> - anchor point will be centered on the specified edge, or in the center of
> - the anchor rectangle if no edge is specified.
> -
> - If two parallel anchor edges are specified (e.g. 'left' and 'right'),
> - the invalid_input error is raised.
> + relative to. The anchor point will be in the specified corner, in the 
> center
> +of a specified edge, or in the center of the anchor rectangle if no edge
> +is specified.

We don't define a set of "edges" anymore, so I suggest changing that
too. We still derive the resulting point however, so we should still
include that.

I suggest this wording, which tries to minimize the change:

Defines the anchor point for the anchor rectangle. The are used
to derive an anchor point that the child surface will be
positioned relative to. If a corner anchor is set (e.g.
'top_left' or 'bottom_right'), the anchor point will be at the
specified corner; otherwise, the derived anchor point will be
centered on the specified edge, or in the center of the anchor
rectangle if no edge is specified.


>
> -summary="bit mask of anchor edges"/>
> +summary="anchor edge"/>

Not really an 'edge' anymore either, so maybe just "anchor" is better
here.

>  
>  
> -
> -   -  summary="center over the anchor edge"/>
> -   -  summary="position above the anchor edge"/>
> -   -  summary="position below the anchor edge"/>
> -   -  summary="position to the left of the anchor edge"/>
> -   -  summary="position to the right of the anchor edge"/>
> +
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
>  
>  
>  
>
> - Defines in what direction a surface should be positioned, relative to
> - the anchor point of the parent surface. If two orthogonal gravities are
> - specified (e.g. 'bottom' and 'right'), then the child surface will be
> - placed in the specified direction; otherwise, the child surface will be
> - centered over the anchor point on any axis that had no gravity
> - specified.
> -
> - If two parallel gravities are specified (e.g. 'left' and 'right'), the
> - invalid_input error is raised.
> + Defines which edge of the surface should be positioned relative to
> + the anchor of the parent surface. The anchor point will be in the 
> specified corner,
> +in the center of a specified edge, or in the center of the anchor 
> rectangle if no edge
> +is specified.

I suggest continuing talking about "direction" here. An alternative to
the above could be, changing the original text just a bit:

Defines in what direction a surface should be positioned,
relative to the anchor point of the parent surface. If a corner
gravity is specified (e.g. 'bottom_right' or 'top_left'), then
the child surface will be placed in the specified direction;
otherwise, the child surface will be centered over the anchor
point on any axis that had no 

Re: [PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

On Fri, Jun 02, 2017 at 09:54:31AM +0100, David Edmundson wrote:
> I have some comments/questions on the current v6 interface which I'd like
> clarifying before we make it stable.
> 
> The Positioner anchor and gravity both takes the edge as a bitfield of
> flags.
> 
> It's then part of the protocol to say "If two parallel anchor edges are
> specified (e.g. 'left' and 'right'), the invalid_input error is raised."
> 
> I don't understand why we don't use 9 enum values; none, topleft, top,
> topright etc. as it forbids even the possibility of an invalid input. It's
> what we do in the top level resize edge. It seems cleaner and safer wtih no
> drawbacks

That would indeed be equivalent. Would you create a patch on top of this
branch to update this for the future stable version?

> 
>  
> 
> Also on the positioner, when I have an offset from an anchor what is the
> intended behaviour in the compositor for applying this if I end up flipping
> or sliding due to constraints?

The idea is that the offset will be applied after placing given the
anchor rect, gravity and anchor, and then constrain adjusted. For
sliding, this means that the popup is first positioned, and moved on one
or two axes. For flipping, it's a bit more non straight forward, as
flipping and the offset are not very useful in combination, but my idea
of it is that after being constrain tested and a flip is triggered, the
new position of the popup is calculated again as before but with the
flipped gravity and anchor.

How about we add the following paragraph to the flip_x/y descriptions:

  The adjusted position is calculated given the original anchor
  rectangle and offset, but with the new flipped anchor and gravity
  values.

For the slide_x/y description, I don't think its needed. The set_offset
request contains a note about the post-offset position is the one used
when constrain testing, and slide_x/y only talks about sliding the
surface position in case of constrain testing shows the surface is
constrained.

> Any user interface element isn't going to line up after it's constrained in
> the same axis as the offset...unless we allow clients to specify an offset
> for every possible constraint.

Could you elaborate on this? I'm not sure what you mean here. In what
way do you want to align a UI widget that is not supported?

Sorry for the delays btw, and thanks for the input!


Jonas

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

[PATCH wayland-protocols 07/11] xdg-shell/surface: Add note about window position and geometry

[Jonas Ådahl]

A client might want to change the window geometry without wanting the
window to be moved, for example when changing the width of the border.
Point out that the compositor should treat the (x,y) coordinate of the
geometry as the top-left corner of the window, and not change the
position of the window as it appears on the screen if the (x,y)
coordinate changes.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 11be7f0..f602a81 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -445,6 +445,11 @@
The window geometry is double buffered, and will be applied at the
time wl_surface.commit of the corresponding wl_surface is called.
 
+   When maintaining a position, the compositor should treat the (x, y)
+   coordinate of the window geometry as the top left corner of the window.
+   A client changing the (x, y) window geometry coordinate should in
+   general not alter the position of the window.
+
Once the window geometry of the surface is set, it is not possible to
unset it, and it will remain the same until set_window_geometry is
called again, even if a new subsurface or buffer is attached.
-- 
2.13.0

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

[PATCH wayland-protocols 00/11] Declaring xdg-shell stable

[Jonas Ådahl]

Hi,

I think it is time to take the next step regarding xdg_shell: declaring it
stable. The current unstable version (xdg_shell unstable v6) has been
implemented in multiple code bases, used by multiple desktop environments for
quite some time, and I think this proves it is time to take the next step.

While it has indeed been implemented and used, there has been various issues
raised regarding the protocol, but I believe all of these qualify as minor
enough not requiring a new unstable release.

I'll go through them here in this E-mail, but please do read the actual commits
for the actual change.

1) Renaming the main global interface

It is not possible to just strip the unstable protocol prefix/postfix of the
global interface name, so it had to be renamed. The reason for this is that up
until the unstable version 6, the global interface name of the protocol was
simply "xdg_shell". This means that without clever version hackery, we can not
make the it discoverable that this is indeed the new stable interface and not
an old unstable one.

The new name has been discussion previously on #wayland, and at one point Pekka
came up with "xdg_wm_base" as xdg_shell really is about the window management
basics. I chose this name for this patch series, but it is not set in stone.
Other suggestions include "wp_shell", "wp_desktop_shell", "xdg_desktop_shell".

2) The anchor rectangle of a xdg_positioner may now be empty

If one wants to position a menu against corner of a pixel and have it flip in
any direction, this was not possible due to the requirement that a anchor
rectangle of a xdg_positioner had to be non-empty. Allowing an empty anchor
rectangle fixes this without any down sides.

3) More forgiving managing of stacking relationships

The set_parent request of xdg_toplevel was specified to require unmapping the
parent before the child. This was poorly enforced in various implementations,
and making it an error will have serious consequences when the relationship
crosses client boundaries, as is possible using xdg_foreign (used by
xdg-desktop-portal, i.e. sandboxed clients using portals). Make things a bit
more forgiving, while at the same time more predictable. For example, unmapping
a parent that itself has a parent, will turn its children children of its own
parent.

4) Allowing external protocols to define popup parent relationships

To use xdg_popup for things such as a window menu implemented in westons
desktop shell client, we must allow passing null as a parent, relying on some
external protocol for setting up this relationship. Allowing this also makes it
possible to extend xdg_foreign with foreign popup menus in case this is ever
needed.

5) Define behaviour when attaching a null buffer to a surface

The behaviour of attaching a null buffer was previously undefined. Some
compositors just didn't render the surface, some assumed it was invalid
behaviour and sent an error. In short, the now defined behavior depends on the
role; it'll either permanently unmap the surface (xdg_popup), or unmap it and
reset all attributes as if the xdg_surface and role objects was just created
(xdg_toplevel). See corresponding patch (xdg-shell: clarify map/unmap wording)
for details.

6) Misc minor changes/clarification/rewording

Other changes are best read in the actual patches, but just to make things more
complete, they include some rewording of the documentation of the global
interface, clarification of maintaining window positions in relation to window
management changes and terminology corrections. The maintainers listed in the
README has also changed to be me and Mike Blumenkrantz.


So these are the changes that should provide us on a good base shell protocol.
If we can agree on making this, we can later start adding more extensions, both
externally (as separate protocols) or inside xdg_shell (as global interfaces,
or new requests/events). There are already plans and ideas of additions that
has been discussed at various places, but I believe we should not try to
introduce any new features to the base protocol before having something we can
rely on for backward compatibility.

So in other words, proposing to make xdg_shell stable does not mean it defines
everything that needs to be defined; it means that it defines the bare minimum
a compositor must implement to support clients that use xdg_shell in a way that
can be extended in the future. If there is something missing for implementing a
certain feature, that is expected; if there is something that makes extending
the protocol to implement a certain feature impossible, that should be fixed.


Jonas



Jonas Ådahl (10):
  Add xdg-shell to stable/
  xdg-shell: Rename interfaces
  xdg-shell: Update copyright notices
  xdg-shell: Reword the xdg_wm_base introduction
  xdg-shell/positioner: Allow empty anchor_rect
  xdg-shell: Replace 'monitor' with 'output'
  xdg-shell/surface: Add note about window p

[PATCH wayland-protocols 09/11] xdg-shell/toplevel: Chain multiple parent-child relationships

[Jonas Ådahl]

Change the semantics of xdg_toplevel.set_parent to allow chaining
multiple parent-child relationships together, while allowing
arbitrarily unmapping parents, while keeping what is left over of the
chain intact.

This makes things easier to manage when parent-child relationships
cross client borders, for example when using xdg_foreign.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 876e13e..fc9a8cd 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -540,9 +540,8 @@
 
 
   
-   Set the "parent" of this surface. This window should be stacked
-   above a parent. The parent surface must be mapped as long as this
-   surface is mapped.
+   Set the "parent" of this surface. This surface should be stacked
+   this above the parent surface and all other ancestor surfaces.
 
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
@@ -551,6 +550,12 @@
Setting a null parent for a child window removes any parent-child
relationship for the child. Setting a null parent for a window which
currently has no parent is a no-op.
+
+   If the parent is unmapped then its children are managed as
+   though the parent of the now-unmapped parent has become the
+   parent of this surface. If no parent exists for the now-unmapped
+   parent then the children are managed as though they have no
+   parent surface.
   
   
 
-- 
2.13.0

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

[PATCH wayland-protocols 04/11] xdg-shell: Reword the xdg_wm_base introduction

[Jonas Ådahl]

Don't refer to things as "traditional desktop" as it is not defined
nor clear what that refers to; instead reword things in a more
non-explicit way. A reason for this is that xdg-shell is not strictly
meant only for traditional window stacking based desktop environments,
but should be equally suitable for stacking, tiling and potentially
other styles as well.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index ec70073..2be4599 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -31,10 +31,11 @@
 
   
 
-  xdg_wm_base allows clients to turn a wl_surface into a "real window"
-  which can be dragged, resized, stacked, and moved around by the
-  user. Everything about this interface is suited towards traditional
-  desktop environments.
+  The xdg_wm_base interface is exposed as a global object enabling clients
+  to turn their wl_surfaces into windows in a desktop environment. It
+  defines the basic functionality needed for clients and the compositor to
+  create windows that can be dragged, resized, maximized, etc, as well as
+  creating transient windows such as popup menus.
 
 
 
-- 
2.13.0

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

[PATCH wayland-protocols 08/11] xdg-shell/toplevel: Clarify xdg_toplevel.set_parent(null)

[Jonas Ådahl]

Setting a null-surface as a toplevel parent should unset the
parent-child relationship. This was not specified, so lets do that.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 4 
 1 file changed, 4 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index f602a81..876e13e 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -547,6 +547,10 @@
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
is raised.
+
+   Setting a null parent for a child window removes any parent-child
+   relationship for the child. Setting a null parent for a window which
+   currently has no parent is a no-op.
   
   
 
-- 
2.13.0

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

[PATCH wayland-protocols 05/11] xdg-shell/positioner: Allow empty anchor_rect

[Jonas Ådahl]

Allow setting an empty anchor rectangle, so that one can map a popup
against a coordinate, not a pixel.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 2be4599..831948c 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -171,7 +171,7 @@
anchor rectangle may not extend outside the window geometry of the
positioned child's parent surface.
 
-   If a zero or negative size is set the invalid_input error is raised.
+   If a negative size is set the invalid_input error is raised.
   
   
   
-- 
2.13.0

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

[PATCH wayland-protocols 10/11] xdg-shell/popup: Allow custom parent by passing null as parent

[Jonas Ådahl]

Allow using some other protocol (custom, or future xdg_* based) to set
up the parent-child relationship of a popup. This allows future
protocols to use xdg_popup when mapping popups over surfaces not based
on xdg_surface.

An example use case for this is the window menu, where a shells UI
client can use xdg_popup to create popup menus over windows it does not
have a xdg_surface of by having a custom protocol setting up the proper
parent-child relationship.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index fc9a8cd..8ca8a94 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -424,14 +424,17 @@
 
 
   
-   This creates an xdg_popup object for the given xdg_surface and gives the
-   associated wl_surface the xdg_popup role.
+   This creates an xdg_popup object for the given xdg_surface and gives
+   the associated wl_surface the xdg_popup role.
+
+   If null is passed as a parent, a parent surface must be specified using
+   some other protocol, before committing the initial state.
 
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
   
   
-  
+  
   
 
 
-- 
2.13.0

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

[PATCH wayland-protocols 11/11] xdg-shell: clarify map/unmap wording

[Jonas Ådahl]

From: Mike Blumenkrantz <zm...@osg.samsung.com>

ensure that this is as precise and explicit as possible for all useful
cases and also define previously-unspecified behavior

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/xdg-shell.xml | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 8ca8a94..2e845fa 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -391,11 +391,20 @@
   manipulate a buffer prior to the first xdg_surface.configure call must
   also be treated as errors.
 
-  For a surface to be mapped by the compositor, the following conditions
-  must be met: (1) the client has assigned a xdg_surface based role to the
-  surface, (2) the client has set and committed the xdg_surface state and
-  the role dependent state to the surface and (3) the client has committed 
a
-  buffer to the surface.
+  Mapping an xdg_surface-based role surface is defined as making it
+  possible for the surface to be shown by the compositor. Note that
+  a mapped surface is not guaranteed to be visible once it is mapped.
+
+  For an xdg_surface to be mapped by the compositor, the following
+  conditions must be met:
+  (1) the client has assigned an xdg_surface-based role to the surface
+  (2) the client has set and committed the xdg_surface state and the
+role-dependent state to the surface
+  (3) the client has committed a buffer to the surface
+
+  A newly-unmapped surface is considered to have met condition (1) out
+  of the 3 required conditions for mapping a surface if its role surface
+  has not been destroyed.
 
 
 
@@ -531,13 +540,20 @@
   fullscreen, and minimize, set application-specific metadata like title 
and
   id, and well as trigger user interactive operations such as interactive
   resize and move.
+
+  Unmapping an xdg_toplevel means that the surface cannot be shown
+  by the compositor until it is explicitly mapped again.
+  All active operations (e.g., move, resize) are canceled and all
+  attributes (e.g. title, state, stacking, ...) are discarded for
+  an xdg_toplevel surface when it is unmapped.
+
+  Attaching a null buffer to a toplevel unmaps the surface.
 
 
 
   
-   Unmap and destroy the window. The window will be effectively
-   hidden from the user's point of view, and all state like
-   maximization, fullscreen, and so on, will be lost.
+   This request destroys the role surface and unmaps the surface;
+   see "Unmapping" behavior in interface section for details.
   
 
 
-- 
2.13.0

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

[PATCH wayland-protocols 02/11] xdg-shell: Rename interfaces

[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.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 1c0f924..da8d6d4 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -1,5 +1,5 @@
 
-
+
 
   
 Copyright © 2008-2013 Kristian Høgsberg
@@ -27,9 +27,9 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
-  xdg_shell allows clients to turn a wl_surface into a "real window"
+  xdg_wm_base allows clients to turn a wl_surface into a "real window"
   which can be dragged, resized, stacked, and moved around by the
   user. Everything about this interface is suited towards traditional
   desktop environments.
@@ -38,7 +38,7 @@
 
   
   
+summary="xdg_wm_base was destroyed before children"/>
   
   
 
 
-  
-   Destroy this xdg_shell object.
+  
+   Destroy this xdg_wm_base object.
 
-   Destroying a bound xdg_shell object while there are surfaces
-   still alive created by this xdg_shell object instance is illegal
+   Destroying a bound xdg_wm_base object while there are surfaces
+   still alive created by this xdg_wm_base object instance is illegal
and will result in a protocol error.
   
 
@@ -65,7 +65,7 @@
surfaces relative to some parent surface. See the interface description
and xdg_surface.get_popup for details.
   
-  
+  
 
 
 
@@ -82,14 +82,14 @@
See the documentation of xdg_surface for more details about what an
xdg_surface is and how it is used.
   
-  
+  
   
 
 
 
   
A client must respond to a ping event with a pong request or
-   the client may be deemed unresponsive. See xdg_shell.ping.
+   the client may be deemed unresponsive. See xdg_wm_base.ping.
   
   
 
@@ -98,7 +98,7 @@
   
The ping event asks the client if it's still alive. Pass the
serial specified in the event back to the compositor by sending
-   a "pong" request back with the specified serial. See xdg_shell.ping.
+   a "pong" request back with the specified serial. See xdg_wm_base.ping.
 
Compositors can use this to determine if the client is still
alive. It's unspecified what will happen if the client doesn't
@@ -106,13 +106,13 @@
try to respond in a reasonable amount of time.
 
A compositor is free to ping in any way it wants, but a client must
-   always respond to any xdg_shell object it created.
+   always respond to any xdg_wm_base object it created.
   
   
 
   
 
-  
+  
 
   The xdg_positioner provides a collection of rules for the placement of a
   child surface relative to a parent surface. Rules can be defined to 
ensure
@@ -361,7 +361,7 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -416,7 +416,7 @@
See the documentation of xdg_toplevel for more details about what an
xdg_toplevel is and how it is used.
   
-  
+  
 
 
 
@@ -427,9 +427,9 @@
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
   
-  
-  
-  
+  
+  
+  
 
 
 
@@ -513,7 +513,7 @@
 
   
 
-  
+  
 
   This interface defines an xdg_surface role which allows a surface to,
   among other things, set window-like properties such as maximize,
@@ -540,7 +540,7 @@
"auxiliary" surfaces, so that the parent is raised when the dialog
is raised.
   
-  
+  
 
 
 
@@ -913,7 +913,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.13.0

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

[PATCH wayland-protocols 03/11] xdg-shell: Update copyright notices

[Jonas Ådahl]

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Acked-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index da8d6d4..ec70073 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -6,6 +6,8 @@
 Copyright © 2013  Rafael Antognolli
 Copyright © 2013  Jasper St. Pierre
 Copyright © 2010-2013 Intel Corporation
+Copyright © 2015-2017 Samsung Electronics Co., Ltd
+Copyright © 2015-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"),
-- 
2.13.0

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

[PATCH wayland-protocols 01/11] Add xdg-shell to stable/

[Jonas Ådahl]

Add a copy of xdg-shell unstable v6 to stable/xdg-shell/xdg-shell.xml.
Folliwing this commit, it will go through a set of changes, before
being declared stable.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 stable/xdg-shell/README|5 +
 stable/xdg-shell/xdg-shell.xml | 1044 
 2 files changed, 1049 insertions(+)
 create mode 100644 stable/xdg-shell/README
 create mode 100644 stable/xdg-shell/xdg-shell.xml

diff --git a/stable/xdg-shell/README b/stable/xdg-shell/README
new file mode 100644
index 000..2769abb
--- /dev/null
+++ b/stable/xdg-shell/README
@@ -0,0 +1,5 @@
+xdg shell protocol
+
+Maintainers:
+Jonas Ådahl <jad...@gmail.com>
+Mike Blumenkrantz <zm...@osg.samsung.com>
diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
new file mode 100644
index 000..1c0f924
--- /dev/null
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -0,0 +1,1044 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 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.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards traditional
+  desktop environments.
+
+
+
+  
+  
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Create a positioner object. A positioner object is used to position
+   surfaces relative to some parent surface. See the interface description
+   and xdg_surface.get_popup for details.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface. While xdg_surface
+   itself is not a role, the corresponding surface may only be assigned
+   a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
+
+   This creates an xdg_surface for the given surface. An xdg_surface is
+   used as basis to define a role to a given surface, such as xdg_toplevel
+   or xdg_popup. It also manages functionality shared between xdg_surface
+   based surface roles.
+
+   See the documentation of xdg_surface for more details about what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   A client must respond to a ping event with a pong request or
+   the client may be deemed unresponsive. See xdg_shell.ping.
+  
+  
+
+
+
+  
+   The ping event asks the client if it's still alive. Pass the
+   serial specified in the event back to the compositor by sending
+   a "pong" request back with the specified serial. See xdg_shell.ping.
+
+   Compositors can use this to determine if the client is still
+   alive. It's unspecified what will happen if the client doesn't
+   respond to the ping request, or in what timeframe. Clients should
+   try to respond in a reasonable amount of time.
+
+   A compositor is free to ping in any way it wants, but a client must
+   always respond to any xdg_shell object it created.
+  
+  
+
+  
+
+  
+
+  The xdg_positioner provides a collection of rules for the placement of a
+  child surface relative to a parent surface. Rules can be defined to 
ensure
+  the child surface remains within the visible area's borders, and to
+  specify how the child surface changes its position, such as sliding along
+ 

[PATCH wayland-protocols 06/11] xdg-shell: Replace 'monitor' with 'output'

[Jonas Ådahl]

There is no such thing as 'monitor' in Wayland, only outputs.

Signed-off-by: Jonas Ådahl <jad...@gmail.com>
Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index 831948c..11be7f0 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -255,7 +255,7 @@
   

  Don't alter the surface position even if it is constrained on some
- axis, for example partially outside the edge of a monitor.
+ axis, for example partially outside the edge of an output.

   
   
@@ -847,7 +847,7 @@
 
 
 
-  
+  
Make the surface fullscreen.
 
You can specify an output that you would prefer to be fullscreen.
-- 
2.13.0

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

Re: [PATCH 2/2 v3] Add keyboard shortcuts inhibitor

[Jonas Ådahl]

On Wed, Apr 05, 2017 at 02:30:15PM +0200, Olivier Fourdan wrote:
> 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.

Look out for style nits (especially now that Yong has cleaned up
inconsistencies in the other protocol XML files!), but there are some
other comments below too.

> 
> Signed-off-by: Olivier Fourdan 
> ---
>  v2: Clarify that that the compositor is under no obligation to ignore
>  every shortcut (ajax)
>  Add "inhibit_active" and "inhibit_inactive" events to notify clients
>  Add "already_inhibited" error
>  v3: Rename "inhibit_active" and "inhibit_inactive" events to simply
>  "active" and "inactive" and fix some Tab in the middle of the text.
> 
>  Makefile.am|   1 +
>  unstable/keyboard-shortcuts-inhibit/README |   4 +
>  .../keyboard-shortcuts-inhibit-unstable-v1.xml | 132 
> +
>  3 files changed, 137 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..bb35de1
> --- /dev/null
> +++ 
> b/unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> @@ -0,0 +1,132 @@
> +
> +
> +
> +  
> + 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.

Indentation issue.

> +  
> +
> +  
> + 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.

Indentation issue

> +  
> +
> +  
> +

Stray newline, and missing .

> +
> +  
> + Destroy the keyboard shortcuts inhibitor manager.
> +  
> +
> +
> +
> +  
> + Create a new 

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

[Jonas Ådahl]

On Wed, Mar 22, 2017 at 05:27:22PM +0100, Olivier Fourdan wrote:
> 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.
> 

Here are some input; I'll also send some others as a reply to another
mail in this thread, but these are more "standalone" and nitpick:y.

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

Leave the version bumping to the release process.

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

Indentation seems wrong.

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

Re: [PATCH wayland 8/9] client: Replace the singleton zombie with bespoke zombies

[Jonas Ådahl]

On Tue, Apr 11, 2017 at 10:37:28AM -0500, Derek Foreman wrote:
> On 07/04/17 03:27 PM, Derek Foreman wrote:
> > Using the singleton zombie object doesn't allow us to posthumously retain
> > object interface information, which makes it difficult to properly inter
> > future events destined for the recently deceased proxy.
> > 
> > Notably, this makes it impossible for zombie proxy destined file
> > descriptors to be properly consumed.
> > 
> > Instead of having a singleton zombie object, we add a new wl_map flag
> > (valid only on the client side where zombies roam - the existing
> > "legacy" flag was only ever used on the server side) to indicate that a
> > map entry is now a zombie.
> > 
> > We still have to refcount and potentially free the proxy immediately or
> > we're left with situations where it can be leaked forever.  If we clean
> > up on delete_id, for example, a forced disconnect will result in a leaked
> > proxy (breaking much of the test suite).
> > 
> > So, since we must free the zombied proxy immediately, we store just the
> > interface for it in its previous map location, so signature information
> > can be retained for zombie-destined events.
> 
> So even with this in place it's still possible for a malicious application
> to consume 1000fds (the number of fds that fit in fds_in) and go to sleep
> and hold them - on client disconnect they should be freed.  I don't really
> see a way to prevent that sort of crap anyway - a client could use sendmsg
> directly, send a single byte of regular data (ie: not enough to trigger
> demarshalling, the server will assume there's more to come), and a buffer's
> worth of file descriptors, then never speak again.
> 
> This appears indistinguishable from reasonable behaviour?
> 
> There's also an interesting side effect to this patch that I noticed
> yesterday - it places a requirement on the client to keep the wl_interfaces
> around in memory long after it destroys the proxy - up until the delete_id
> occurs.  We have no way to hook delete_id in the client.  This turned into a
> crash in EFL clients using the text input protocol, as the input method code
> in EFL is a module that's unloaded on shutdown.  It was easily fixed in EFL,
> but I'd like some input - is a client allowed to unmap the memory that a
> wl_interface is stored in at the moment it deletes the relevant proxy?
> 
> This isn't terribly difficult to fix, but I won't bother if the behaviour is
> universally concluded to be a client bug. :)

We could instead introduce a struct wl_zombie_object that constains the
data needed for doing a proper cleanup. This data could be for example
be number of fds per event opcode, or strdup:ed event signatures or
something. All of this would be known at zombification, and we'd avoid
any ABI change as this patch, as you say, seems to introduce.

If we'd care about minimizing allocations, we could also insert the old
WL_ZOMBIE_OBJECT when there are no fds to clean up, and handle that as a
another special case on clean up.


Jonas


> 
> Oh, and I just noticed wl_map_set_flags() is in this patch - that's a
> remnant of a previous attempt to close this leak, and will be removed for
> v2.
> 
> Thanks,
> Derek
> 
> > Signed-off-by: Derek Foreman 
> > ---
> >  src/connection.c  | 20 +++-
> >  src/wayland-client.c  | 10 ++
> >  src/wayland-private.h | 12 
> >  src/wayland-util.c| 22 --
> >  4 files changed, 53 insertions(+), 11 deletions(-)
> > 
> > diff --git a/src/connection.c b/src/connection.c
> > index f2ebe06..84f5d79 100644
> > --- a/src/connection.c
> > +++ b/src/connection.c
> > @@ -809,6 +809,24 @@ wl_connection_demarshal(struct wl_connection 
> > *connection,
> > return NULL;
> >  }
> > 
> > +bool
> > +wl_object_is_zombie(struct wl_map *map, uint32_t id)
> > +{
> > +   uint32_t flags;
> > +
> > +   if (map->side == WL_MAP_SERVER_SIDE)
> > +   return false;
> > +
> > +   if (id >= WL_SERVER_ID_START)
> > +   return false;
> > +
> > +   flags = wl_map_lookup_flags(map, id);
> > +   if (flags & WL_MAP_ENTRY_ZOMBIE)
> > +   return true;
> > +
> > +   return false;
> > +}
> > +
> >  int
> >  wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map 
> > *objects)
> >  {
> > @@ -830,7 +848,7 @@ wl_closure_lookup_objects(struct wl_closure *closure, 
> > struct wl_map *objects)
> > closure->args[i].o = NULL;
> > 
> > object = wl_map_lookup(objects, id);
> > -   if (object == WL_ZOMBIE_OBJECT) {
> > +   if (wl_object_is_zombie(objects, id)) {
> > /* references object we've already
> >  * destroyed client side */
> > object = NULL;
> > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > index 7243d3d..2cd713d 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c

Re: [PATCH wayland] docs: Reference Contributor Covenant

[Jonas Ådahl]

On Fri, Apr 07, 2017 at 05:48:59PM +0300, Pekka Paalanen wrote:
> On Fri,  7 Apr 2017 15:07:56 +0100
> Daniel Stone <dani...@collabora.com> wrote:
> 
> > All fd.o projects are now covered by the Contributor Covenant. Include a
> > reference to this in the Contributing doc, making it clear that we are
> > all expected to behave like human beings.
> > 
> > Signed-off-by: Daniel Stone <dani...@collabora.com>
> > ---
> >  doc/Contributing | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/doc/Contributing b/doc/Contributing
> > index c790a071..9475271a 100644
> > --- a/doc/Contributing
> > +++ b/doc/Contributing
> > @@ -159,6 +159,19 @@ my_function(void)
> > x = function_with_a_really_long_name(parameter1, parameter2,
> >  parameter3, parameter4);
> >  
> > +
> > +== Conduct ==
> > +
> > +As a freedesktop.org project, Wayland follows the Contributor Covenant,
> > +found at:
> > +https://www.freedesktop.org/wiki/CodeOfConduct
> > +
> > +Please conduct yourself in a respectful and civilised manner when
> > +interacting with community members on mailing lists, IRC, or bug
> > +trackers. The community represents the project as a whole, and abusive
> > +or bullying behaviour is not tolerated by the project.
> > +
> > +
> >  == Licensing ==
> >  
> >  Wayland is licensed with the intention to be usable anywhere X.org is.
> 
> Acked-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> 

Acked-by: Jonas Ådahl <jad...@gmail.com>


Jonas

> 
> Thanks,
> pq



> ___
> 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 wayland-protocols] inputfd - direct input access protocol

[Jonas Ådahl]

On Sat, Apr 01, 2017 at 10:48:40AM +1000, Peter Hutterer wrote:
> On Fri, Mar 31, 2017 at 12:23:49PM +0300, Pekka Paalanen wrote:
> > > +  
> > > + This event is sent to notify the client of a custom property that
> > > + applies to this device. The property is a standard key/value store
> > > + in UTF-8 format, interpretation of both strings is left to the
> > > + client. The wayland protocol makes no guarantees about the content
> > > + of each string beyond its text encoding.
> > > +
> > > + Compositors and clients need to agree on a dictionary of properties.
> > > + For example, a compositor may designate the device to be of
> > > + 'joystick-type' 'gamepad'. This dictionary is out of the scope of
> > > + this protocol.
> > > +  
> > > +  
> > > +  
> > > +
> > 
> > While I understand the desire to leave the dictionary for others to
> > specify, this event is essentially useless without it. The dictionary
> > really is part of the protocol, even if you didn't want it. I'm not
> > sure it's helpful to leave the authority on the dictionary unspecified.
> > As you wrote, they need to be agreed somewhere.
> > 
> > This raises a couple of questions for the protocol itself:
> > 
> > - What should the client do with a property or value it does not
> >   recognize?
> > 
> > - If the client does not recognize a property or a value, can it still
> >   use the device? Could this vary per property?
> > 
> > - Should the compositor be sending only properties and values the
> >   client can understand?
> > 
> > If this protocol does not define a single authority on the dictionary,
> > should it then carry a dictionary type, id or namespace?
> > 
> > Should properties be namespaced?
> 
> ok, easy answers first :)
> 
> clients must ignore property names or values that they do not understand,
> the compositor may send any value (it won't know what the client supports),
> the protocol does not enforce namespacing, but the dictionary authority may
> do so.
> one more thing I thought of: properties key/values are *not* singular, a
> client may receive the same property with multiple different values (e.g.
> ORIENTATION=left, ORIENTATION=top or BUTTON=A, BUTTON=X, ...). Whether
> that's allowed for any property depends on the dictionary.
> 
> Now to the difficult answers:
> 
> I think it'll be impossible to *not* have this in an external dictionary.
> The needs of the compositor and the clients are both the same and completely
> different for this protocol to work correctly. Let's take the example of
> tagging a device as gamepad. The default udev rules are unreliable,
> ID_INPUT_JOYSTICK has too many false positives. So we need some database
> that tags the device as JOYSTICK_TYPE=gamepad, JOYSTICK_TYPE=wheel, etc.
> That can be done in udev, but needs some external authority anyway -
> libwacom style. Without that, you'll have a mismatch in what compositors
> detect as gaming devices vs what clients can handle (assuming the mythical
> libgamingdevice exists).
> 
> The compositor doesn't care about the actual value though, anything with
> JOYSTICK_TYPE is a gaming device and will be accessible through inputfd.
> Adding new joystick types in the future does not change the protocol or the
> compositor implementation. A client should not need to wait for protocol 
> bumps just
> to get access to a new type that the compositor doesn't care about anyway.
> Just as a general reminder, the whole point of this protocol is for the
> compositor to have some say in what's available but otherwise get out of the
> way.
> 
> If we don't have the generic properties, we need the client to have some
> other way to access information about the device. In the Wacom case we have
> 'path' which gives the client a syspath and thus the udev device and access
> to udev properties. Bastien wasn't too happy about this for GPIO devices
> where it may not be possible, so the property approach was the first thing
> that came to mind.
> 
> Having said this - while I don't want this in the protocol, there's no
> reason we can't define that dictionary authority ourselves. I just want it
> external to the protocol. ICCCM/EMWH-style, effectively. But I would feel
> uncomfortable *being* the authority, given that this is too far outside my
> core knowledge. Happy to be the maintainer for this though, an initial
> implementation would be largely boilerplate.
> 
> I still think that there's a market for a generic libgamingdevice library
> that works libinput-style for gaming devices and provides the database that
> matches this dictionary. 
> 

The main reason I can think of for having an external authority for a
generic property set is if these properties are not going to be specific
to this protocol, but in this case, the backward compatibility
requirements must be the same, and the protocol cannot be skip
specifying who the authority actually is, as otherwise it'd make the
property completely undefined thus useless. A compositor 

Re: [RFC] Interface for injection of input events

[Jonas Ådahl]

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 

Re: [RFC PATCH xserver] xwayland: RFC Disable glamor with an env var?

[Jonas Ådahl]

On Thu, Mar 02, 2017 at 05:47:10AM -0500, Olivier Fourdan wrote:
> Hi Pekka,
> 
> > I understand the attractiveness of adding an override, bypassing the
> > compositors like this. But, essentially it is just that: a
> > configuration bypass.
> 
> True.
>  
> > I would prefer leaning towards just making the compositors more
> > considerate about their Xwayland configuration. I believe the global
> > trend is to move towards the compositor having all the configurability
> > in itself, and all the other components having a single source of
> > configuration in the running system: the compositor. I would compare
> > Xwayland to libinput here.
> 
> Yes, but that means that all compositors need to have this "configurability", 
> even though it's actually Xwayland that uses it.
> 

For a compositor that supports respawning Xwayland, to be able to change
the Xwayland configurations without restarting the actual compositor
would still need this "configurability", as any user set environment
variable will be static for the whole session.


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

Re: [PATCH weston] weston-resizor: Don't add new frame callbacks every click

[Jonas Ådahl]

On Wed, Feb 08, 2017 at 03:05:54PM -0600, Derek Foreman wrote:
> The frame callback added on button click re-adds itself when done,
> so adding a new one every click resulted in an ever increasing
> number of callbacks.
> 
> Signed-off-by: Derek Foreman 
> ---
>  clients/resizor.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/clients/resizor.c b/clients/resizor.c
> index 5d342e1f..600452ad 100644
> --- a/clients/resizor.c
> +++ b/clients/resizor.c
> @@ -53,6 +53,7 @@ struct resizor {
>   struct spring height;
>   struct wl_callback *frame_callback;
>   bool pointer_locked;
> + bool locked_frame_callback_registered;
>   struct input *locked_input;
>   float pointer_x;
>   float pointer_y;
> @@ -330,11 +331,15 @@ button_handler(struct widget *widget,
> handle_pointer_unlocked);
>   resizor->locked_input = input;
>  
> + if (resizor->locked_frame_callback_registered)
> + return;
> +
>   surface = window_get_wl_surface(resizor->window);
>   callback = wl_surface_frame(surface);
>   wl_callback_add_listener(callback,
>_pointer_frame_listener,
>resizor);
> + resizor->locked_frame_callback_registered = true;

Won't this mean that we can only initiate the resize once? The second
time we click, the locked_frame_callback_registered will still be true,
and we won't add the frame listener.

Instead what we could do is probably to check the result of
window_lock_pointer(), if it succeeded, continue with setting
resizor->locked_input. Before trying to lock, check if we already have a
locked_input, and if so, skip locking and adding the frame callback.
Would also mean we need to clean up the locked_input on button-release
and on unlocked (though seems weston-resizer crashes when unlocked by
the compositor and not by itself).


Jonas

>   } else if (button == BTN_LEFT &&
>  state == WL_POINTER_BUTTON_STATE_RELEASED) {
>   input_set_pointer_image(input, CURSOR_LEFT_PTR);
> -- 
> 2.11.0
> 
> ___
> 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: [PATCH wayland v2] protocol: Clarify the behaviour of wl_surface.attach

[Jonas Ådahl]

On Tue, Feb 14, 2017 at 10:20:06AM -0600, Derek Foreman wrote:
> Attaching a NULL wl_buffer to a surface is not always valid, but
> the previous text indicated it was.
> 
> Instead, let's define what NULL attachment does for all the surface
> roles defined in wayland.xml, stop giving a blanket definition of
> its behavior in wl_surface.attach, and warn developers that they
> should refer to other protocol documentation for a full understanding
> of wl_surface.attach.

Good to see these things cleared up. Have some comments on the wording
below, and the "cursor" role behaviour seems still undefined when
attaching a NULL buffer.

> 
> Signed-off-by: Derek Foreman 
> ---
> 
> Changes from v1:
>  pretty much everything - define NULL attach for wl_shell specifically
>  and remove the generic statement from wl_surface.attach
>  refer readers to "other documentation"
> 
>  protocol/wayland.xml | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 29b63be..1a76e60 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1002,6 +1002,10 @@
>the related wl_surface is destroyed. On the client side,
>wl_shell_surface_destroy() must be called before destroying
>the wl_surface object.
> +
> +  Attaching a NULL wl_buffer to a surface assigned a role by
> +  wl_shell will remove the content from the surface after the
> +  next commit.

How is "removes the content" compared to unmaps? Does this mean a shell
implementation need to keep track of the position when the shell surface
is later remapped? That would be a new requirement that was previously
undefined behaviour, and is not what mutter does at the moment.

>  
>  
>  
> @@ -1324,6 +1328,9 @@
>
>   Set a buffer as the content of this surface.
>  
> + The role of the surface influences the behaviour of attach,
> + so this documentation is incomplete without further reading.
> +

Possible alternative wording, possibly in the end of the ,
as it talks about things that is specified below:

The effect committing an attached buffer to a surface depends on
what role the surface has been or is going to be assigned to.
See the corresponding role specification for further details.

This makes read more as the behaviour of *attach* does not change, but
the effect of having attached and committed a buffer.


Jonas

>   The new size of the surface is calculated based on the buffer
>   size transformed by the inverse buffer_transform and the
>   inverse buffer_scale. This means that the supplied buffer
> @@ -1358,9 +1365,6 @@
>   the surface contents. However, if the client destroys the
>   wl_buffer before receiving the wl_buffer.release event, the surface
>   contents become undefined immediately.
> -
> - If wl_surface.attach is sent with a NULL wl_buffer, the
> - following wl_surface.commit will remove the surface content.
>
> allow-null="true"
>  summary="buffer of surface contents"/>
> -- 
> 2.11.0
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCHv3] Add surface-layers protocol

[Jonas Ådahl]

On Tue, Jan 24, 2017 at 10:03:05PM -0500, Drew DeVault wrote:
> On 2017-01-25  9:54 AM, Jonas Ådahl wrote:
> > Hi,
> > 
> > By the looks of it, this is a protocol extension that aims to enable
> > desktop environments to be built of interoperable components (i.e. a
> > "background" process to draw a (live?) wallpaper, an "overlay" thing
> > could be used to create a panel, popup launcher or alt-tab view or
> > something). Is this correct?
> >
> > ...
> >
> > If I misunderstood the intention of the protocol, do let me know. I
> > didn't see any use cases spelled out, so I am just assuming.
> 
> You're correct. There are numerous other use-cases this enables that
> you're missing, though. Here's a few that come to mind:
> 
> - dmenu/rofi style applications
> - slop style applications
> - an android-like notification drawer
> 
> As well as basic desktop components like:
> 
> - screen locks and screensavers
> - on screen keyboards
> - panels
> - wallpapers (live or otherwise)
> - desktop icons
> 
> I put forth some use-cases in my initial proposal, but I've repeated
> them here.
> 
> > If so, I believe this type of protocols, and probably many others
> > similar to this one (there have been others passing by wayland-devel as
> > well), would be best suited "wayland-wall"[0] or something similar,
> > where modular compositor developers who want to choose what type of
> > modularity they want to support can pick at their discretion.
> > 
> > Thus, I don't think it is suitable for wayland-protocols, as I think the
> > focus of it should rather be an extension of Wayland proper
> > (wayland.xml) where client and compositor developers can look for
> > protocols that can be considered relatively portable. "Modular
> > compositor" protocols mostly cannot be portable in the same sense.
> 
> I have a few arguments to pose in response to this. Not all of this is
> in response to your specific concerns, but I'll extrapolate this
> discussion a bit based on what I expect to hear based on previous
> discussions.
> 
> 1. surface-layers learns from previous proposals
> 
> Similar protocols have been discussed here before, and have been largely
> rejected. I designed this protocol with the benefit of hindsight. The
> motivation behind rejecting many of these, I believe, is that they're
> too specific. Weston's desktop-shell.xml isn't suitable for
> wayland-protocols because it explicitly outlines the supported use-cases
> as things like panels and wallpapers and such, that specifically
> accommodate a likely Weston-specific desktop shell.

No. desktop-shell.xml is not suitable because it an implementation
detail of the sample desktop shell of weston. It's just one piece of
code, standing next to a bunch of C files. It has never had any
intention of being an exposed API, just as weston/desktop-shell/shell.h
is not. Being generic or not, is irrelevant.

> 
> This protocol (and the ones that will follow) support the same
> uses-cases, but are much more generic and applicable to a wide variety
> of compositors. As a consequence they also support a much wider range of
> use-cases than i.e. desktop-shell.xml. I'm sure you'll agree that this
> protocol can support many use cases we haven't though of, whereas
> desktop-shell.xml's wallpaper interfaces are tied quite closely to the
> specific use-case of wallpapers.
> 
> 2. wayland-protocols and wayland.xml already make similar and more
>egregious assumptions
> 
> I summarize this aspect of your viewpoint as a desire to avoid
> desktop-specific paradigms leaking into core Wayland bits, and a desire
> for Wayland to support more novel compositor designs than the desktop.
> However, I think that (1) the damage is already done, and (2)
> surface-layers is conservative in this regard anyway.
> 
> Design choices have already landed in wayland-protocols and wayland.xml
> that are closely associated with a desktop UX. xdg-shell has interfaces
> which have clearly been designed to accommodate a traditional desktop UX
> and traditional UI toolkit designs. It includes features like the
> positioner, which only really exists to support context menus;
> minimizing and maximising; the implication that xdg surfaces are
> floating windows that are user-resizable with a mouse.
> 
> wayland.xml itself has several similar assumptions, including features
> like drag-and-drop and clipboard support. Both of these are arguably
> outside of the scope of wayland.xml, have clear origins in the desktop
> UX, and have questionable re-applicability for novel compositor designs.
> 
> surface-layers is comparatively much more

Re: libwayland-server ABI change: [PATCH] wayland-server: Destroy Clients upon wl_display_destroy()

[Jonas Ådahl]

On Mon, Jan 23, 2017 at 03:40:11PM +0200, Pekka Paalanen wrote:
> On Tue, 20 Dec 2016 18:40:13 +0530
> viveka  wrote:
> 
> > From: "Vivek.A" 
> > 
> > Without this, client socket file descriptors are being kept open until 
> > the process
> > hosting the compositor gets terminated / exit. This causes compositor 
> > termination
> > goes undetected through its fd. This could be reproduced by having 
> > compositor as
> > one of the threads in a process.
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=99142
> > 
> > Signed-off-by: Vivek.A 
> > ---
> >  src/wayland-server.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/src/wayland-server.c b/src/wayland-server.c
> > index 9d7d9c1..8195064 100644
> > --- a/src/wayland-server.c
> > +++ b/src/wayland-server.c
> > @@ -979,11 +979,16 @@ wl_socket_alloc(void)
> >  WL_EXPORT void
> >  wl_display_destroy(struct wl_display *display)
> >  {
> > +   struct wl_client *c, *cnext;
> > struct wl_socket *s, *next;
> > struct wl_global *global, *gnext;
> >  
> > wl_signal_emit(>destroy_signal, display);
> >  
> > +   wl_list_for_each_safe(c, cnext, >client_list, link) {
> > +   wl_client_destroy(c);
> > +   }
> > +
> > wl_list_for_each_safe(s, next, >socket_list, link) {
> > wl_socket_destroy(s);
> > }
> 
> Hi,
> 
> this needs an update on the documentation to say that existing clients
> are destroyed.
> 
> Previously it has been illegal to have existing clients when destroying
> a wl_display, because destroying a wl_client afterwards would have
> potentially accessed freed memory: wl_display::client_list list head.
> However, we failed to document this.
> 
> As far as I can tell, Weston also got it wrong, and never destroyed the
> clients before the wl_display.
> 
> Now starts the self-rant, which could be just TL;DR and conclude as: a
> good patch, fine by me if you add docs, but Weston is broken anyway.
> 
> ---
> 
> (A counter-proposition to this patch could be to just unlink the client
> list head, and leave the clients to be destroyed by the compositor. I
> have hard time imagining when that would be useful (Graceful shutdown
> waiting for clients to exit themselves? This is not a web server.) and
> it would be awkward to use, too. Also, destroying the wl_display
> removes the only supported way of polling and servicing the clients.
> Therefore I reject the counter-proposition.)
> 
> So I started wondering what happens in Weston, as I should really see
> the access to freed memory in valgrind, but I don't. Then I realized
> that nothing frees the remaining clients in Weston on shutdown. Ok, I
> should see a reduction in leaked memory then. But the results are
> depressing.
> 
> Start weston on x11:
> 
> $ valgrind -v --leak-check=full --show-reachable=yes --track-origins=yes 
> --num-callers=30 weston --use-pixman
> 
> Then click (twice... why twice...) the icon to start weston_terminal,
> and then close weston while the terminal window is open. This is needed
> to have a client remain, because the shell helper clients get torn down
> anyway.
> 
> 
> Before patch:
> 
> ==23476== LEAK SUMMARY:
> ==23476==definitely lost: 232 bytes in 3 blocks
> ==23476==indirectly lost: 22,890 bytes in 47 blocks
> ==23476==  possibly lost: 163 bytes in 4 blocks
> ==23476==still reachable: 72,450 bytes in 181 blocks
> ==23476== suppressed: 0 bytes in 0 blocks
> ==23476== 
> ==23476== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
> 
> After patch:
> 
> ==26025== LEAK SUMMARY:
> ==26025==definitely lost: 968 bytes in 4 blocks
> ==26025==indirectly lost: 1,584 bytes in 6 blocks
> ==26025==  possibly lost: 163 bytes in 4 blocks
> ==26025==still reachable: 72,450 bytes in 181 blocks
> ==26025== suppressed: 0 bytes in 0 blocks
> ==26025== 
> ==26025== ERROR SUMMARY: 23 errors from 21 contexts (suppressed: 0 from 0)
> 
> The indirectly lost amount goes down as expected, but the number of
> errors grows badly.
> 
> I suppose the thing is that weston has already pretty much shut down by
> the time it calls wl_display_destroy(). It's not prepared to resources
> still existing after shutdown, so when wl_display_destroy() goes
> destroying the remaining clients, their resources get destroyed, which
> then accesses freed memory because the tracking infrastructure has
> already been freed and the resources are full of stale pointers.
> 
> But that is Weston's problem.
> 
> One might think to move wl_display_destroy() earlier, but it feels
> fundamentally wrong, and would likely screw up so many places that
> assume the display exists. So I won't go there.
> 
> Weston will need fixing in any case, but the question is how.
> 
> Do we apply this patch which automatically destroys remaining clients?
> The alternative is to declare the opposite.
> 
> If we do, then Weston has 

Re: [PATCHv3] Add surface-layers protocol

[Jonas Ådahl]

Hi,

By the looks of it, this is a protocol extension that aims to enable
desktop environments to be built of interoperable components (i.e. a
"background" process to draw a (live?) wallpaper, an "overlay" thing
could be used to create a panel, popup launcher or alt-tab view or
something). Is this correct?

If so, I believe this type of protocols, and probably many others
similar to this one (there have been others passing by wayland-devel as
well), would be best suited "wayland-wall"[0] or something similar,
where modular compositor developers who want to choose what type of
modularity they want to support can pick at their discretion.

Thus, I don't think it is suitable for wayland-protocols, as I think the
focus of it should rather be an extension of Wayland proper
(wayland.xml) where client and compositor developers can look for
protocols that can be considered relatively portable. "Modular
compositor" protocols mostly cannot be portable in the same sense.

If I misunderstood the intention of the protocol, do let me know. I
didn't see any use cases spelled out, so I am just assuming.

Maybe it would make sense to link wayland-wall from
wayland.freedesktop.org as a possible path to take for "modular
compositor" developers looking for protocols for components? Are there
any other projects trying to do the same?


Jonas

[0] https://github.com/wayland-wall/wayland-wall

On Tue, Jan 24, 2017 at 07:47:30PM -0500, Drew DeVault wrote:
> Signed-off-by: Drew DeVault 
> ---
> This revision addresses much of Yong's feedback. It changes some of the
> language to more closely match other protocols, fixes a few typos, and
> clarifies some descriptions. I disagree with the use of a bitfield for
> anchors in xdg-shell et al, but I chose to reuse that design per Yong's
> suggestion, for the sake of consistency. I chose not to add many
> descriptions as Yong suggested, where I felt that the nature of the
> fields were self-evident.
> 
> Cheers!
> 
>  unstable/surface-layers/README |   4 +
>  unstable/surface-layers/surface-layers.xml | 151 
> +
>  2 files changed, 155 insertions(+)
>  create mode 100644 unstable/surface-layers/README
>  create mode 100644 unstable/surface-layers/surface-layers.xml
> 
> diff --git a/unstable/surface-layers/README b/unstable/surface-layers/README
> new file mode 100644
> index 000..662f488
> --- /dev/null
> +++ b/unstable/surface-layers/README
> @@ -0,0 +1,4 @@
> +Surface layers protocol
> +
> +Maintainers:
> +Drew DeVault 
> diff --git a/unstable/surface-layers/surface-layers.xml 
> b/unstable/surface-layers/surface-layers.xml
> new file mode 100644
> index 000..fe621ef
> --- /dev/null
> +++ b/unstable/surface-layers/surface-layers.xml
> @@ -0,0 +1,151 @@
> +
> +
> +
> +  
> +Copyright © 2017 Drew DeVault
> +
> +Permission to use, copy, modify, distribute, and sell this
> +software and its documentation for any purpose is hereby granted
> +without fee, provided that the above copyright notice appear in
> +all copies and that both that copyright notice and this permission
> +notice appear in supporting documentation, and that the name of
> +the copyright holders not be used in advertising or publicity
> +pertaining to distribution of the software without specific,
> +written prior permission.  The copyright holders make no
> +representations about the suitability of this software for any
> +purpose.  It is provided "as is" without express or implied
> +warranty.
> +
> +THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> +SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> +FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> +SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> +AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> +THIS SOFTWARE.
> +  
> +
> +  
> +
> +  Clients can use this interface to assign the surface_layer role to
> +  wl_surfaces. Such surfaces are assigned to a "layer" of the output and
> +  rendered with a defined z-depth respective to each other. They may 
> also be
> +  anchored to the edges and corners of a screen and specify input 
> handling
> +  semantics. This interface should be suitable for the implementation of
> +  many desktop shell components, and a broad number of other applications
> +  that interact with the desktop.
> +
> +
> +
> +  
> +These values indicate which layers a surface can be rendered in. They
> +are ordered by z depth, bottom-most first. Traditional shell surfaces
> +will typically be rendered between the bottom and top layers. 
> Multiple
> +surfaces can share a single layer.
> +  
> +
> +  
> +  

Re: [PATCH] xdg-shell: require popups to intersect with or be adjacent to parent surfaces

[Jonas Ådahl]

On Mon, Dec 19, 2016 at 11:56:38AM -0500, Mike Blumenkrantz wrote:
> some restrictions must be placed on this or else it becomes legal for
> the compositor to place popups in unexpected locations
> 
> Signed-off-by: Mike Blumenkrantz 

Pushed:

   642dd7a..375385e  master -> master

Jonas

> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index e49d74f..1c0f924 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -118,7 +118,9 @@
>child surface relative to a parent surface. Rules can be defined to 
> ensure
>the child surface remains within the visible area's borders, and to
>specify how the child surface changes its position, such as sliding 
> along
> -  an axis, or flipping around a rectangle.
> +  an axis, or flipping around a rectangle. These positioner-created 
> rules are
> +  constrained by the requirement that a child surface must intersect 
> with or
> +  be at least partially adjacent to its parent surface.
>  
>See the various requests for details about possible rules.
>  
> @@ -941,7 +943,8 @@
>The x and y arguments passed when creating the popup object specify
>where the top left of the popup should be placed, relative to the
>local surface coordinates of the parent surface. See
> -  xdg_surface.get_popup.
> +  xdg_surface.get_popup. An xdg_popup must intersect with or be at least
> +  partially adjacent to its parent surface.
>  
>The client must call wl_surface.commit on the corresponding wl_surface
>for the xdg_popup state to take effect.
> -- 
> 2.5.5
> 
> ___
> 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: [RFE wayland] protocol: add axis_source.wheel_tilt

[Jonas Ådahl]

On Wed, Jan 04, 2017 at 03:18:07PM +1000, Peter Hutterer wrote:
> On Tue, Dec 06, 2016 at 02:31:22PM +1000, Peter Hutterer wrote:
> > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
> > ---
> > This is missing the various version bumps, it's just an RFE at this point.
> > We have a bit of a problem with the axis sources in the wayland protocol in
> > that they're sent but not really explained well in the protocol.
> > 
> > So to match the rest we pretty much just need to add tilt. And then maybe
> > define the other axis sources more verbosely. Hindsight and whatnot.
> > 
> >  protocol/wayland.xml | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> Any opinions on this?

I can't see anything wrong with adding this, and I have no better idea
what source to assign a wheel tilt axis event.

So consider this

Reviewed-by: Jonas Ådahl <jad...@gmail.com>


Jonas

> 
> Cheers,
>Peter
> 
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 098f286..0735997 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1986,10 +1986,15 @@
> > finger. One example for this source is button-based scrolling where
> > the vertical motion of a device is converted to scroll events while
> > a button is held down.
> > +
> > +   The "wheel tilt" axis source indicates that the actual device is a
> > +   wheel but the scroll event is not caused by a rotation but a
> > +   (usually sideways) tilt of the wheel.
> >
> > -  
> > +  
> >
> >
> > +  
> >  
> >  
> >  
> > @@ -2004,7 +2009,8 @@
> > wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be
> > sent when the user lifts the finger off the device.
> >  
> > -   If the source is wl_pointer axis_source.wheel or
> > +   If the source is wl_pointer.axis_source.wheel,
> > +   wl_pointer.axis_source.wheel_tilt or
> > wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may
> > or may not be sent. Whether a compositor sends an axis_stop event
> > for these sources is hardware-specific and implementation-dependent;
> > -- 
> > 2.9.3
>  
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v2 2/2] xdg-shell: Fold several client-side decoration requests into a generic request

[Jonas Ådahl]

On Thu, Dec 29, 2016 at 07:59:40PM -0500, Adam Goode wrote:
> On Mon, Dec 19, 2016 at 10:15 PM, Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > On Mon, Dec 19, 2016 at 12:55:24PM -0500, Adam Goode wrote:
> > > Compositors currently receive "move", "resize", and "show_window_menu"
> > > requests from clients whose decorations have been interacted with.
> > > Clients currently implement key- and mouse-binding policies to
> > > determine which one of these requests to send to the compositor in
> > > response to user action.
> > >
> > > Desktop environments traditionally have let users bind a large number of
> > > potential actions to various interactions with decorations: not just a
> > > handful like move and resize.
> > >
> > > This change to xdg-shell makes the protocol more generic, allowing more
> > > surface management policy to be implemented in the compositor directly.
> > > This centralizes more policy in compositors, reducing policy duplication
> > > from client toolkits and allowing for more standard surface management
> > > behavior across them.
> >
> > Hi,
> >
> > I think this is an interesting proposal, but I don't agree it's the
> > right way to do it. Especially, I don't think we should replace
> > move/resize with it, and I think it should be a separate extension.
> > Reasons for this ar 1) triggering a move is not limited window
> > decorations and I don't think its reasonable to define each such area
> > separately, 2) a client is expected to show feedback (i.e. change
> > cursor sprite) when hovering over area that would trigger a resize, this
> > will not be possible since a client has no idea what will happen when
> > clicked anymore, 3) using move/resie requests are proven to work well
> > for what they are meant to do, 4) we're in a state where any major
> > changes will set us back considerably when it comes to getting xdg-shell
> > in state where we can move forward with a backward compatible base.
> >
> > Given this, I wouldn't mind this added as an extension. Whether this
> > extension will eventually be added into xdg-shell "proper" can be
> > discussed at a later point when we have some experience "in the wild",
> > but that is not where we are now. I'd happily review such an extension,
> > but I oppose bumping xdg-shell and replacing move/resize as is proposed
> > here.
> >
> >
> > Jonas
> >
> >
> Hi Jonas,
> 
> I've been looking into how to do this properly. I've reached a bit of an
> impasse. Specifically, I am thinking about the problems of roundtrips.
> 
> Currently, move, resize, and show_window_menu take a serial that the
> compositor remembers. In looking at weston and mutter, this is done through
> implicit grabs, which (appear) to save the last single-button click that
> happened. There is a race condition, because if the client stalls, a new
> implicit grab may occur and wipe out the old one before the move/resize/etc
> request is sent and processed. It mostly works because roundtrips are fast
> enough and clients rarely stall. I think the compositor would just ignore
> the event if the serial doesn't match the latest grab. Lost events lead to
> a bad experience.
> 
> We could increase the number of implicit grabs that compositors remember,
> but that would lead to more desynchronization, as client requests come in
> that say "that old event from a while ago was actually a move". It is way
> more complicated to handle than the current single-slot implicit grab that
> compositors use, and seems counter-waylandic to rely on all these
> roundtrips and introduce these race conditions.
> 
> My original plans were to continue this reasoning and press on with the
> generic "interact" request. In implementing, I would probably need to look
> into storing at least a few grabs, to let compositors recognize
> double-clicks and such. It was looking a bit sketchy already, but then I
> noticed that axis events don't provide serials, and it would be nice to let
> "interact" allow users to implement other classic bindings, such as "spin
> mousewheel on titlebar to shade". Looking into how axis events are
> delivered to clients really made me start to think if this was the correct
> way at all.
> 
> A complex way to solve the race condition would be for clients to use a
> decoration mask that would be committed to the server along with surface
> updates. Then the compositor would know at all times exactly what
> interactions are on what decorations. This would easily allow comp

Re: Hide or show the surface

[Jonas Ådahl]

On Fri, Dec 23, 2016 at 09:52:45AM +0800, Anthenony wrote:
> Hi, All:
> 
> 
> As far as I know there is no interface to hide or show the client. I want 
> to make sure whether other method is feasible.
> For example, I move the client out of the screen.
> 
> Hide:
> attach(m_wl_sufface, 1000, 1000);
> commit();
>  
> Show:
> attach(m_wl_sufface, 0, 0);
> commit();
> 
> 
> Anyway, is there any other methods?

Attaching with an offset should not be used to hide a surface. It's a
total abuse of those parameters and will definitely not work reliably. I
wouldn't be surprised if compositors will blatantly terminate clients
abusing it in such ways, since it would make no sense from the point of
view of the way those parameters were intended to be used.

The proper way depends on the role the surface has. For example if it's
a pointer cursor surface, and you want to hide the cursor, you set the
pointer cursor to a NULL surface. If it's a shell surface (xdg_toplevel
or a toplevel wl_shell_surface) you unmap it; how unmapping is done
depends on the protocol defining the role. For example if it's a
xdg_toplevel, to unmap the surface you destroy the xdg_toplevel and
xdg_surface objects. For wl_shell_surface clients, it's similar; destroy
the wl_shell_surface object to unmap the surface.

For other roles, it's up to the role to define how to hide/unmap the
corresponding surface view.


Jonas

> 
> 
> 
> 
> Best regards,
> Anthenony

> ___
> 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: [PATCH wayland v2] doc: start documenting Xwayland

[Jonas Ådahl]

On Mon, Dec 05, 2016 at 03:52:19PM +0200, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> 
> This is a rough intro to what Xwayland is and does, with just one
> implementation detail so far (Window identification).
> 
> I paid no attention to formatting details, those can be polished in
> follow-ups. I just want the prose out.
> 
> I also just quickly whacked up the diagram, would be happy to see
> someone replace it with a nicer one. I just didn't have time to learn
> dot for now.
> 
> v2:
> - typo fix
> - rephrase "talking to hardware" as "driving the displays"
> - mention circular dependency in intro
> - add section to explain rootless and rootful modes
> - remove paragraph about Xwayland protocol usage
> - move TBD part to the end under a new section header
> 
> Cc: Olivier Fourdan <ofour...@redhat.com>
> Cc: Jonas Ådahl <jad...@gmail.com>
> Cc: Daniel Stone <dan...@fooishbar.org>
> Signed-off-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
> ---
>  doc/publican/Makefile.am   |   5 +-
>  doc/publican/sources/Wayland.xml   |   1 +
>  doc/publican/sources/Xwayland.xml  | 207 
> +
>  .../sources/images/xwayland-architecture.png   | Bin 0 -> 7611 bytes
>  4 files changed, 212 insertions(+), 1 deletion(-)
>  create mode 100644 doc/publican/sources/Xwayland.xml
>  create mode 100644 doc/publican/sources/images/xwayland-architecture.png
> 
> diff --git a/doc/publican/Makefile.am b/doc/publican/Makefile.am
> index 57728a0..e861fe6 100644
> --- a/doc/publican/Makefile.am
> +++ b/doc/publican/Makefile.am
> @@ -24,9 +24,11 @@ publican_sources = \
>   $(srcdir)/sources/Preface.xml \
>   $(srcdir)/sources/Revision_History.xml \
>   $(srcdir)/sources/Protocol.xml \
> + $(srcdir)/sources/Xwayland.xml \
>   $(srcdir)/sources/Compositors.xml \
>   $(srcdir)/sources/images/icon.svg  \
>   $(srcdir)/sources/images/wayland.png \
> + $(srcdir)/sources/images/xwayland-architecture.png \
>   $(srcdir)/sources/Client.xml \
>   $(srcdir)/sources/Server.xml
>  
> @@ -43,7 +45,8 @@ css_sources = \
>  
>  img_sources = \
>   $(srcdir)/sources/images/icon.svg \
> - $(srcdir)/sources/images/wayland.png
> + $(srcdir)/sources/images/wayland.png \
> + $(srcdir)/sources/images/xwayland-architecture.png
>  
>  doxygen_img_sources := \
>   $(doxydir)/xml/wayland-architecture.png \
> diff --git a/doc/publican/sources/Wayland.xml 
> b/doc/publican/sources/Wayland.xml
> index 2f47f13..0457c15 100644
> --- a/doc/publican/sources/Wayland.xml
> +++ b/doc/publican/sources/Wayland.xml
> @@ -11,6 +11,7 @@
> xmlns:xi="http://www.w3.org/2001/XInclude; />
> xmlns:xi="http://www.w3.org/2001/XInclude; />
>http://www.w3.org/2001/XInclude; 
> />
> +  http://www.w3.org/2001/XInclude; 
> />
> xmlns:xi="http://www.w3.org/2001/XInclude; />
>http://www.w3.org/2001/XInclude"/>
>http://www.w3.org/2001/XInclude"/>
> diff --git a/doc/publican/sources/Xwayland.xml 
> b/doc/publican/sources/Xwayland.xml
> new file mode 100644
> index 000..20e94e3
> --- /dev/null
> +++ b/doc/publican/sources/Xwayland.xml
> @@ -0,0 +1,207 @@
> +
> + "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; [
> +
> +%BOOK_ENTITIES;
> +]>
> +
> +  X11 Application Support
> +  
> +Introduction
> +
> +  Being able to run existing X11 applications is crucial for the adoption
> +  of Wayland, especially on desktops, as there will always be X11
> +  applications that have not been or cannot be converted into Wayland
> +  applications, and throwing them all away would be prohibitive.
> +  Therefore a Wayland compositor often needs to support running X11
> +  applications.
> +
> +
> +  X11 and Wayland are different enough that there is no "simple" way to
> +  translate between them. Most of X11 is uninteresting to a Wayland
> +  compositor. That combined with the gigantic implementation effort 
> needed
> +  to support X11 makes it intractable to just write X11 support directly 
> in
> +  a Wayland compositor. The implementation would be nothing short from a
> +  real X11 server.
> +
> +
> +  Therefore Wayland compositors should use Xwayland, the X11 server that
> +  lives in the Xorg server source code repository and shares most of the
> +  implementation with the Xorg server. Xwayland is a complete X11 server,
> +  just like Xorg i

Re: [PATCH v2 2/2] xdg-shell: Fold several client-side decoration requests into a generic request

[Jonas Ådahl]

On Mon, Dec 19, 2016 at 12:55:24PM -0500, Adam Goode wrote:
> Compositors currently receive "move", "resize", and "show_window_menu"
> requests from clients whose decorations have been interacted with.
> Clients currently implement key- and mouse-binding policies to
> determine which one of these requests to send to the compositor in
> response to user action.
> 
> Desktop environments traditionally have let users bind a large number of
> potential actions to various interactions with decorations: not just a
> handful like move and resize.
> 
> This change to xdg-shell makes the protocol more generic, allowing more
> surface management policy to be implemented in the compositor directly.
> This centralizes more policy in compositors, reducing policy duplication
> from client toolkits and allowing for more standard surface management
> behavior across them.

Hi,

I think this is an interesting proposal, but I don't agree it's the
right way to do it. Especially, I don't think we should replace
move/resize with it, and I think it should be a separate extension.
Reasons for this ar 1) triggering a move is not limited window
decorations and I don't think its reasonable to define each such area
separately, 2) a client is expected to show feedback (i.e. change
cursor sprite) when hovering over area that would trigger a resize, this
will not be possible since a client has no idea what will happen when
clicked anymore, 3) using move/resie requests are proven to work well
for what they are meant to do, 4) we're in a state where any major
changes will set us back considerably when it comes to getting xdg-shell
in state where we can move forward with a backward compatible base.

Given this, I wouldn't mind this added as an extension. Whether this
extension will eventually be added into xdg-shell "proper" can be
discussed at a later point when we have some experience "in the wild",
but that is not where we are now. I'd happily review such an extension,
but I oppose bumping xdg-shell and replacing move/resize as is proposed
here.


Jonas

> 
> Signed-off-by: Adam Goode <ago...@google.com>
> ---
>  COPYING  |   1 +
>  unstable/xdg-shell/xdg-shell-unstable-v7.xml | 137 
> +++
>  2 files changed, 55 insertions(+), 83 deletions(-)
> 
> diff --git a/COPYING b/COPYING
> index 8ab3291..73cebf9 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -6,6 +6,7 @@ Copyright © 2014  Jonas Ådahl
>  Copyright © 2014  Jason Ekstrand
>  Copyright © 2014-2015 Collabora, Ltd.
>  Copyright © 2015  Red Hat Inc.
> +Copyright © 2016  Google Inc.
>  
>  Permission is hereby granted, free of charge, to any person obtaining a
>  copy of this software and associated documentation files (the "Software"),
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v7.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v7.xml
> index de5d21c..5b99eec 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v7.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v7.xml
> @@ -580,101 +580,72 @@
>
>  
>  
> -
> -  
> - Clients implementing client-side decorations might want to show
> - a context menu when right-clicking on the decorations, giving the
> - user a menu that they can use to maximize or minimize the window.
> -
> - This request asks the compositor to pop up such a window menu at
> - the given position, relative to the local surface coordinates of
> - the parent surface. There are no guarantees as to what menu items
> - the window menu contains.
> -
> - This request must be used in response to some sort of user action
> - like a button press, key press, or touch down event.
> -  
> -  
> -  
> -  
> -  
> -
> -
> -
> -  
> - Start an interactive, user-driven move of the surface.
> -
> - This request must be used in response to some sort of user action
> - like a button press, key press, or touch down event. The passed
> - serial is used to determine the type of interactive move (touch,
> - pointer, etc).
> -
> - The server may ignore move requests depending on the state of
> - the surface (e.g. fullscreen or maximized), or if the passed serial
> - is no longer valid.
> -
> - If triggered, the surface will lose the focus of the device
> - (wl_pointer, wl_touch, etc) used for the move. It is up to the
> - compositor to visually indicate that the move is taking place, such as
> - updating a pointer cursor, during the move. There is no guarantee
> - that the device focus will return when the move is completed.
> -  
> -

Re: [PATCH] xdg-shell: require popups to intersect with or be adjacent to parent surfaces

[Jonas Ådahl]

On Mon, Dec 19, 2016 at 11:56:38AM -0500, Mike Blumenkrantz wrote:
> some restrictions must be placed on this or else it becomes legal for
> the compositor to place popups in unexpected locations
> 
> Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>

Could be further specified further that its about window geometry and
not just the surface I guess, but this is an improvement so:

Reviewed-by: Jonas Ådahl <jad...@gmail.com>


Jonas

> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index e49d74f..1c0f924 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -118,7 +118,9 @@
>child surface relative to a parent surface. Rules can be defined to 
> ensure
>the child surface remains within the visible area's borders, and to
>specify how the child surface changes its position, such as sliding 
> along
> -  an axis, or flipping around a rectangle.
> +  an axis, or flipping around a rectangle. These positioner-created 
> rules are
> +  constrained by the requirement that a child surface must intersect 
> with or
> +  be at least partially adjacent to its parent surface.
>  
>See the various requests for details about possible rules.
>  
> @@ -941,7 +943,8 @@
>The x and y arguments passed when creating the popup object specify
>where the top left of the popup should be placed, relative to the
>local surface coordinates of the parent surface. See
> -  xdg_surface.get_popup.
> +  xdg_surface.get_popup. An xdg_popup must intersect with or be at least
> +  partially adjacent to its parent surface.
>  
>The client must call wl_surface.commit on the corresponding wl_surface
>for the xdg_popup state to take effect.
> -- 
> 2.5.5
> 
> ___
> 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: [PATCH] xdg-shell: require that popups intersect with parent surfaces

[Jonas Ådahl]

On Thu, Dec 08, 2016 at 11:00:10AM -0500, Mike Blumenkrantz wrote:
> some restrictions must be placed on this or else it becomes legal for
> the compositor to place popups in unexpected locations
> 
> Signed-off-by: Mike Blumenkrantz 
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index e49d74f..ab270b8 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -118,7 +118,9 @@
>child surface relative to a parent surface. Rules can be defined to 
> ensure
>the child surface remains within the visible area's borders, and to
>specify how the child surface changes its position, such as sliding 
> along
> -  an axis, or flipping around a rectangle.
> +  an axis, or flipping around a rectangle. These positioner-created 
> rules are
> +  constrained by the requirement that a child surface must intersect 
> with its
> +  parent surface.

I think it should be fine if they simply "touch" as in the intersection
is empty, but there is no space in between.

Otherwise I think it looks good.


Jonas

>  
>See the various requests for details about possible rules.
>  
> @@ -941,7 +943,7 @@
>The x and y arguments passed when creating the popup object specify
>where the top left of the popup should be placed, relative to the
>local surface coordinates of the parent surface. See
> -  xdg_surface.get_popup.
> +  xdg_surface.get_popup. An xdg_popup must intersect with its parent 
> surface.
>  
>The client must call wl_surface.commit on the corresponding wl_surface
>for the xdg_popup state to take effect.
> -- 
> 2.5.5
> 
> ___
> 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: [PATCH v3] protocol: Define further the behavior of input on the presence of grabs

[Jonas Ådahl]

On Wed, Nov 23, 2016 at 06:32:07PM +0100, Carlos Garnacho wrote:
> The leave events in the respective device interfaces has been further
> documented so those can convey the necessary info when input is being
> redirected out of their currently focused surface.
> 
> Only wl_touch is missing something semantically similar, a wl_touch.leave
> event has been added so the touch interface can cope with such input
> redirection situations on individual touchpoints.
> 
> Signed-off-by: Carlos Garnacho 
> ---
> 
> v2: Reuse leave events for this purpose. This meant one had to be added
> on wl_touch.
> v3: Improved wording (I hope!) largely inspired on the suggestions from
> Daniel Stone. Bumped wl_seat version to 6 for wl_touch.leave.
> 
>  protocol/wayland.xml | 61 
> +++-
>  1 file changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 6c6d078..16fc0b3 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1669,7 +1669,7 @@
>  
> 
>  
> -  
> +  
>  
>A seat is a group of keyboards, pointer and touch devices. This
>object is published as a global during start up, or when such a
> @@ -1859,6 +1859,23 @@
>  
>   The leave notification is sent before the enter notification
>   for the new focus.
> +
> + Normally, a pointer will not leave a surface while there are
> + buttons pressed, there's however circumstances where this event
> + may be received in this situation, for example:
> +
> + - When a popup is shown by this or other client.
> + - When a drag-and-drop operation is initiated from this or
> +   any other surface.
> + - Other compositor-specific grabs, like pointer gestures.
> +
> + In these situations, a leave event will be emitted with no
> + pairing button release events on this surface, clients must undo
> + their internal state related to the ongoing button presses.
> +
> + Clients must either receive a release or a leave event in a
> + timely manner, and strictly before all other input events from
> + that seat.
>
>
> summary="surface left by the pointer"/>
> @@ -1893,6 +1910,10 @@
>   enter event.
>  The time argument is a timestamp with millisecond
>  granularity, with an undefined base.
> +
> + Clients should note that pressed/released events may not be paired;
> + in some cases, a leave event will be sent in place of a released event.
> + See wl_pointer.leave for more details.
>
>  
>
> @@ -2136,6 +2157,17 @@
>  
>   The leave notification is sent before the enter notification
>   for the new focus.
> +
> + There may be circumstances that force the keyboard focus to be taken
> + away from a surface while there are pressed keys, for example:
> +
> + - When a popup is shown by this or other client.
> + - When a drag-and-drop operation is initiated from this or
> +   any other surface.
> +
> + In these situations, a leave event will be emitted with no pairing
> + key release events on this surface, clients must undo their internal
> + state related to the ongoing key presses.
>
>
> summary="surface that lost keyboard focus"/>
> @@ -2154,6 +2186,10 @@
>   A key was pressed or released.
>  The time argument is a timestamp with millisecond
>  granularity, with an undefined base.
> +
> + Clients should note that pressed/released events may not be paired;
> + in some cases, a leave event will be sent in place of a released event.
> + See wl_keyboard.leave for more details.
>
>  
>
> @@ -2238,6 +2274,10 @@
>   The touch point has disappeared. No further events will be sent for
>   this touch point and the touch point's ID is released and may be
>   reused in a future touch down event.
> +
> + Clients should note that down/up events may not be paired;
> + in some cases, a leave event will be sent in place of a wl_touch.up
> + event. See wl_touch.leave for more details.
>
>
>
> @@ -2276,6 +2316,25 @@
>  
>
>  
> +
> +
> +
> +
> +  
> + Notification that this touch point is no longer focused on a
> + certain surface.
> +
> + Note that, because touch points are always implicitly grabbed,
> + this event will only be emitted when the touch point is taken
> + away from this surface through explicit means, for example:
> +
> + - When a popup is shown by this or other client.
> + - When a drag-and-drop operation is initiated from this or
> +   any other surface.

Should we make this grouped by wl_touch.frame, just as
wl_pointer.leave is rfamed by wl_pointer.frame?


Jonas

> +  
> +  
> +  
> +
>
>  
>
> -- 
> 2.9.3
> 
> ___
> 

Re: Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

[Jonas Ådahl]

On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:
> On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> 
> > On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:
> > > Hi,
> > >
> > > See https://bugzilla.redhat.com/show_bug.cgi?id=1349225 and
> > > https://bugzilla.gnome.org/show_bug.cgi?id=767967
> > >
> > > When using Client Side Decorations, toolkits cannot bind raise or lower
> > to
> > > user actions. This binding is traditionally used in the "middle click
> > > titlebar to lower" action, which no longer works with CSD on Wayland.
> > > Additionally, when click-to-raise is disabled, a click on a CSD titlebar
> > > will not raise the window.
> > >
> > > I would like to add 'raise' and 'lower' to xdg-shell. These requests will
> > > take no arguments, similarly to 'set_maximized' (which is commonly bound
> > to
> > > double-click titlebar).
> >
> > A client should not be able to raise itself on demand like that. Usually
> > when raising, what they actually wanted to do is get attention because
> > something happened, and that is what an API is supposed to do. I think
> > the last time this was discussed it was referred to as "present" or
> > something. GTK+ have a private protocol for this until we have something
> > else.
> >
> > Regarding 'lower', any reason why this cannot be made a compositor side
> > modifier->middle-click kind of thing? It'd work on the whole window and
> > it'd work on all clients without any need for any protocol. There has
> > also been discussions about having a protocol for specifying a "window
> > title area" kind of thing, which the compositor can handle with special
> > care would so be needed.
> >
> >
> The compositor side modifier->middle-click does work this way in mutter
> today. Having support for bare clicks with special meaning in certain
> regions is the more subtle case. What this means today is that if you
> configure your compositor with no-raise-on-click (for the traditional X
> behavior), then windows with CSD don't get raised when decorations are
> clicked (unless you hold a modifier key).
> 
> The idea of having a special title-bar area known to the compositor seems
> worth pursuing, but that could be abused by clients. CSD blended the lines
> between client and compositor roles, and X was happy to be permissive with
> that situation. I'm glad Wayland is non-permissive by default, but it does
> make things tricky.

Right, and since the lines are now comparably blurry, I think it makes
sense to move away from clients doing window management when we have the
chance. Personally I'd vote for getting rid of the
"middle-click-on-title-lowers" binding in mutter X11 SSD paths rather
than adding it to GTK+.

> 
> I would really like to avoid having direct ways for a client to
> > interfere with the window stacking, and especially not ones that require
> > round trips.
> >
> >
> As an alternative, what do you think of a raise/lower protocol that
> required evidence of a click to trigger? The client could decide on its own
> which buttons did what on which region of its surface (necessary for CSD),
> but prove to the compositor that a click of some kind actually occurred.
> 

There is still no reason why a client needs to have the ability to raise
itself when it can communicate what it actually wanted. IIRC the
"present" proposal used input event serials (i.e. allowed the compositor
to match against a click/touch/...) at its discretion.


Jonas

> 
> 
> > >
> > > Is there any objection to adding these to xdg-shell, or should I
> > > investigate another solution?
> > >
> >
> > xdg-shell is in a state where I don't think we should add anything that
> > is not very crucial until we have managed to declare it stable. A thing
> > like lower/raise, which has been discussed plenty of times and is on the
> > more controversial side, should not delay any stabilization of
> > xdg-shell. With that said, things can be added as separate extensions in
> > the mean time.
> >
> >
> > Jonas
> >
> > >
> > >
> > > Thanks,
> > >
> > > Adam
> >
> > > ___
> > > 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