Re: [PATCH weston] Makefile: fix systemd-notify plugin CFLAGS

[Bryce Harrington]

On Tue, Apr 05, 2016 at 02:08:11PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> SYSTEMD_DAEMON_LIBS does not belong in CFLAGS, but SYSTEMD_DAEMON_CFLAGS
> does. Fix that.
> 
> Add the missing COMPOSITOR_CFLAGS. Otherwise compiling the plugin will
> use the system wayland-server.h when it should be using the one pointed
> to by pkg-config.
> 
> The latter fixes the build for me, as my system libwayland-server is
> older than what Weston and this plugin require, and the correct version
> is only found in my install $prefix.
> 
> Cc: Egor Starkov 
> Cc: Eugen Friedrich 
> Signed-off-by: Pekka Paalanen 
Reviewed-by: Bryce Harrington 

Went ahead and pushed it, too:
   7b3a52a..aff703e  master -> master

> ---
>  Makefile.am | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.am b/Makefile.am
> index d1644ac..9bed32c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -102,7 +102,8 @@ module_LTLIBRARIES += systemd-notify.la
>  systemd_notify_la_LDFLAGS = -module -avoid-version
>  systemd_notify_la_LIBADD = $(SYSTEMD_DAEMON_LIBS)
>  systemd_notify_la_CFLAGS =   \
> - $(SYSTEMD_DAEMON_LIBS)  \
> + $(COMPOSITOR_CFLAGS)\
> + $(SYSTEMD_DAEMON_CFLAGS)\
>   $(PIXMAN_CFLAGS)\
>   $(AM_CFLAGS)
>  systemd_notify_la_SOURCES =  \
> -- 
> 2.7.3
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH libinput] touchpad: enlarge top button area by a factor 3 instead of 1.5

[Peter Hutterer]

From: Peter Frühberger 

When the touchpad is disabled, the top software button on the Lenovo T440
series touchpads currently enlarge by a factor of 1.5 (to 15mm). This is not
enough, a user has to rotate the wrist quite uncomfortable when using
the left mouse button.

When the touchpad itself is off anyway we can extend the size of the top
software buttons to the factor 3, i.e. 30mm.

Signed-off-by: Peter Frühberger 
Signed-off-by: Peter Hutterer  
---
 src/evdev-mt-touchpad.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 0640974..6c8ab37 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -1156,7 +1156,7 @@ tp_suspend(struct tp_dispatch *tp, struct evdev_device 
*device)
if (tp->buttons.has_topbuttons) {
evdev_notify_suspended_device(device);
/* Enlarge topbutton area while suspended */
-   tp_init_top_softbuttons(tp, device, 1.5);
+   tp_init_top_softbuttons(tp, device, 3.0);
} else {
evdev_device_suspend(device);
}
-- 
2.7.4


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

Re: [PATCH wayland-build-tools] wl_install_deps: Add missing dependencies, remove INCLUDE_XWAYLAND logic

[Bryce Harrington]

On Wed, Apr 13, 2016 at 05:29:31PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> Building on Ubuntu 15.10 x64 fails due to missing packages:
> libtool, libxml2-dev, libpng-dev, libglib2.0-dev, libgudev-1.0-dev,
> libgcrypt20-dev, x11proto-scrnsaver-dev, libxfont-dev, and libedit-dev.
> 
> In addition, building with INCLUDE_XWAYLAND=0 causes failures due to missing
> package dependencies that would otherwise be installed when 
> INCLUDE_XWAYLAND=1.
> With only ~two packages not needing to be installed, it seems more simple to
> remove this logic from wl_install_deps entirely.
> 
> After these changes, wl_build succeeds on Ubuntu 15.10 x64.

Thanks for investigating this.

I do think there may still be a benefit to having an ability to omit
Xwayland support from the build.  I could easily imagine some users
wanting to explore how Wayland works without X in the mix.

Also, it used to be the Xwayland dependencies were in some flux and
could be harder to get running than the base.  I think we're well beyond
that situation and unlikely to repeat it, but it's still a point to
consider.  There could be platforms that lack X infrastructure support,
but that want to run weston.

Bryce

> Signed-off-by: Yong Bakos 
> ---
>  wl_install_deps | 45 +
>  1 file changed, 25 insertions(+), 20 deletions(-)
> 
> diff --git a/wl_install_deps b/wl_install_deps
> index c400f6f..e9ba6ad 100755
> --- a/wl_install_deps
> +++ b/wl_install_deps
> @@ -3,7 +3,7 @@
>  . $HOME/.config/wayland-build-tools/wl_defines.sh
>  
>  # generic build dependencies for ubuntu
> -sudo apt-get -y install autoconf automake bison debhelper dpkg-dev flex
> +sudo apt-get -y install autoconf automake bison debhelper dpkg-dev flex 
> libtool
>  sudo apt-get -y install pkg-config quilt python-libxml2
>  
>  # wayland/weston specific stuff
> @@ -19,23 +19,28 @@ sudo apt-get -y install libpciaccess-dev
>  sudo apt-get -y install libudev-dev
>  sudo apt-get -y install llvm-dev
>  sudo apt-get -y install python-mako
> +sudo apt-get -y install libxml2-dev
> +sudo apt-get -y install libpng-dev
> +sudo apt-get -y install libglib2.0-dev
> +sudo apt-get -y install libgudev-1.0-dev
> +sudo apt-get -y install libgcrypt20-dev
> +sudo apt-get -y install x11proto-scrnsaver-dev
> +sudo apt-get -y install libxfont-dev
> +sudo apt-get -y install libedit-dev
>  
> -# xwayland specific stuff
> -if [ ${INCLUDE_XWAYLAND} ]; then
> - sudo apt-get -y install libxcb-composite0-dev
> - sudo apt-get -y install x11proto-randr-dev
> - sudo apt-get -y install x11proto-composite-dev
> - sudo apt-get -y install x11proto-xinerama-dev
> - sudo apt-get -y install x11proto-dri2-dev
> - sudo apt-get -y install x11proto-gl-dev
> - sudo apt-get -y install xutils-dev
> - sudo apt-get -y install libxcursor-dev
> - #sudo apt-get -y install libdrm-dev
> - sudo apt-get -y install libx11-dev
> - sudo apt-get -y install libx11-xcb-dev
> - #sudo apt-get -y install x11proto-dri3-dev
> - sudo apt-get -y install libxdamage-dev
> - sudo apt-get -y install libxext-dev
> - sudo apt-get -y install libxfixes-dev
> - sudo apt-get -y install libxxf86vm-dev
> -fi
> +sudo apt-get -y install libxcb-composite0-dev
> +sudo apt-get -y install x11proto-randr-dev
> +sudo apt-get -y install x11proto-composite-dev
> +sudo apt-get -y install x11proto-xinerama-dev
> +sudo apt-get -y install x11proto-dri2-dev
> +sudo apt-get -y install x11proto-gl-dev
> +sudo apt-get -y install xutils-dev
> +sudo apt-get -y install libxcursor-dev
> +# sudo apt-get -y install libdrm-dev
> +sudo apt-get -y install libx11-dev
> +sudo apt-get -y install libx11-xcb-dev
> +# sudo apt-get -y install x11proto-dri3-dev
> +sudo apt-get -y install libxdamage-dev
> +sudo apt-get -y install libxext-dev
> +sudo apt-get -y install libxfixes-dev
> +sudo apt-get -y install libxxf86vm-dev
> -- 
> 2.7.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 wayland-build-tools] readme: Add instructions

[Bryce Harrington]

On Wed, Apr 13, 2016 at 05:28:55PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> The original readme just had a link to the official build instructions,
> which does not help a user with these build tools.
> 
> Signed-off-by: Yong Bakos 
Reviewed-by: Bryce Harrington 

Thanks, pushed:
  bcc2863..452f1d9  master -> master

> ---
>  README | 54 +-
>  1 file changed, 53 insertions(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index c101150..b7eea61 100644
> --- a/README
> +++ b/README
> @@ -1 +1,53 @@
> -See http://wayland.freedesktop.org/building.html for documentation
> +Wayland Build Tools
> +
> +These are scripts that automate the standard Wayland build and installation
> +directions (http://wayland.freedesktop.org/building.html), and take care of
> +downloading and building the various upstream components needed for Wayland,
> +the Weston compositor, and Xwayland.
> +
> +These scripts and instructions are tested with a fresh installation of 
> Ubuntu,
> +and should work well for any Debian-based distro that uses APT.
> +
> +
> +Step 1: Install git, and clone the wayland-build-tools repository
> +
> +apt-get install -y git
> +git clone git://anongit.freedesktop.org/wayland/wayland-build-tools
> +
> +Where you place this repository is up to you.
> +
> +
> +Step 2: Prepare expected directories
> +
> +mkdir ~/Wayland # sources and builds will be here
> +mkdir -p ~/.config/wayland-build-tools
> +cp wl_defines.sh ~/.config/wayland-build-tools/
> +
> +You can change these directories if you wish, but these are the defaults
> +and you'll need to edit the scripts to match. See WL_ROOT and WLD in
> +wl_defines.sh.
> +
> +
> +Step 3: Install packaged build dependencies
> +
> +./wl_install_deps
> +
> +
> +Step 4: Clone the necessary repositories
> +
> +./wl_clone
> +
> +
> +Step 5: Build upstream dependencies, Wayland, and Weston
> +
> +./wl_build
> +
> +
> +Step 6: Run Weston
> +
> +source ~/.config/wayland-build-tools/wl_defines.sh
> +weston
> +
> +
> +Build scripts and configuration for other distros are welcome. For more
> +details, see https://blogs.s-osg.org/kick-waylands-tires-wayland-build-tools.
> -- 
> 2.7.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

[PATCH libinput] touchpad: add LIBINPUT_MODEL_WOBBLY_TOUCHPAD for the HP 14-ac157tu

[Peter Hutterer]

If some elantech touchpads require a hysteresis, let's use some more generic
tag for those touchpads that require correct handling of pointer wobbles.

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

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad.c| 3 +++
 src/evdev.c| 1 +
 src/evdev.h| 1 +
 udev/90-libinput-model-quirks.hwdb | 8 
 4 files changed, 13 insertions(+)

diff --git a/src/evdev-mt-touchpad.c b/src/evdev-mt-touchpad.c
index 0640974..a6eebd2 100644
--- a/src/evdev-mt-touchpad.c
+++ b/src/evdev-mt-touchpad.c
@@ -2023,6 +2023,9 @@ tp_init_hysteresis(struct tp_dispatch *tp)
(tp->device->model_flags & EVDEV_MODEL_SYNAPTICS_SERIAL_TOUCHPAD))
goto want_hysteresis;
 
+   if (tp->device->model_flags & EVDEV_MODEL_WOBBLY_TOUCHPAD)
+   goto want_hysteresis;
+
tp->hysteresis_margin.x = 0;
tp->hysteresis_margin.y = 0;
 
diff --git a/src/evdev.c b/src/evdev.c
index 6bb8986..f0311c6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -1681,6 +1681,7 @@ evdev_read_model_flags(struct evdev_device *device)
{ "LIBINPUT_MODEL_CYAPA", EVDEV_MODEL_CYAPA },
{ "LIBINPUT_MODEL_ALPS_RUSHMORE", EVDEV_MODEL_ALPS_RUSHMORE },
{ "LIBINPUT_MODEL_LENOVO_T450_TOUCHPAD", 
EVDEV_MODEL_LENOVO_T450_TOUCHPAD },
+   { "LIBINPUT_MODEL_WOBBLY_TOUCHPAD", EVDEV_MODEL_WOBBLY_TOUCHPAD 
},
{ NULL, EVDEV_MODEL_DEFAULT },
};
const struct model_map *m = model_map;
diff --git a/src/evdev.h b/src/evdev.h
index 4a5d807..3a7693e 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -114,6 +114,7 @@ enum evdev_device_model {
EVDEV_MODEL_CYAPA = (1 << 15),
EVDEV_MODEL_ALPS_RUSHMORE = (1 << 16),
EVDEV_MODEL_LENOVO_T450_TOUCHPAD= (1 << 17),
+   EVDEV_MODEL_WOBBLY_TOUCHPAD = (1 << 18),
 };
 
 struct mt_slot {
diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index d5978f7..d075417 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -81,6 +81,14 @@ libinput:name:Cypress APA Trackpad (cyapa):dmi:*
  LIBINPUT_MODEL_CYAPA=1
 
 ##
+# HP
+##
+
+# HP 14-ac157tu
+libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*svnHP*pvrCNB1:*
+ LIBINPUT_MODEL_WOBBLY_TOUCHPAD=1
+
+##
 # LENOVO
 ##
 
-- 
2.5.5

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

[PATCH wayland-build-tools] wl_install_deps: Add missing dependencies, remove INCLUDE_XWAYLAND logic

[Yong Bakos]

From: Yong Bakos 

Building on Ubuntu 15.10 x64 fails due to missing packages:
libtool, libxml2-dev, libpng-dev, libglib2.0-dev, libgudev-1.0-dev,
libgcrypt20-dev, x11proto-scrnsaver-dev, libxfont-dev, and libedit-dev.

In addition, building with INCLUDE_XWAYLAND=0 causes failures due to missing
package dependencies that would otherwise be installed when INCLUDE_XWAYLAND=1.
With only ~two packages not needing to be installed, it seems more simple to
remove this logic from wl_install_deps entirely.

After these changes, wl_build succeeds on Ubuntu 15.10 x64.

Signed-off-by: Yong Bakos 
---
 wl_install_deps | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/wl_install_deps b/wl_install_deps
index c400f6f..e9ba6ad 100755
--- a/wl_install_deps
+++ b/wl_install_deps
@@ -3,7 +3,7 @@
 . $HOME/.config/wayland-build-tools/wl_defines.sh
 
 # generic build dependencies for ubuntu
-sudo apt-get -y install autoconf automake bison debhelper dpkg-dev flex
+sudo apt-get -y install autoconf automake bison debhelper dpkg-dev flex libtool
 sudo apt-get -y install pkg-config quilt python-libxml2
 
 # wayland/weston specific stuff
@@ -19,23 +19,28 @@ sudo apt-get -y install libpciaccess-dev
 sudo apt-get -y install libudev-dev
 sudo apt-get -y install llvm-dev
 sudo apt-get -y install python-mako
+sudo apt-get -y install libxml2-dev
+sudo apt-get -y install libpng-dev
+sudo apt-get -y install libglib2.0-dev
+sudo apt-get -y install libgudev-1.0-dev
+sudo apt-get -y install libgcrypt20-dev
+sudo apt-get -y install x11proto-scrnsaver-dev
+sudo apt-get -y install libxfont-dev
+sudo apt-get -y install libedit-dev
 
-# xwayland specific stuff
-if [ ${INCLUDE_XWAYLAND} ]; then
-   sudo apt-get -y install libxcb-composite0-dev
-   sudo apt-get -y install x11proto-randr-dev
-   sudo apt-get -y install x11proto-composite-dev
-   sudo apt-get -y install x11proto-xinerama-dev
-   sudo apt-get -y install x11proto-dri2-dev
-   sudo apt-get -y install x11proto-gl-dev
-   sudo apt-get -y install xutils-dev
-   sudo apt-get -y install libxcursor-dev
-   #sudo apt-get -y install libdrm-dev
-   sudo apt-get -y install libx11-dev
-   sudo apt-get -y install libx11-xcb-dev
-   #sudo apt-get -y install x11proto-dri3-dev
-   sudo apt-get -y install libxdamage-dev
-   sudo apt-get -y install libxext-dev
-   sudo apt-get -y install libxfixes-dev
-   sudo apt-get -y install libxxf86vm-dev
-fi
+sudo apt-get -y install libxcb-composite0-dev
+sudo apt-get -y install x11proto-randr-dev
+sudo apt-get -y install x11proto-composite-dev
+sudo apt-get -y install x11proto-xinerama-dev
+sudo apt-get -y install x11proto-dri2-dev
+sudo apt-get -y install x11proto-gl-dev
+sudo apt-get -y install xutils-dev
+sudo apt-get -y install libxcursor-dev
+# sudo apt-get -y install libdrm-dev
+sudo apt-get -y install libx11-dev
+sudo apt-get -y install libx11-xcb-dev
+# sudo apt-get -y install x11proto-dri3-dev
+sudo apt-get -y install libxdamage-dev
+sudo apt-get -y install libxext-dev
+sudo apt-get -y install libxfixes-dev
+sudo apt-get -y install libxxf86vm-dev
-- 
2.7.2

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

[PATCH wayland-build-tools] readme: Add instructions

[Yong Bakos]

From: Yong Bakos 

The original readme just had a link to the official build instructions,
which does not help a user with these build tools.

Signed-off-by: Yong Bakos 
---
 README | 54 +-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/README b/README
index c101150..b7eea61 100644
--- a/README
+++ b/README
@@ -1 +1,53 @@
-See http://wayland.freedesktop.org/building.html for documentation
+Wayland Build Tools
+
+These are scripts that automate the standard Wayland build and installation
+directions (http://wayland.freedesktop.org/building.html), and take care of
+downloading and building the various upstream components needed for Wayland,
+the Weston compositor, and Xwayland.
+
+These scripts and instructions are tested with a fresh installation of Ubuntu,
+and should work well for any Debian-based distro that uses APT.
+
+
+Step 1: Install git, and clone the wayland-build-tools repository
+
+apt-get install -y git
+git clone git://anongit.freedesktop.org/wayland/wayland-build-tools
+
+Where you place this repository is up to you.
+
+
+Step 2: Prepare expected directories
+
+mkdir ~/Wayland # sources and builds will be here
+mkdir -p ~/.config/wayland-build-tools
+cp wl_defines.sh ~/.config/wayland-build-tools/
+
+You can change these directories if you wish, but these are the defaults
+and you'll need to edit the scripts to match. See WL_ROOT and WLD in
+wl_defines.sh.
+
+
+Step 3: Install packaged build dependencies
+
+./wl_install_deps
+
+
+Step 4: Clone the necessary repositories
+
+./wl_clone
+
+
+Step 5: Build upstream dependencies, Wayland, and Weston
+
+./wl_build
+
+
+Step 6: Run Weston
+
+source ~/.config/wayland-build-tools/wl_defines.sh
+weston
+
+
+Build scripts and configuration for other distros are welcome. For more
+details, see https://blogs.s-osg.org/kick-waylands-tires-wayland-build-tools.
-- 
2.7.2

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

Re: [PATCH wayland-protocols 1/4] stable/presentation-time: swap two paragraphs in 'presented'

[Bryce Harrington]

On Wed, Apr 13, 2016 at 11:11:54AM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> Associates better with the surrounding paragraphs by not jumping topics
> back and forth.
> 
> Suggested-by: Bill Spitzak 
> Signed-off-by: Pekka Paalanen 

For all four patches:
Reviewed-by: Bryce Harrington 

> ---
>  stable/presentation-time/presentation-time.xml | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/stable/presentation-time/presentation-time.xml 
> b/stable/presentation-time/presentation-time.xml
> index dc4ae68..6c3fff8 100644
> --- a/stable/presentation-time/presentation-time.xml
> +++ b/stable/presentation-time/presentation-time.xml
> @@ -232,6 +232,10 @@
>  targeting the next few vblanks. If such prediction cannot
>  usefully be done, the argument is zero.
>  
> +If the output does not have a constant refresh rate, explicit
> +video mode switches excluded, then the refresh argument must
> +be zero.
> +
>  The 64-bit value combined from seq_hi and seq_lo is the value
>  of the output's vertical retrace counter when the content
>  update was first scanned out to the display. This value must
> @@ -240,10 +244,6 @@
>  path has a non-zero latency, the time instant specified by
>  this counter may differ from the timestamp's.
>  
> -If the output does not have a constant refresh rate, explicit
> -video mode switches excluded, then the refresh argument must
> -be zero.
> -
>  If the output does not have a concept of vertical retrace or a
>  refresh cycle, or the output device is self-refreshing without
>  a way to query the refresh count, then the arguments seq_hi
> -- 
> 2.7.3
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 00/19] Correct writing errors

[Yong Bakos]

On Apr 13, 2016, at 2:54 PM, Bryce Harrington  wrote:
> 
> On Mon, Apr 11, 2016 at 05:22:47PM -0500, Yong Bakos wrote:
>> From: Yong Bakos 
>> 
>> This v1 patchset consists of spelling, grammar and minor formatting
>> changes to all protocol xml files. The approach here is to be
>> minimally invasive and to not impart stylistic changes; only corrections
>> and consistency changes have been made, with the motivation of accuracy and
>> clarity of documentation.
>> 
>> Note: Only #16 affects a protocol (fullscreen-shell) directly, by correcting
>>  a parameter name.
>> 
>> Any changes on the grounds of 'consistency' were made to reflect either:
>> 
>> a) the majority of the content in the specific xml doc itself
>> b) the current convention followed by protocol writers, including
>>   wayland.xml
>> 
>> In other words, I hope you will find them non-opinionated. Apologies for
>> the rather verbose patchset, but this should allow easier decision making
>> and hopefully merging. Thanks for reviewing!
>> 
>> yong
>> 
>> 
>> 
>> Yong Bakos (19):
>>  readme: Correct spelling and grammar
>>  presentation-time: Correct minor grammar errors
>>  xdg-shell: Downcase summary values consistently
>>  xdg-shell: Remove inconsistent spacing
>>  xdg-shell: Adjust articles and correct grammar
>>  text-input: Fix indentation and paragraph whitespace
>>  text-input: Rename text-input to text_input
>>  text-input: Correct grammar
>>  tablet: Adjust vertical whitespace for consistency
>>  tablet: Correct grammar and punctuation
>>  relative-pointer: Correct spelling error, one capitalization, and
>>minor space
>>  pointer-gestures: Correct pluralization, one space, minor vertical
>>whitespace
>>  pointer-constraints: Correct spelling, grammar and consistency
>>  linux-dmabuf: Add missing articles and punctuation, adjust minor
>>whitespace
>>  input-method: Correct grammar, add missing line break
>>  fullscreen-shell: Correct spelling of parameter name
>>  fullscreen-shell: Correct grammar, punctuation, minor naming and space
>>  pointer-gestures: Add missing xml declaration
>>  fullscreen-shell: Add missing xml declaration
> 
> Hi Yong,
> 
> Patches 1-2, 9-15, and 17-19 all R-b'd by me.  All are obviously correct
> copyediting to documentation, and I'll land them directly.

Thank you!


> Since patch #16 affects protocol I've opted to omit it from speedy
> landing.  But the spelling fix is correct so +1 from me.

I cc'd Jason E so hopefully he'll chime in.


> The xdg-shell and text-input patches I've left out just because there
> are new versions for each of those protocols in the works, and I'm
> hesistant on introducing a delta that could potentially cause problems.
> 
> For xdg-shell, its v6 is being developed in a branch:
> 
>  https://cgit.freedesktop.org/wayland/wayland-protocols/

Crap, I totally overlooked that branch and was working from master/HEAD.
I'll review again after Olivier's v6 patch is merged.


> For text-input, it doesn't have a branch, but the most recent rev of its
> v2 update is:
> 
>  https://patchwork.freedesktop.org/patch/79435/
> 
> As I understand it, new major versions of protocols will be
> co-installable, so presumably copyedits to the earlier versions of the
> protocols won't cause merge conflicts or anything, so maybe these are
> safe to land?  However, maybe there might be some benefit during the
> final stages of development if diffs between the two protocols aren't
> cluttered up with copyedits?  In any case, it probably makes sense to
> copyedit the new versions of the protocols so we don't inadvertantly
> regress the fixes when moving to the new versions.
> 
> So, first make sure to give review on text-input-v2 and xdg-shell-v6.
> Second, I guess we should decide if copyedits to the older versions of
> the protocols are worth doing, and if so should they be landed
> separately from the new protocols or be included with them?

I see what you're saying and thought about timing as well. My conclusion
was, "well, they're still unstable so ad hoc should be ok," but I do
understand your point.

yong


> 
> 
>> README | 14 ++--
>> stable/presentation-time/presentation-time.xml |  6 +-
>> .../fullscreen-shell-unstable-v1.xml   | 19 +++--
>> unstable/input-method/input-method-unstable-v1.xml | 40 ++-
>> unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 +++--
>> .../pointer-constraints-unstable-v1.xml| 16 ++---
>> .../pointer-gestures-unstable-v1.xml   |  9 ++-
>> .../relative-pointer-unstable-v1.xml   |  8 +--
>> unstable/tablet/tablet-unstable-v1.xml | 28 
>> unstable/text-input/text-input-unstable-v1.xml | 82 
>> +++---
>> unstable/xdg-shell/xdg-shell-unstable-v5.xml   | 30 
>> 11 files changed, 142 insertions(+), 128 deletions(-)
>> 
>> --
>> 2.7.2
>> 
>> 

Re: [PATCH wayland-protocols 00/19] Correct writing errors

[Bryce Harrington]

On Mon, Apr 11, 2016 at 05:22:47PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> This v1 patchset consists of spelling, grammar and minor formatting
> changes to all protocol xml files. The approach here is to be
> minimally invasive and to not impart stylistic changes; only corrections
> and consistency changes have been made, with the motivation of accuracy and
> clarity of documentation.
> 
> Note: Only #16 affects a protocol (fullscreen-shell) directly, by correcting
>   a parameter name.
> 
> Any changes on the grounds of 'consistency' were made to reflect either:
> 
> a) the majority of the content in the specific xml doc itself
> b) the current convention followed by protocol writers, including
>wayland.xml
> 
> In other words, I hope you will find them non-opinionated. Apologies for
> the rather verbose patchset, but this should allow easier decision making
> and hopefully merging. Thanks for reviewing!
> 
> yong
> 
> 
> 
> Yong Bakos (19):
>   readme: Correct spelling and grammar
>   presentation-time: Correct minor grammar errors
>   xdg-shell: Downcase summary values consistently
>   xdg-shell: Remove inconsistent spacing
>   xdg-shell: Adjust articles and correct grammar
>   text-input: Fix indentation and paragraph whitespace
>   text-input: Rename text-input to text_input
>   text-input: Correct grammar
>   tablet: Adjust vertical whitespace for consistency
>   tablet: Correct grammar and punctuation
>   relative-pointer: Correct spelling error, one capitalization, and
> minor space
>   pointer-gestures: Correct pluralization, one space, minor vertical
> whitespace
>   pointer-constraints: Correct spelling, grammar and consistency
>   linux-dmabuf: Add missing articles and punctuation, adjust minor
> whitespace
>   input-method: Correct grammar, add missing line break
>   fullscreen-shell: Correct spelling of parameter name
>   fullscreen-shell: Correct grammar, punctuation, minor naming and space
>   pointer-gestures: Add missing xml declaration
>   fullscreen-shell: Add missing xml declaration

Hi Yong,

Patches 1-2, 9-15, and 17-19 all R-b'd by me.  All are obviously correct
copyediting to documentation, and I'll land them directly.

Since patch #16 affects protocol I've opted to omit it from speedy
landing.  But the spelling fix is correct so +1 from me.

The xdg-shell and text-input patches I've left out just because there
are new versions for each of those protocols in the works, and I'm
hesistant on introducing a delta that could potentially cause problems.

For xdg-shell, its v6 is being developed in a branch:

  https://cgit.freedesktop.org/wayland/wayland-protocols/

For text-input, it doesn't have a branch, but the most recent rev of its
v2 update is:

  https://patchwork.freedesktop.org/patch/79435/

As I understand it, new major versions of protocols will be
co-installable, so presumably copyedits to the earlier versions of the
protocols won't cause merge conflicts or anything, so maybe these are
safe to land?  However, maybe there might be some benefit during the
final stages of development if diffs between the two protocols aren't
cluttered up with copyedits?  In any case, it probably makes sense to
copyedit the new versions of the protocols so we don't inadvertantly
regress the fixes when moving to the new versions.

So, first make sure to give review on text-input-v2 and xdg-shell-v6.
Second, I guess we should decide if copyedits to the older versions of
the protocols are worth doing, and if so should they be landed
separately from the new protocols or be included with them?


>  README | 14 ++--
>  stable/presentation-time/presentation-time.xml |  6 +-
>  .../fullscreen-shell-unstable-v1.xml   | 19 +++--
>  unstable/input-method/input-method-unstable-v1.xml | 40 ++-
>  unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml | 18 +++--
>  .../pointer-constraints-unstable-v1.xml| 16 ++---
>  .../pointer-gestures-unstable-v1.xml   |  9 ++-
>  .../relative-pointer-unstable-v1.xml   |  8 +--
>  unstable/tablet/tablet-unstable-v1.xml | 28 
>  unstable/text-input/text-input-unstable-v1.xml | 82 
> +++---
>  unstable/xdg-shell/xdg-shell-unstable-v5.xml   | 30 
>  11 files changed, 142 insertions(+), 128 deletions(-)
> 
> --
> 2.7.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 v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz 

On Wed, Apr 13, 2016 at 2:18 PM Olivier Fourdan  wrote:

> Just a quick note, not that it matters much, but this should have been v7,
> not v6, I got confused with the numbering of iterations :)
>
> Cheers,
> Olivier
>
> - Original Message -
> > Some application may wish to restrict their window in size, but
> > xdg-shell has no mechanism for the client to specify a maximum or
> > minimum size.
> >
> > As a result, the compositor may try to maximize or fullscreen a window
> > while the client would not allow for the requested size.
> >
> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> > the client can tell the compositor what would be its smallest/largest
> > acceptable size, and that the compositor can decide if maximize or
> > fullscreen is achievable, draw an accurate animation, etc.
> >
> > Signed-off-by: Olivier Fourdan 
> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> > ---
> >  v2: Rename the request to "set_preferred_max_size",
> >  add "set_preferred_min_size" as well
> >  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> >  Rephrase description to clarify the unscaled size and using 0 to
> >  reset back the preferred size to an unspecified state
> >  v4: Patch the correct xml file (v6, not v5 )
> >  Fix multiple mismatch of min/max in the description
> >  Remove mention of "unscaled", specify window geometry coordinates
> >  and refer to set_window_geometry.
> >  v5: Fix typos and remove "preferred" from the name and description as
> >  requested by several people on the ML and irc.
> >  v6: Specify the requests are double-buffered and require a commit,
> >  rephrase the values never set as suggested by Jasper, state
> >  that min > max is an invalid state and result in a protocol error
> >  as suggested by Bill, Yong and Jonas.
> >  Specify that width/height values must be greater than or equal to
> >  zero as discussed with Mike.
> >
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74
> >  
> >  1 file changed, 74 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 3fc7d42..eba31ce 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -489,6 +489,80 @@
> >
> >  
> >
> > +
> > +  
> > + Set a maximum size for the window.
> > +
> > + The client can specify a maximum size so that the compositor does
> > + not try to configure the window beyond this size.
> > +
> > + The width and height arguments are in window geometry coordinates.
> > + See set_window_geometry.
> > +
> > + Values set in this way are double-buffered. They will get applied
> > + on the next commit.
> > +
> > + The compositor can use this information to allow or disallow
> > + different states like maximize or fullscreen and draw accurate
> > + animations.
> > +
> > + Similarly, a tiling window manager may use this information to
> > + place and resize client windows in a more effective way.
> > +
> > + If never set, or a value of zero in the request, means that the
> > + client has no expected maximum size in the given dimension.
> > + As a result, a client wishing to reset the maximum size
> > + to an unspecified state can use zero for width and height in the
> > + request.
> > +
> > + Requesting a maximum size to be smaller than the minimum size of
> > + a surface is illegal and will result in a protocol error.
> > +
> > + The width and height must be greater than or equal to zero. Using
> > + strictly negative values for width and height will result in a
> > + protocol error.
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > + Set a minimum size for the window.
> > +
> > + The client can specify a minimum size so that the compositor does
> > + not try to configure the window below this size.
> > +
> > + The width and height arguments are in window geometry coordinates.
> > + See set_window_geometry.
> > +
> > + Values set in this way are double-buffered. They will get applied
> > + on the next commit.
> > +
> > + The compositor can use this information to allow or disallow
> > + different states like maximize or fullscreen and draw accurate
> > + animations.
> > +
> > + Similarly, a tiling window manager may use this information to
> > + place and resize client windows in a more effective way.
> > +
> > + If never set, or a value of zero in the request, means that the
> > + client has no expected minimum size in the given dimension.
> > + As a result, a client wishing to reset the minimum size
> > + to an unspecified state can use zero 

Re: [PATCH 4/5] compositor: Version the backend configuration structures

[Bryce Harrington]

On Wed, Apr 13, 2016 at 02:47:06PM +0300, Pekka Paalanen wrote:
> On Tue, 12 Apr 2016 21:44:10 -0700
> Bryce Harrington  wrote:
> 
> > On Wed, Apr 06, 2016 at 11:43:54AM +0300, Pekka Paalanen wrote:
> > > On Mon, 21 Mar 2016 23:11:29 +0100
> > > Benoit Gschwind  wrote:
> > >   
> > > > Hello,
> > > > 
> > > > I think that struct_version and struct_size should not be belong
> > > > compositor.h. I think those versioning should be back-end detail, and
> > > > each back-end should provide a major version number through #define in
> > > > the backend header.  
> > > 
> > > Hi!
> > > 
> > > No, the struct fields do belong in compositor.h. These fields are
> > > common to all backend-specific structs, and must be handled the same
> > > everywhere, so they make perfect sense in compositor.h, in the
> > > definition of struct weston_backend_config.
> > > 
> > > However, you are right in that backends must define the struct_version
> > > values in a backend-specific header. That #define can (only) be used for
> > > build time compatibility checks in #if directives in main.c.  
> > 
> > Agreed.  How should this #define be named?
> 
> Hi,
> 
> umm... WESTON_DRM_BACKEND_CONFIG_VERSION?

But we have a major/minor version.  WESTON_DRM_BACKEND_CONFIG_MAJOR_VERSION?
Or is that too long?

> > > > Reviewed-by: Benoit Gschwind 
> > > > 
> > > > Le 10/03/2016 01:49, Bryce Harrington a écrit :  
> > > > > With this struct versioning, it is possible to add new options without
> > > > > breaking the ABI, as long as all additions are made to the end of a
> > > > > struct and nothing existing is modified or removed.  When things are
> > > > > added, the structure's size will increase, and we'll use this size as
> > > > > our minor version number.  If existing things need to be changed, then
> > > > > the major version, struct_version, is incremented to indicate the ABI
> > > > > break.
> > > > > 
> > > > > From our call site in main we record these major and minor version as
> > > > > struct_version and struct_size.  The backend then verifies these 
> > > > > against
> > > > > its own assumptions.  So long as the backend's struct is equal or 
> > > > > larger
> > > > > than what was passed in and the major versions are equal, we're good;
> > > > > but if it is larger, then this is a fatal error.
> > > > > 
> > > > > Signed-off-by: Bryce Harrington 
> > > > > ---
> > > > >  src/compositor-drm.c | 10 --
> > > > >  src/compositor.h | 16 
> > > > >  src/main.c   |  2 ++
> > > > >  3 files changed, 26 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > > > > index 5ddedb9..9bce285 100644
> > > > > --- a/src/compositor-drm.c
> > > > > +++ b/src/compositor-drm.c
> > > > > @@ -3203,8 +3203,14 @@ backend_init(struct weston_compositor 
> > > > > *compositor, int *argc, char *argv[],
> > > > >   struct weston_backend_config *config_base)
> > > > >  {
> > > > >   struct drm_backend *b;
> > > > > - struct weston_drm_backend_config *config =
> > > > > - (struct weston_drm_backend_config 
> > > > > *)config_base;
> > > > > + struct weston_drm_backend_config *config;
> > > > > +
> > > > > + if (config_base == NULL ||
> > > > > + config_base->struct_version != 1 ||
> > > > > + config_base->struct_size > sizeof(struct 
> > > > > weston_drm_backend_config))
> > > > > + return -1;
> > > > > +
> > > > > + config = (struct weston_drm_backend_config *)config_base;  
> > > 
> > > Like Quentin has suggested in IRC, this should be done as follows:  
> > 
> > Is there a log of that discussion?
> 
> Umh, it happened a while ago. Not really much else to say than it's a
> nice trick to augment an incoming struct into a version used internally
> in a library. That's the reason to pick sizeof() instead of an arbitrary
> minor_version.
> 
> > > - allocate a private struct weston_drm_backend_config
> > > - init the private config with all defaults
> > > - copy the first struct_size bytes from the passed-in config to the
> > >   private config
> > > 
> > > This allows the backend to add more fields to the end with default
> > > values, and maintain compatiblity with the older main.c.  
> > 
> > So like in place of the cast line, do you mean something like:
> > 
> > config = zalloc(sizeof weston_drm_backend_config);
> > if (config == NULL)
> >return -1;
> 
> Add init_to_defaults(config); here.
> 
> > memcpy(config, config_base, config_base->struct_size);
> > 
> > ?
> 
> Then memcpy only overwrites the passed in data and leaves the rest as
> defaults.
> 
> This is the generic way. There might be shortcuts to be made if
> everything is already copied into yet other variables anyway.
> 
> > > The reason is that sizeof(struct weston_drm_backend_config) is
> > > 

Re: [PATCH weston v5 09/11] drm: Don't hang onto the backend config object post-backend_init

[Bryce Harrington]

On Wed, Apr 13, 2016 at 04:54:04PM +0300, Pekka Paalanen wrote:
> On Wed, 13 Apr 2016 03:25:13 -0700
> Bryce Harrington  wrote:
> 
> > The drm backend was copying most everything out of the config object
> > already, but now also copy the use_current_mode parameter and the
> > config_output function pointer, so that there are no remaining
> > references to the config object passed into backend_init().
> > 
> > By decoupling the config struct to the backend, if in the future if the
> > structure definition changes in non-backwards compatible ways, then any
> > version compatibility adaptation will be limited to just the
> > backend_init() routine.
> > 
> > Signed-off-by: Bryce Harrington 
> > ---
> >  src/compositor-drm.c | 24 +++-
> >  src/compositor-drm.h |  3 ++-
> >  src/main.c   | 18 --
> >  3 files changed, 25 insertions(+), 20 deletions(-)
> > 
> > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > index 38296e2..722cc6a 100644
> > --- a/src/compositor-drm.c
> > +++ b/src/compositor-drm.c
> > @@ -121,7 +121,17 @@ struct drm_backend {
> > int32_t cursor_width;
> > int32_t cursor_height;
> >  
> > -   struct weston_drm_backend_config *config;
> > +/** Callback used to configure the outputs.
> > +*
> > + * This function will be called by the backend when a new DRM
> > + * output needs to be configured.
> > + */
> > +enum weston_drm_backend_output_mode
> 
> Some whitespace damage here?
> 
> > +   (*configure_output)(struct weston_compositor *compositor,
> > +   bool use_current_mode,
> > +   const char *name,
> > +   struct weston_drm_backend_output_config 
> > *output_config);
> > +   bool use_current_mode;
> >  };
> >  
> >  struct drm_mode {
> > @@ -2311,8 +2321,8 @@ create_output_for_connector(struct drm_backend *b,
> > output->base.serial_number = "unknown";
> > wl_list_init(>base.mode_list);
> >  
> > -   mode = b->config->configure_output(b->compositor, b->config,
> > -  output->base.name, );
> > +   mode = b->configure_output(b->compositor, b->use_current_mode,
> > +  output->base.name, );
> > if (parse_gbm_format(config.gbm_format, b->gbm_format, 
> > >gbm_format) == -1)
> > output->gbm_format = b->gbm_format;
> >  
> > @@ -2699,11 +2709,6 @@ drm_destroy(struct weston_compositor *ec)
> > weston_launcher_destroy(ec->launcher);
> >  
> > close(b->drm.fd);
> > -
> > -   free(b->config->gbm_format);
> > -   free(b->config->seat_id);
> > -   free(b->config);
> > -
> > free(b);
> >  }
> >  
> > @@ -3054,7 +3059,8 @@ drm_backend_create(struct weston_compositor 
> > *compositor,
> > b->sprites_are_broken = 1;
> > b->compositor = compositor;
> > b->use_pixman = config->use_pixman;
> > -   b->config = config;
> > +   b->configure_output = config->configure_output;
> > +   b->use_current_mode = config->use_current_mode;
> >  
> > if (parse_gbm_format(config->gbm_format, GBM_FORMAT_XRGB, 
> > >gbm_format) < 0)
> > goto err_compositor;
> > diff --git a/src/compositor-drm.h b/src/compositor-drm.h
> > index 3b54ca5..7e0913a 100644
> > --- a/src/compositor-drm.h
> > +++ b/src/compositor-drm.h
> > @@ -112,9 +112,10 @@ struct weston_drm_backend_config {
> >  */
> > enum weston_drm_backend_output_mode
> > (*configure_output)(struct weston_compositor *compositor,
> > -   struct weston_drm_backend_config 
> > *backend_config,
> > +   bool use_current_mode,
> > const char *name,
> > struct weston_drm_backend_output_config 
> > *output_config);
> > +   bool use_current_mode;
> >  };
> >  
> >  #ifdef  __cplusplus
> > diff --git a/src/main.c b/src/main.c
> > index f652701..c499fd0 100644
> > --- a/src/main.c
> > +++ b/src/main.c
> > @@ -683,11 +683,10 @@ struct drm_config {
> >  
> >  static enum weston_drm_backend_output_mode
> >  drm_configure_output(struct weston_compositor *c,
> > -struct weston_drm_backend_config *backend_config,
> > +bool use_current_mode,
> >  const char *name,
> >  struct weston_drm_backend_output_config *config)
> >  {
> > -   struct drm_config *drm_config = (struct drm_config *)backend_config;
> > struct weston_config *wc = weston_compositor_get_user_data(c);
> > struct weston_config_section *section;
> > char *s;
> > @@ -702,7 +701,7 @@ drm_configure_output(struct weston_compositor *c,
> > return WESTON_DRM_BACKEND_OUTPUT_OFF;
> > }
> >  
> > -   if (drm_config->use_current_mode || strcmp(s, "current") == 0) {
> > +   if (use_current_mode || strcmp(s, "current") == 0) {
> > mode = 

Re: [PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Just a quick note, not that it matters much, but this should have been v7, not 
v6, I got confused with the numbering of iterations :)

Cheers,
Olivier

- Original Message -
> Some application may wish to restrict their window in size, but
> xdg-shell has no mechanism for the client to specify a maximum or
> minimum size.
> 
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
> 
> Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> the client can tell the compositor what would be its smallest/largest
> acceptable size, and that the compositor can decide if maximize or
> fullscreen is achievable, draw an accurate animation, etc.
> 
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  v2: Rename the request to "set_preferred_max_size",
>  add "set_preferred_min_size" as well
>  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
>  Rephrase description to clarify the unscaled size and using 0 to
>  reset back the preferred size to an unspecified state
>  v4: Patch the correct xml file (v6, not v5 )
>  Fix multiple mismatch of min/max in the description
>  Remove mention of "unscaled", specify window geometry coordinates
>  and refer to set_window_geometry.
>  v5: Fix typos and remove "preferred" from the name and description as
>  requested by several people on the ML and irc.
>  v6: Specify the requests are double-buffered and require a commit,
>  rephrase the values never set as suggested by Jasper, state
>  that min > max is an invalid state and result in a protocol error
>  as suggested by Bill, Yong and Jonas.
>  Specify that width/height values must be greater than or equal to
>  zero as discussed with Mike.
> 
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74
>  
>  1 file changed, 74 insertions(+)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 3fc7d42..eba31ce 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -489,6 +489,80 @@
>
>  
>  
> +
> +  
> + Set a maximum size for the window.
> +
> + The client can specify a maximum size so that the compositor does
> + not try to configure the window beyond this size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + Values set in this way are double-buffered. They will get applied
> + on the next commit.
> +
> + The compositor can use this information to allow or disallow
> + different states like maximize or fullscreen and draw accurate
> + animations.
> +
> + Similarly, a tiling window manager may use this information to
> + place and resize client windows in a more effective way.
> +
> + If never set, or a value of zero in the request, means that the
> + client has no expected maximum size in the given dimension.
> + As a result, a client wishing to reset the maximum size
> + to an unspecified state can use zero for width and height in the
> + request.
> +
> + Requesting a maximum size to be smaller than the minimum size of
> + a surface is illegal and will result in a protocol error.
> +
> + The width and height must be greater than or equal to zero. Using
> + strictly negative values for width and height will result in a
> + protocol error.
> +  
> +  
> +  
> +
> +
> +
> +  
> + Set a minimum size for the window.
> +
> + The client can specify a minimum size so that the compositor does
> + not try to configure the window below this size.
> +
> + The width and height arguments are in window geometry coordinates.
> + See set_window_geometry.
> +
> + Values set in this way are double-buffered. They will get applied
> + on the next commit.
> +
> + The compositor can use this information to allow or disallow
> + different states like maximize or fullscreen and draw accurate
> + animations.
> +
> + Similarly, a tiling window manager may use this information to
> + place and resize client windows in a more effective way.
> +
> + If never set, or a value of zero in the request, means that the
> + client has no expected minimum size in the given dimension.
> + As a result, a client wishing to reset the minimum size
> + to an unspecified state can use zero for width and height in the
> + request.
> +
> + Requesting a minimum size to be larger than the maximum size of
> + a surface is illegal and will result in a protocol error.
> +
> + The width and height must be greater than or equal to zero. Using
> + strictly negative values for width and height will result in a
> + protocol 

[PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Some application may wish to restrict their window in size, but
xdg-shell has no mechanism for the client to specify a maximum or
minimum size.

As a result, the compositor may try to maximize or fullscreen a window
while the client would not allow for the requested size.

Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
the client can tell the compositor what would be its smallest/largest
acceptable size, and that the compositor can decide if maximize or
fullscreen is achievable, draw an accurate animation, etc.

Signed-off-by: Olivier Fourdan 
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
---
 v2: Rename the request to "set_preferred_max_size",
 add "set_preferred_min_size" as well
 v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
 Rephrase description to clarify the unscaled size and using 0 to
 reset back the preferred size to an unspecified state
 v4: Patch the correct xml file (v6, not v5 )
 Fix multiple mismatch of min/max in the description
 Remove mention of "unscaled", specify window geometry coordinates
 and refer to set_window_geometry.
 v5: Fix typos and remove "preferred" from the name and description as
 requested by several people on the ML and irc.
 v6: Specify the requests are double-buffered and require a commit,
 rephrase the values never set as suggested by Jasper, state
 that min > max is an invalid state and result in a protocol error
 as suggested by Bill, Yong and Jonas.
 Specify that width/height values must be greater than or equal to
 zero as discussed with Mike.

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74 
 1 file changed, 74 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 3fc7d42..eba31ce 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -489,6 +489,80 @@
   
 
 
+
+  
+   Set a maximum size for the window.
+
+   The client can specify a maximum size so that the compositor does
+   not try to configure the window beyond this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   Values set in this way are double-buffered. They will get applied
+   on the next commit.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, or a value of zero in the request, means that the
+   client has no expected maximum size in the given dimension.
+   As a result, a client wishing to reset the maximum size
+   to an unspecified state can use zero for width and height in the
+   request.
+
+   Requesting a maximum size to be smaller than the minimum size of
+   a surface is illegal and will result in a protocol error.
+
+   The width and height must be greater than or equal to zero. Using
+   strictly negative values for width and height will result in a
+   protocol error.
+  
+  
+  
+
+
+
+  
+   Set a minimum size for the window.
+
+   The client can specify a minimum size so that the compositor does
+   not try to configure the window below this size.
+
+   The width and height arguments are in window geometry coordinates.
+   See set_window_geometry.
+
+   Values set in this way are double-buffered. They will get applied
+   on the next commit.
+
+   The compositor can use this information to allow or disallow
+   different states like maximize or fullscreen and draw accurate
+   animations.
+
+   Similarly, a tiling window manager may use this information to
+   place and resize client windows in a more effective way.
+
+   If never set, or a value of zero in the request, means that the
+   client has no expected minimum size in the given dimension.
+   As a result, a client wishing to reset the minimum size
+   to an unspecified state can use zero for width and height in the
+   request.
+
+   Requesting a minimum size to be larger than the maximum size of
+   a surface is illegal and will result in a protocol error.
+
+   The width and height must be greater than or equal to zero. Using
+   strictly negative values for width and height will result in a
+   protocol error.
+  
+  
+  
+
+
 
   
Maximize the surface.
-- 
2.5.5

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

Re: [PATCH weston v2] Makefile: Fix compilation error when git commit message has quotes

[Pekka Paalanen]

On Thu, 7 Apr 2016 10:56:23 -0700
Bryce Harrington  wrote:

> On Thu, Apr 07, 2016 at 04:53:31PM +, Chokshi, Mitul wrote:
> > 
> > A double-quote in log message prematurely ends the enquoted string
> > in src/git-version.h, causing an error during compilation.
> > Used stream editor to replace " with \"
> > 
> > Signed-off-by: Mitul Chokshi 
> > ---
> >  Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Makefile.am b/Makefile.am
> > index d1644ac..a09ea0b 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -162,7 +162,7 @@ endif
> >  
> >  if HAVE_GIT_REPO
> >  src/git-version.h : $(top_srcdir)/.git/logs/HEAD
> > -   $(AM_V_GEN)echo "#define BUILD_ID \"$(shell git 
> > --git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git 
> > --git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)')\"" > $@
> > +   $(AM_V_GEN)echo "#define BUILD_ID \"$(shell git 
> > --git-dir=$(top_srcdir)/.git describe --always --dirty) $(shell git 
> > --git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)' | $(SED) 
> > 's|\"|\\\"|g' )\"" > $@
> >  else
> >  src/git-version.h :
> > $(AM_V_GEN)echo "#define BUILD_ID \"unknown (not built from git or 
> > tarball)\"" > $@  
> 
> Confirmed:
> 
> $ echo "foo" >> README
> $ git commit README -m "testing \""
> 
> $ make
> make  all-am
> make[1]: Entering directory `/home/bryce/src/Wayland/weston'
> /bin/bash: -c: line 0: syntax error near unexpected token `('
> /bin/bash: -c: line 0: `echo "  GEN " src/git-version.h;echo "#define 
> BUILD_ID \"1.9.0-168-gb1f52e1 testing " (2016-04-07 10:53:15 -0700)\"" > 
> src/git-version.h'
> make[1]: *** [src/git-version.h] Error 1
> make[1]: Leaving directory `/home/bryce/src/Wayland/weston'
> make: *** [all] Error 2
> 
> With the patch applied, the make passes properly.
> 
> Tested-by: Bryce Harrington 

Hi,

hmm, it doesn't work for me. I did the same test, having the subject
line 'testing "', and I get:

$ make
make  all-am
make[1]: Entering directory '/home/pq/build/weston'
  GEN  src/git-version.h
  CC   src/weston-compositor.o
In file included from /home/pq/git/weston/src/compositor.c:62:0:
./src/git-version.h:1:81: warning: missing terminating " character [enabled by 
default]
 #define BUILD_ID "1.10.0-90-g610e0a7-dirty testing " (2016-04-13 17:32:41 
+0300)"

 ^
  CC   src/weston-main.o
In file included from /home/pq/git/weston/src/main.c:47:0:
./src/git-version.h:1:81: warning: missing terminating " character [enabled by 
default]
 #define BUILD_ID "1.10.0-90-g610e0a7-dirty testing " (2016-04-13 17:32:41 
+0300)"

 ^
/home/pq/git/weston/src/main.c: In function ‘main’:
./src/git-version.h:1:66: error: expected ‘)’ before numeric constant
 #define BUILD_ID "1.10.0-90-g610e0a7-dirty testing " (2016-04-13 17:32:41 
+0300)"
  ^
/home/pq/git/weston/src/main.c:737:6: note: in expansion of macro ‘BUILD_ID’
  BUILD_ID);
  ^
./src/git-version.h:1:54: error: called object is not a function or function 
pointer
 #define BUILD_ID "1.10.0-90-g610e0a7-dirty testing " (2016-04-13 17:32:41 
+0300)"
  ^
/home/pq/git/weston/src/main.c:737:6: note: in expansion of macro ‘BUILD_ID’
  BUILD_ID);
  ^
./src/git-version.h:1:66: error: missing terminating " character
 #define BUILD_ID "1.10.0-90-g610e0a7-dirty testing " (2016-04-13 17:32:41 
+0300)"
  ^
/home/pq/git/weston/src/main.c:737:6: note: in expansion of macro ‘BUILD_ID’
  BUILD_ID);
  ^
Makefile:5398: recipe for target 'src/weston-main.o' failed
make[1]: *** [src/weston-main.o] Error 1
make[1]: Leaving directory '/home/pq/build/weston'
Makefile:2982: recipe for target 'all' failed
make: *** [all] Error 2


So even if the Makefile command invocation was fixed, the C
preprocessor token is still broken. Touching just README probably did
not cause any .c files to be rebuilt.

Maybe the git strings should not go as arguments to 'echo', so we avoid
one level of quoting. So something like this in bash:

( echo -n '#define BUILD_ID "' &&
  ( git --git-dir=$(top_srcdir)/.git describe --always --dirty &&
git --git-dir=$(top_srcdir)/.git log -1 --format='%s (%ci)' ) | sed ... &&
  echo '"' ) > $@

An excercise for the reader is to figure out if there are any bashisms
in that, how to write it in Makefile.am, and what the sed script needs
to be. And perhaps make sure to remove stray newlines from the string.


Thanks,
pq


pgpNeAyrENop5.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: [PATCH weston v5 00/11] drm: port the drm backend to the new init api

[Pekka Paalanen]

On Wed, 13 Apr 2016 03:25:04 -0700
Bryce Harrington  wrote:

> In following up on my earlier update of Giulio's drm backend config
> patch, I've taken the liberty to try and also integrate a couple of
> Benoit's other backend configuration patches into this patchset.
> 
> Giulio and Benoit took different approaches in their implementations.
> I've attempted to reconcile them so that they are stylistically
> consistent, along with incorporating pq's request to have the root
> config structure incorporate versioning information.  I went through all
> the review comments against each of the backend config patches and
> incorporated the suggestions people made.  The resultant changes have
> ended up a bit more extensive than I had expected, and I apologize for
> any toe stepping I'm doing but my hope is to move the collective work
> closer to being landable.
> 
> ---
> todo:
>   - Use backend-specific header #defines for struct_version values
> v5:
>   - Add missing compositor-drm.h
>   - Integrate wayland, x11, and headless backend patches
>   - Implement struct versioning for wayland, x11, and headless backend
> patches in the weston_backend_config structure, as requested by pq
>   - Drop bzero usage as suggested in review by Jan Engelhardt
>   - Don't change 'backend_init' entry point function name, as suggested
> in review by Giulio
>   - Prefer use of load_backend_new() for actual module loading, as
> suggested in Giulio's review of the x11 backend patch
>   - Refactor all backend initialization code paths and code style for
>   consistency.
>   - Squashed drm config struct versioning with drm patch; remainder moved
>   to a prerequisite patch.
> v4:
>   - Update to current trunk
>   - Add missing param doc for mode in drm_output_choose_initial_mode
>   - Rebase to account for code changes by 91880f1e to make vt
> switching configurable.
> 
> 
> 
> Benoit Gschwind (1):
>   x11: port the x11 backend to the new init api
> 
> Bryce Harrington (9):
>   Revert "main: Remove unused function load_backend_new()"
>   compositor: Version the backend configuration structures
>   drm: Fix gcc warning about missing braces.
>   compositor: Document refs for alternatives/assumptions for backend
> configs
>   headless: port the headless backend to the new init api
>   drm: Code and comments reformatting for consistency with other backend
> configs
>   drm: Don't hang onto the backend config object post-backend_init
>   Enforce destruction of all backend config objects after initialization
>   drm: Drop use of drm_config config wrapper
> 
> Giulio Camuffo (1):
>   drm: port the drm backend to the new init api
> 
>  Makefile.am   |   5 +
>  src/compositor-drm.c  | 216 ++--
>  src/compositor-drm.h  | 125 +++
>  src/compositor-headless.c |  69 +--
>  src/compositor-headless.h |  51 
>  src/compositor-x11.c  | 157 
>  src/compositor-x11.h  |  60 +
>  src/compositor.h  |  24 +++-
>  src/main.c| 304 
> +-
>  9 files changed, 734 insertions(+), 277 deletions(-)
>  create mode 100644 src/compositor-drm.h
>  create mode 100644 src/compositor-headless.h
>  create mode 100644 src/compositor-x11.h
> 

Hi,

patches: 1, 2, 4, 9, 10
are Reviewed-by: Pekka Paalanen 

Patch 3 already has my Acked-by and it is good to go, since the patches
coming later fix the issues I raised earlier.

Patch 5 seems to have dropped the email archive links, those would be
good to keep. With them added back, R-b me.

I think patches 8-11 should have come before 6 and 7. I needed to
review 8-11 first to see where design ended up, before I can check that
6 and 7 follow it too.

Seems like the changes in patch 10 should be squashed into the patches
converting each backend,  but okay anyway.

Patch 11 is R-b me otherwise, except it will need some changes
according to the comment to patch 8.

I am still in the middle of reviewing patches 6 and 7. Patch 6 has some
compositor-drm change mixed in. More comments for these two patches
will follow another day.


Thanks,
pq


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

Re: [PATCH weston v5 09/11] drm: Don't hang onto the backend config object post-backend_init

[Pekka Paalanen]

On Wed, 13 Apr 2016 03:25:13 -0700
Bryce Harrington  wrote:

> The drm backend was copying most everything out of the config object
> already, but now also copy the use_current_mode parameter and the
> config_output function pointer, so that there are no remaining
> references to the config object passed into backend_init().
> 
> By decoupling the config struct to the backend, if in the future if the
> structure definition changes in non-backwards compatible ways, then any
> version compatibility adaptation will be limited to just the
> backend_init() routine.
> 
> Signed-off-by: Bryce Harrington 
> ---
>  src/compositor-drm.c | 24 +++-
>  src/compositor-drm.h |  3 ++-
>  src/main.c   | 18 --
>  3 files changed, 25 insertions(+), 20 deletions(-)
> 
> diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> index 38296e2..722cc6a 100644
> --- a/src/compositor-drm.c
> +++ b/src/compositor-drm.c
> @@ -121,7 +121,17 @@ struct drm_backend {
>   int32_t cursor_width;
>   int32_t cursor_height;
>  
> - struct weston_drm_backend_config *config;
> +/** Callback used to configure the outputs.
> +  *
> + * This function will be called by the backend when a new DRM
> + * output needs to be configured.
> + */
> +enum weston_drm_backend_output_mode

Some whitespace damage here?

> + (*configure_output)(struct weston_compositor *compositor,
> + bool use_current_mode,
> + const char *name,
> + struct weston_drm_backend_output_config 
> *output_config);
> + bool use_current_mode;
>  };
>  
>  struct drm_mode {
> @@ -2311,8 +2321,8 @@ create_output_for_connector(struct drm_backend *b,
>   output->base.serial_number = "unknown";
>   wl_list_init(>base.mode_list);
>  
> - mode = b->config->configure_output(b->compositor, b->config,
> -output->base.name, );
> + mode = b->configure_output(b->compositor, b->use_current_mode,
> +output->base.name, );
>   if (parse_gbm_format(config.gbm_format, b->gbm_format, 
> >gbm_format) == -1)
>   output->gbm_format = b->gbm_format;
>  
> @@ -2699,11 +2709,6 @@ drm_destroy(struct weston_compositor *ec)
>   weston_launcher_destroy(ec->launcher);
>  
>   close(b->drm.fd);
> -
> - free(b->config->gbm_format);
> - free(b->config->seat_id);
> - free(b->config);
> -
>   free(b);
>  }
>  
> @@ -3054,7 +3059,8 @@ drm_backend_create(struct weston_compositor *compositor,
>   b->sprites_are_broken = 1;
>   b->compositor = compositor;
>   b->use_pixman = config->use_pixman;
> - b->config = config;
> + b->configure_output = config->configure_output;
> + b->use_current_mode = config->use_current_mode;
>  
>   if (parse_gbm_format(config->gbm_format, GBM_FORMAT_XRGB, 
> >gbm_format) < 0)
>   goto err_compositor;
> diff --git a/src/compositor-drm.h b/src/compositor-drm.h
> index 3b54ca5..7e0913a 100644
> --- a/src/compositor-drm.h
> +++ b/src/compositor-drm.h
> @@ -112,9 +112,10 @@ struct weston_drm_backend_config {
>*/
>   enum weston_drm_backend_output_mode
>   (*configure_output)(struct weston_compositor *compositor,
> - struct weston_drm_backend_config 
> *backend_config,
> + bool use_current_mode,
>   const char *name,
>   struct weston_drm_backend_output_config 
> *output_config);
> + bool use_current_mode;
>  };
>  
>  #ifdef  __cplusplus
> diff --git a/src/main.c b/src/main.c
> index f652701..c499fd0 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -683,11 +683,10 @@ struct drm_config {
>  
>  static enum weston_drm_backend_output_mode
>  drm_configure_output(struct weston_compositor *c,
> -  struct weston_drm_backend_config *backend_config,
> +  bool use_current_mode,
>const char *name,
>struct weston_drm_backend_output_config *config)
>  {
> - struct drm_config *drm_config = (struct drm_config *)backend_config;
>   struct weston_config *wc = weston_compositor_get_user_data(c);
>   struct weston_config_section *section;
>   char *s;
> @@ -702,7 +701,7 @@ drm_configure_output(struct weston_compositor *c,
>   return WESTON_DRM_BACKEND_OUTPUT_OFF;
>   }
>  
> - if (drm_config->use_current_mode || strcmp(s, "current") == 0) {
> + if (use_current_mode || strcmp(s, "current") == 0) {
>   mode = WESTON_DRM_BACKEND_OUTPUT_CURRENT;
>   } else if (strcmp(s, "preferred") != 0) {
>   config->modeline = s;
> @@ -756,13 +755,12 @@ load_drm_backend(struct weston_compositor *c, const 
> char *backend,
>   

Re: [PATCH weston v5 08/11] drm: Code and comments reformatting for consistency with other backend configs

[Pekka Paalanen]

On Wed, 13 Apr 2016 03:25:12 -0700
Bryce Harrington  wrote:

> Signed-off-by: Bryce Harrington 
> ---
>  src/compositor-drm.c | 10 ++
>  src/compositor-drm.h | 43 ---
>  src/main.c   |  6 --
>  3 files changed, 38 insertions(+), 21 deletions(-)
> 

> diff --git a/src/compositor-drm.h b/src/compositor-drm.h
> index 423378a..3b54ca5 100644
> --- a/src/compositor-drm.h
> +++ b/src/compositor-drm.h
> @@ -25,8 +25,8 @@
>   * SOFTWARE.
>   */
>  
> -#ifndef WESTON_COMPOSITOR_DRM_H
> -#define WESTON_COMPOSITOR_DRM_H
> +#ifndef _WESTON_COMPOSITOR_DRM_H
> +#define _WESTON_COMPOSITOR_DRM_H

Hi,

let's not add any more macros starting with an underscore. I suspect
they may be reserved.


> diff --git a/src/main.c b/src/main.c
> index 334464b..f652701 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -675,6 +675,7 @@ load_backend_new(struct weston_compositor *compositor, 
> const char *backend,
>  }
>  
>  
> +// TODO: Why is there a wrapper around the drm config base object?

Looks like a left-over: bad style and removed in a later patch.

>  struct drm_config {
>   struct weston_drm_backend_config base;
>   bool use_current_mode;
> @@ -731,7 +732,7 @@ load_drm_backend(struct weston_compositor *c, const char 
> *backend,
>   struct weston_config_section *section;
>   int ret = 0;
>  
> - config = zalloc(sizeof *config);
> + config = zalloc(sizeof (struct drm_config));

Please keep it as it was to ensure the variable and the sizeof
obviously match. It removes the need for change here in the patch
removing drm_config.

>   if (!config)
>   return -1;
>  
> @@ -755,7 +756,8 @@ load_drm_backend(struct weston_compositor *c, const char 
> *backend,
>   config->base.base.struct_size = sizeof(struct 
> weston_drm_backend_config);
>   config->base.configure_output = drm_configure_output;
>  
> - if (load_backend_new(c, backend, >base.base) < 0) {
> + if (load_backend_new(c, backend,
> +  (struct weston_backend_config *)(>base)) < 
> 0) {

This I don't understand. Why? The old form is shorter, maintains
type-safety, and does not depend on the particular layout of the struct.


>   ret = -1;
>   free(config->base.gbm_format);
>   free(config->base.seat_id);

All the above fixed, this gets:
Reviewed-by: Pekka Paalanen 


Thanks,
pq


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

Re: [PATCH 4/5] compositor: Version the backend configuration structures

[Pekka Paalanen]

On Tue, 12 Apr 2016 21:44:10 -0700
Bryce Harrington  wrote:

> On Wed, Apr 06, 2016 at 11:43:54AM +0300, Pekka Paalanen wrote:
> > On Mon, 21 Mar 2016 23:11:29 +0100
> > Benoit Gschwind  wrote:
> >   
> > > Hello,
> > > 
> > > I think that struct_version and struct_size should not be belong
> > > compositor.h. I think those versioning should be back-end detail, and
> > > each back-end should provide a major version number through #define in
> > > the backend header.  
> > 
> > Hi!
> > 
> > No, the struct fields do belong in compositor.h. These fields are
> > common to all backend-specific structs, and must be handled the same
> > everywhere, so they make perfect sense in compositor.h, in the
> > definition of struct weston_backend_config.
> > 
> > However, you are right in that backends must define the struct_version
> > values in a backend-specific header. That #define can (only) be used for
> > build time compatibility checks in #if directives in main.c.  
> 
> Agreed.  How should this #define be named?

Hi,

umm... WESTON_DRM_BACKEND_CONFIG_VERSION?

> > > Reviewed-by: Benoit Gschwind 
> > > 
> > > Le 10/03/2016 01:49, Bryce Harrington a écrit :  
> > > > With this struct versioning, it is possible to add new options without
> > > > breaking the ABI, as long as all additions are made to the end of a
> > > > struct and nothing existing is modified or removed.  When things are
> > > > added, the structure's size will increase, and we'll use this size as
> > > > our minor version number.  If existing things need to be changed, then
> > > > the major version, struct_version, is incremented to indicate the ABI
> > > > break.
> > > > 
> > > > From our call site in main we record these major and minor version as
> > > > struct_version and struct_size.  The backend then verifies these against
> > > > its own assumptions.  So long as the backend's struct is equal or larger
> > > > than what was passed in and the major versions are equal, we're good;
> > > > but if it is larger, then this is a fatal error.
> > > > 
> > > > Signed-off-by: Bryce Harrington 
> > > > ---
> > > >  src/compositor-drm.c | 10 --
> > > >  src/compositor.h | 16 
> > > >  src/main.c   |  2 ++
> > > >  3 files changed, 26 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/src/compositor-drm.c b/src/compositor-drm.c
> > > > index 5ddedb9..9bce285 100644
> > > > --- a/src/compositor-drm.c
> > > > +++ b/src/compositor-drm.c
> > > > @@ -3203,8 +3203,14 @@ backend_init(struct weston_compositor 
> > > > *compositor, int *argc, char *argv[],
> > > >   struct weston_backend_config *config_base)
> > > >  {
> > > > struct drm_backend *b;
> > > > -   struct weston_drm_backend_config *config =
> > > > -   (struct weston_drm_backend_config 
> > > > *)config_base;
> > > > +   struct weston_drm_backend_config *config;
> > > > +
> > > > +   if (config_base == NULL ||
> > > > +   config_base->struct_version != 1 ||
> > > > +   config_base->struct_size > sizeof(struct 
> > > > weston_drm_backend_config))
> > > > +   return -1;
> > > > +
> > > > +   config = (struct weston_drm_backend_config *)config_base;  
> > 
> > Like Quentin has suggested in IRC, this should be done as follows:  
> 
> Is there a log of that discussion?

Umh, it happened a while ago. Not really much else to say than it's a
nice trick to augment an incoming struct into a version used internally
in a library. That's the reason to pick sizeof() instead of an arbitrary
minor_version.

> > - allocate a private struct weston_drm_backend_config
> > - init the private config with all defaults
> > - copy the first struct_size bytes from the passed-in config to the
> >   private config
> > 
> > This allows the backend to add more fields to the end with default
> > values, and maintain compatiblity with the older main.c.  
> 
> So like in place of the cast line, do you mean something like:
> 
> config = zalloc(sizeof weston_drm_backend_config);
> if (config == NULL)
>  return -1;

Add init_to_defaults(config); here.

> memcpy(config, config_base, config_base->struct_size);
> 
> ?

Then memcpy only overwrites the passed in data and leaves the rest as
defaults.

This is the generic way. There might be shortcuts to be made if
everything is already copied into yet other variables anyway.

> > The reason is that sizeof(struct weston_drm_backend_config) is
> > different between the caller and callee, and we still need to get the
> > defaults in somehow. Using this copy trick allows the version check to
> > be in just one place, and all other code can trust that all the fields
> > are properly initialized (not dependent on version).
> > 
> > It is a shallow copy, which is a bit awkward, but I'm not sure there is
> > a simple and better way.


Thanks,

[PATCH weston v5 07/11] headless: port the headless backend to the new init api

[Bryce Harrington]

refactor configuration API of headless-backend

Signed-off-by: Bryce Harrington 

---
v5:
   - update to current trunk
   - fixed typo 'struct weston_wayland_backend_config'
   - dropped unused variables
   - dropped weston_headless_backend_config_create() in favor of
 directly zalloc'ing the object
   - dropped weston_headless_backend_load() in favor of the more
 generalized load_backend_new().
   - dropped typedef from header
   - restored use of 'backend_init' entry point
   - backend_init() takes a base weston_backend_config object
   - renamed 'param' to 'config' in a few places for consistency
   - renamed 'headless_options' variable to 'options for consistency
   - version the base struct
   - free config on error
   - don't free config during backend_init normal operations
   - adjust header ordering
   - make header guard naming consistent with other headers
   - light reformatting for code style and consistency with other
 backend config patches

 Makefile.am   |  1 +
 src/compositor-headless.c | 69 ---
 src/compositor-headless.h | 51 +++
 src/main.c| 45 +--
 4 files changed, 124 insertions(+), 42 deletions(-)
 create mode 100644 src/compositor-headless.h

diff --git a/Makefile.am b/Makefile.am
index fde6280..8a5e004 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -73,6 +73,7 @@ weston_SOURCES =  \
src/compositor.c\
src/compositor.h\
src/compositor-drm.h\
+   src/compositor-headless.h   \
src/compositor-x11.h\
src/input.c \
src/data-device.c   \
diff --git a/src/compositor-headless.c b/src/compositor-headless.c
index 16b5c39..0087347 100644
--- a/src/compositor-headless.c
+++ b/src/compositor-headless.c
@@ -31,33 +31,29 @@
 #include 
 #include 
 
-#include "shared/helpers.h"
 #include "compositor.h"
+#include "compositor-headless.h"
+#include "shared/helpers.h"
 #include "pixman-renderer.h"
 #include "presentation-time-server-protocol.h"
 
 struct headless_backend {
struct weston_backend base;
struct weston_compositor *compositor;
+
struct weston_seat fake_seat;
bool use_pixman;
 };
 
 struct headless_output {
struct weston_output base;
+
struct weston_mode mode;
struct wl_event_source *finish_frame_timer;
uint32_t *image_buf;
pixman_image_t *image;
 };
 
-struct headless_parameters {
-   int width;
-   int height;
-   int use_pixman;
-   uint32_t transform;
-};
-
 static void
 headless_output_start_repaint_loop(struct weston_output *output)
 {
@@ -120,7 +116,7 @@ headless_output_destroy(struct weston_output *output_base)
 
 static int
 headless_backend_create_output(struct headless_backend *b,
-  struct headless_parameters *param)
+  struct weston_headless_backend_config *config)
 {
struct weston_compositor *c = b->compositor;
struct headless_output *output;
@@ -132,15 +128,15 @@ headless_backend_create_output(struct headless_backend *b,
 
output->mode.flags =
WL_OUTPUT_MODE_CURRENT | WL_OUTPUT_MODE_PREFERRED;
-   output->mode.width = param->width;
-   output->mode.height = param->height;
+   output->mode.width = config->width;
+   output->mode.height = config->height;
output->mode.refresh = 6;
wl_list_init(>base.mode_list);
wl_list_insert(>base.mode_list, >mode.link);
 
output->base.current_mode = >mode;
-   weston_output_init(>base, c, 0, 0, param->width,
-  param->height, param->transform, 1);
+   weston_output_init(>base, c, 0, 0, config->width,
+  config->height, config->transform, 1);
 
output->base.make = "weston";
output->base.model = "headless";
@@ -158,15 +154,15 @@ headless_backend_create_output(struct headless_backend *b,
output->base.switch_mode = NULL;
 
if (b->use_pixman) {
-   output->image_buf = malloc(param->width * param->height * 4);
+   output->image_buf = malloc(config->width * config->height * 4);
if (!output->image_buf)
return -1;
 
output->image = pixman_image_create_bits(PIXMAN_x8r8g8b8,
-param->width,
-param->height,
+config->width,
+config->height,
 output->image_buf,
-   

[PATCH weston v5 00/11] drm: port the drm backend to the new init api

[Bryce Harrington]

In following up on my earlier update of Giulio's drm backend config
patch, I've taken the liberty to try and also integrate a couple of
Benoit's other backend configuration patches into this patchset.

Giulio and Benoit took different approaches in their implementations.
I've attempted to reconcile them so that they are stylistically
consistent, along with incorporating pq's request to have the root
config structure incorporate versioning information.  I went through all
the review comments against each of the backend config patches and
incorporated the suggestions people made.  The resultant changes have
ended up a bit more extensive than I had expected, and I apologize for
any toe stepping I'm doing but my hope is to move the collective work
closer to being landable.

---
todo:
  - Use backend-specific header #defines for struct_version values
v5:
  - Add missing compositor-drm.h
  - Integrate wayland, x11, and headless backend patches
  - Implement struct versioning for wayland, x11, and headless backend
patches in the weston_backend_config structure, as requested by pq
  - Drop bzero usage as suggested in review by Jan Engelhardt
  - Don't change 'backend_init' entry point function name, as suggested
in review by Giulio
  - Prefer use of load_backend_new() for actual module loading, as
suggested in Giulio's review of the x11 backend patch
  - Refactor all backend initialization code paths and code style for
consistency.
  - Squashed drm config struct versioning with drm patch; remainder moved
to a prerequisite patch.
v4:
  - Update to current trunk
  - Add missing param doc for mode in drm_output_choose_initial_mode
  - Rebase to account for code changes by 91880f1e to make vt
switching configurable.



Benoit Gschwind (1):
  x11: port the x11 backend to the new init api

Bryce Harrington (9):
  Revert "main: Remove unused function load_backend_new()"
  compositor: Version the backend configuration structures
  drm: Fix gcc warning about missing braces.
  compositor: Document refs for alternatives/assumptions for backend
configs
  headless: port the headless backend to the new init api
  drm: Code and comments reformatting for consistency with other backend
configs
  drm: Don't hang onto the backend config object post-backend_init
  Enforce destruction of all backend config objects after initialization
  drm: Drop use of drm_config config wrapper

Giulio Camuffo (1):
  drm: port the drm backend to the new init api

 Makefile.am   |   5 +
 src/compositor-drm.c  | 216 ++--
 src/compositor-drm.h  | 125 +++
 src/compositor-headless.c |  69 +--
 src/compositor-headless.h |  51 
 src/compositor-x11.c  | 157 
 src/compositor-x11.h  |  60 +
 src/compositor.h  |  24 +++-
 src/main.c| 304 +-
 9 files changed, 734 insertions(+), 277 deletions(-)
 create mode 100644 src/compositor-drm.h
 create mode 100644 src/compositor-headless.h
 create mode 100644 src/compositor-x11.h

-- 
1.9.1

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

[PATCH weston v5 09/11] drm: Don't hang onto the backend config object post-backend_init

[Bryce Harrington]

The drm backend was copying most everything out of the config object
already, but now also copy the use_current_mode parameter and the
config_output function pointer, so that there are no remaining
references to the config object passed into backend_init().

By decoupling the config struct to the backend, if in the future if the
structure definition changes in non-backwards compatible ways, then any
version compatibility adaptation will be limited to just the
backend_init() routine.

Signed-off-by: Bryce Harrington 
---
 src/compositor-drm.c | 24 +++-
 src/compositor-drm.h |  3 ++-
 src/main.c   | 18 --
 3 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 38296e2..722cc6a 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -121,7 +121,17 @@ struct drm_backend {
int32_t cursor_width;
int32_t cursor_height;
 
-   struct weston_drm_backend_config *config;
+/** Callback used to configure the outputs.
+*
+ * This function will be called by the backend when a new DRM
+ * output needs to be configured.
+ */
+enum weston_drm_backend_output_mode
+   (*configure_output)(struct weston_compositor *compositor,
+   bool use_current_mode,
+   const char *name,
+   struct weston_drm_backend_output_config 
*output_config);
+   bool use_current_mode;
 };
 
 struct drm_mode {
@@ -2311,8 +2321,8 @@ create_output_for_connector(struct drm_backend *b,
output->base.serial_number = "unknown";
wl_list_init(>base.mode_list);
 
-   mode = b->config->configure_output(b->compositor, b->config,
-  output->base.name, );
+   mode = b->configure_output(b->compositor, b->use_current_mode,
+  output->base.name, );
if (parse_gbm_format(config.gbm_format, b->gbm_format, 
>gbm_format) == -1)
output->gbm_format = b->gbm_format;
 
@@ -2699,11 +2709,6 @@ drm_destroy(struct weston_compositor *ec)
weston_launcher_destroy(ec->launcher);
 
close(b->drm.fd);
-
-   free(b->config->gbm_format);
-   free(b->config->seat_id);
-   free(b->config);
-
free(b);
 }
 
@@ -3054,7 +3059,8 @@ drm_backend_create(struct weston_compositor *compositor,
b->sprites_are_broken = 1;
b->compositor = compositor;
b->use_pixman = config->use_pixman;
-   b->config = config;
+   b->configure_output = config->configure_output;
+   b->use_current_mode = config->use_current_mode;
 
if (parse_gbm_format(config->gbm_format, GBM_FORMAT_XRGB, 
>gbm_format) < 0)
goto err_compositor;
diff --git a/src/compositor-drm.h b/src/compositor-drm.h
index 3b54ca5..7e0913a 100644
--- a/src/compositor-drm.h
+++ b/src/compositor-drm.h
@@ -112,9 +112,10 @@ struct weston_drm_backend_config {
 */
enum weston_drm_backend_output_mode
(*configure_output)(struct weston_compositor *compositor,
-   struct weston_drm_backend_config 
*backend_config,
+   bool use_current_mode,
const char *name,
struct weston_drm_backend_output_config 
*output_config);
+   bool use_current_mode;
 };
 
 #ifdef  __cplusplus
diff --git a/src/main.c b/src/main.c
index f652701..c499fd0 100644
--- a/src/main.c
+++ b/src/main.c
@@ -683,11 +683,10 @@ struct drm_config {
 
 static enum weston_drm_backend_output_mode
 drm_configure_output(struct weston_compositor *c,
-struct weston_drm_backend_config *backend_config,
+bool use_current_mode,
 const char *name,
 struct weston_drm_backend_output_config *config)
 {
-   struct drm_config *drm_config = (struct drm_config *)backend_config;
struct weston_config *wc = weston_compositor_get_user_data(c);
struct weston_config_section *section;
char *s;
@@ -702,7 +701,7 @@ drm_configure_output(struct weston_compositor *c,
return WESTON_DRM_BACKEND_OUTPUT_OFF;
}
 
-   if (drm_config->use_current_mode || strcmp(s, "current") == 0) {
+   if (use_current_mode || strcmp(s, "current") == 0) {
mode = WESTON_DRM_BACKEND_OUTPUT_CURRENT;
} else if (strcmp(s, "preferred") != 0) {
config->modeline = s;
@@ -756,13 +755,12 @@ load_drm_backend(struct weston_compositor *c, const char 
*backend,
config->base.base.struct_size = sizeof(struct 
weston_drm_backend_config);
config->base.configure_output = drm_configure_output;
 
-   if (load_backend_new(c, backend,
-(struct weston_backend_config *)(>base)) < 
0) {
-  

[PATCH weston v5 01/11] Revert "main: Remove unused function load_backend_new()"

[Bryce Harrington]

This reverts commit 5ffbfffaf7758c33791978516d0a1100773b85e2.

Restore load_backend_new() for use with libweston backend configuration.

Signed-off-by: Bryce Harrington 
---
 src/main.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/src/main.c b/src/main.c
index 1850fa6..43de354 100644
--- a/src/main.c
+++ b/src/main.c
@@ -653,6 +653,23 @@ load_backend_old(struct weston_compositor *compositor, 
const char *backend,
return backend_init(compositor, argc, argv, wc, NULL);
 }
 
+/* Temporary function to be replaced by weston_compositor_load_backend(). */
+static int
+load_backend_new(struct weston_compositor *compositor, const char *backend,
+struct weston_backend_config *config_base)
+{
+   int (*backend_init)(struct weston_compositor *c,
+   int *argc, char *argv[],
+   struct weston_config *config,
+   struct weston_backend_config *config_base);
+
+   backend_init = weston_load_module(backend, "backend_init");
+   if (!backend_init)
+   return -1;
+
+   return backend_init(compositor, NULL, NULL, NULL, config_base);
+}
+
 static int
 load_backend(struct weston_compositor *compositor, const char *backend,
 int *argc, char **argv, struct weston_config *config)
-- 
1.9.1

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

[PATCH weston v5 04/11] drm: Fix gcc warning about missing braces.

[Bryce Harrington]

Use double-brackets for config initializer for
create_output_for_connector to avoid gcc warning, since first
element is another struct.  (See GCC bug 53119.)

Quells warning:
  src/compositor-drm.c: In function ‘create_output_for_connector’:
  src/compositor-drm.c:2292:9: warning: missing braces around initializer
  [-Wmissing-braces]
struct weston_drm_backend_output_config config = { 0 };
   ^
  src/compositor-drm.c:2292:9: warning: (near initialization for
  ‘config.base’) [-Wmissing-braces]

Signed-off-by: Bryce Harrington 
---
 src/compositor-drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 508b7e8..21af671 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -2292,7 +2292,7 @@ create_output_for_connector(struct drm_backend *b,
drmModeModeInfo crtc_mode;
int i;
enum weston_drm_backend_output_mode mode;
-   struct weston_drm_backend_output_config config = { 0 };
+   struct weston_drm_backend_output_config config = {{ 0 }};
 
i = find_crtc_for_connector(b, resources, connector);
if (i < 0) {
-- 
1.9.1

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

[PATCH weston v5 05/11] compositor: Document refs for alternatives/assumptions for backend configs

[Bryce Harrington]

Signed-off-by: Bryce Harrington 
---
 src/compositor.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index f93d76a..45ffb6c 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -682,6 +682,12 @@ struct weston_backend_output_config {
  * passed to the backend's init entry point. The backend will
  * likely want to subclass this in order to handle backend specific
  * data.
+ *
+ * NOTE: Alternate designs were proposed (Feb 2016) for using opaque
+ * structures and for section+key/value getter/setters.  The rationale
+ * for selecting the transparent structure design is based on several
+ * assumptions which may require re-evaluating the design choice if they
+ * fail to hold.
  */
 struct weston_backend_config {
/** Major version for the backend-specific config struct
-- 
1.9.1

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

[PATCH weston v5 10/11] Enforce destruction of all backend config objects after initialization

[Bryce Harrington]

Since the backend config struct versioning implies that there we expect
potential future descrepancy between main's definition of the config
object and the backend's, don't allow the backend to hang onto the
config object outside the initialization scope.

Signed-off-by: Bryce Harrington 
---
 src/main.c | 35 +++
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/src/main.c b/src/main.c
index c499fd0..6463e7a 100644
--- a/src/main.c
+++ b/src/main.c
@@ -657,7 +657,20 @@ load_backend_old(struct weston_compositor *compositor, 
const char *backend,
return backend_init(compositor, argc, argv, wc, NULL);
 }
 
-/* Temporary function to be replaced by weston_compositor_load_backend(). */
+/** Main module call-point for backends.
+ *
+ * All backends should use this routine to access their init routine.
+ * Backends may subclass weston_backend_config to add their own
+ * configuration data, setting the major/minor version in config_base
+ * accordingly.
+ *
+ * The config_base object should be treated as temporary, and any data
+ * copied out of it by backend_init before returning.  The load_backend_new
+ * callers may then free the config_base object.
+ *
+ * NOTE: This is a temporary function intended to eventually be replaced
+ * by weston_compositor_load_backend().
+ */
 static int
 load_backend_new(struct weston_compositor *compositor, const char *backend,
 struct weston_backend_config *config_base)
@@ -796,11 +809,10 @@ load_headless_backend(struct weston_compositor *c, char 
const * backend,
config->base.struct_size = sizeof(struct 
weston_headless_backend_config);
 
/* load the actual wayland backend and configure it */
-   if (load_backend_new(c, backend,
-(struct weston_backend_config *)config) < 0) {
-   ret = -1;
-   free(config);
-   }
+   ret = load_backend_new(c, backend,
+  (struct weston_backend_config *)config);
+
+   free(config);
 
return ret;
 }
@@ -896,7 +908,7 @@ load_x11_backend(struct weston_compositor *c, char const * 
backend,
 
if (weston_x11_backend_config_append_output_config(config, 
_output) < 0) {
ret = -1;
-   goto error;
+   goto out;
}
 
output_count++;
@@ -917,7 +929,7 @@ load_x11_backend(struct weston_compositor *c, char const * 
backend,
 
if (weston_x11_backend_config_append_output_config(config, 
_output) < 0) {
ret = -1;
-   goto error;
+   goto out;
}
}
 
@@ -928,16 +940,15 @@ load_x11_backend(struct weston_compositor *c, char const 
* backend,
if (load_backend_new(c, backend,
 (struct weston_backend_config *)config) < 0) {
ret = -1;
-   goto error;
+   goto out;
}
 
-   return ret;
-
-error:
+out:
for (j = 0; j < config->num_outputs; ++j)
free(config->outputs[j].name);
free(config->outputs);
free(config);
+
return ret;
 }
 
-- 
1.9.1

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

[PATCH weston v5 11/11] drm: Drop use of drm_config config wrapper

[Bryce Harrington]

With the use_current_mode moved into the main config class, this small
wrapper is redundant.  Dropping it helps make the drm backend config
initialization more consistent with the other backends.

Signed-off-by: Bryce Harrington 
---
 src/main.c | 35 ++-
 1 file changed, 14 insertions(+), 21 deletions(-)

diff --git a/src/main.c b/src/main.c
index 6463e7a..8ec8701 100644
--- a/src/main.c
+++ b/src/main.c
@@ -688,12 +688,6 @@ load_backend_new(struct weston_compositor *compositor, 
const char *backend,
 }
 
 
-// TODO: Why is there a wrapper around the drm config base object?
-struct drm_config {
-   struct weston_drm_backend_config base;
-   bool use_current_mode;
-};
-
 static enum weston_drm_backend_output_mode
 drm_configure_output(struct weston_compositor *c,
 bool use_current_mode,
@@ -740,39 +734,38 @@ static int
 load_drm_backend(struct weston_compositor *c, const char *backend,
 int *argc, char **argv, struct weston_config *wc)
 {
-   struct drm_config *config;
+   struct weston_drm_backend_config *config;
struct weston_config_section *section;
int ret = 0;
 
-   config = zalloc(sizeof (struct drm_config));
+   config = zalloc(sizeof (struct weston_drm_backend_config));
if (!config)
return -1;
 
const struct weston_option options[] = {
-   { WESTON_OPTION_INTEGER, "connector", 0, 
>base.connector },
-   { WESTON_OPTION_STRING, "seat", 0, >base.seat_id },
-   { WESTON_OPTION_INTEGER, "tty", 0, >base.tty },
-   { WESTON_OPTION_BOOLEAN, "current-mode", 0,
- >use_current_mode },
-   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, 
>base.use_pixman },
+   { WESTON_OPTION_INTEGER, "connector", 0, >connector },
+   { WESTON_OPTION_STRING, "seat", 0, >seat_id },
+   { WESTON_OPTION_INTEGER, "tty", 0, >tty },
+   { WESTON_OPTION_BOOLEAN, "current-mode", 0, 
>use_current_mode },
+   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, >use_pixman },
};
 
parse_options(options, ARRAY_LENGTH(options), argc, argv);
 
section = weston_config_get_section(wc, "core", NULL, NULL);
weston_config_section_get_string(section,
-"gbm-format", >base.gbm_format,
+"gbm-format", >gbm_format,
 NULL);
 
-   config->base.base.struct_version = 1;
-   config->base.base.struct_size = sizeof(struct 
weston_drm_backend_config);
-   config->base.configure_output = drm_configure_output;
+   config->base.struct_version = 1;
+   config->base.struct_size = sizeof(struct weston_drm_backend_config);
+   config->configure_output = drm_configure_output;
 
ret = load_backend_new(c, backend,
-  (struct weston_backend_config *)(>base));
+  (struct weston_backend_config *)config);
 
-   free(config->base.gbm_format);
-   free(config->base.seat_id);
+   free(config->gbm_format);
+   free(config->seat_id);
free(config);
 
return ret;
-- 
1.9.1

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

[PATCH weston v5 08/11] drm: Code and comments reformatting for consistency with other backend configs

[Bryce Harrington]

Signed-off-by: Bryce Harrington 
---
 src/compositor-drm.c | 10 ++
 src/compositor-drm.h | 43 ---
 src/main.c   |  6 --
 3 files changed, 38 insertions(+), 21 deletions(-)

diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index aee42ea..38296e2 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -46,13 +46,13 @@
 #include 
 #include 
 
-#include "shared/helpers.h"
-#include "shared/timespec-util.h"
-#include "libbacklight.h"
 #include "compositor.h"
 #include "compositor-drm.h"
+#include "shared/helpers.h"
+#include "shared/timespec-util.h"
 #include "gl-renderer.h"
 #include "pixman-renderer.h"
+#include "libbacklight.h"
 #include "libinput-seat.h"
 #include "launcher-util.h"
 #include "vaapi-recorder.h"
@@ -3201,7 +3201,8 @@ err_compositor:
 }
 
 WL_EXPORT int
-backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
+backend_init(struct weston_compositor *compositor,
+int *argc, char *argv[],
 struct weston_config *wc,
 struct weston_backend_config *config_base)
 {
@@ -3221,5 +3222,6 @@ backend_init(struct weston_compositor *compositor, int 
*argc, char *argv[],
b = drm_backend_create(compositor, config);
if (b == NULL)
return -1;
+
return 0;
 }
diff --git a/src/compositor-drm.h b/src/compositor-drm.h
index 423378a..3b54ca5 100644
--- a/src/compositor-drm.h
+++ b/src/compositor-drm.h
@@ -25,8 +25,8 @@
  * SOFTWARE.
  */
 
-#ifndef WESTON_COMPOSITOR_DRM_H
-#define WESTON_COMPOSITOR_DRM_H
+#ifndef _WESTON_COMPOSITOR_DRM_H
+#define _WESTON_COMPOSITOR_DRM_H
 
 #ifdef  __cplusplus
 extern "C" {
@@ -73,30 +73,43 @@ struct weston_drm_backend_output_config {
 struct weston_drm_backend_config {
struct weston_backend_config base;
 
-   /** The connector id of the output to be initialized. A value of 0 will
-* enable all available outputs. */
+   /** The connector id of the output to be initialized.
+*
+* A value of 0 will enable all available outputs.
+*/
int connector;
+
/** The tty to be used. Set to 0 to use the current tty. */
int tty;
-   /** If true the pixman renderer will be used instead of the OpenGL ES
-* renderer. */
+
+   /** Whether to use the pixman renderer instead of the OpenGL ES 
renderer. */
bool use_pixman;
-   /** The seat to be used for input and output. If NULL the default 
"seat0"
-* will be used.
-* The backend will take ownership of the seat_id pointer and will free
-* it on backend destruction. */
+
+   /** The seat to be used for input and output.
+*
+* If NULL the default "seat0" will be used.  The backend will
+* take ownership of the seat_id pointer and will free it on
+* backend destruction.
+*/
char *seat_id;
-   /** The pixel format of the framebuffer to be used. Valid values are:
+
+   /** The pixel format of the framebuffer to be used.
+*
+* Valid values are:
 * - NULL - The default format ("xrgb") will be used;
 * - "xrgb";
 * - "rgb565"
 * - "xrgb2101010"
 * The backend will take ownership of the format pointer and will free
-* it on backend destruction. */
+* it on backend destruction.
+*/
char *gbm_format;
 
-   /** Callback used to configure the outputs. This function will be called
-* by the backend when a new DRM output needs to be configured. */
+   /** Callback used to configure the outputs.
+*
+* This function will be called by the backend when a new DRM
+* output needs to be configured.
+*/
enum weston_drm_backend_output_mode
(*configure_output)(struct weston_compositor *compositor,
struct weston_drm_backend_config 
*backend_config,
@@ -108,4 +121,4 @@ struct weston_drm_backend_config {
 }
 #endif
 
-#endif
+#endif /* _WESTON_COMPOSITOR_DRM_H */
diff --git a/src/main.c b/src/main.c
index 334464b..f652701 100644
--- a/src/main.c
+++ b/src/main.c
@@ -675,6 +675,7 @@ load_backend_new(struct weston_compositor *compositor, 
const char *backend,
 }
 
 
+// TODO: Why is there a wrapper around the drm config base object?
 struct drm_config {
struct weston_drm_backend_config base;
bool use_current_mode;
@@ -731,7 +732,7 @@ load_drm_backend(struct weston_compositor *c, const char 
*backend,
struct weston_config_section *section;
int ret = 0;
 
-   config = zalloc(sizeof *config);
+   config = zalloc(sizeof (struct drm_config));
if (!config)
return -1;
 
@@ -755,7 +756,8 @@ load_drm_backend(struct weston_compositor *c, const char 
*backend,
config->base.base.struct_size = sizeof(struct 
weston_drm_backend_config);

[PATCH weston v5 06/11] x11: port the x11 backend to the new init api

[Bryce Harrington]

From: Benoit Gschwind 

Use a "well" defined structure to configure x11-backend and move configuration
file parsing inside the weston compositor code.

Signed-off-by: Bryce Harrington 

---
v5:
  - Update to current trunk
  - Reformated for style consistency (e.g. spaces in "if(",
linebreaks, etc.)
  - Move variable declarations to top of block
  - Rename header guard for consistency with other headers
  - Other misc. code style formatting fixes
  - Adjust code style to better match drm backend config
  - Version the config struct
  - Dropped use of bzero in favor of zalloc
  - Don't initialize vars already zalloc'd
  - Dropped weston_x11_backend_load in favor of more general
load_backend_new routine
  - Dropped weston_x11_backend_config_outputs_clear and just free
outputs in error handler for init routine
  - Dropped some temp variables for output configuration
  - Restore use of 'backend_init' as module entrypoint
  - Rename 'ths' to 'config' for backend config structs
  - Rename 'x11_options' to 'options' for consistency
  - Rename other variables for consistency with other code
  - Rename 'noutputs' to 'num_outputs'

 Makefile.am  |   1 +
 src/compositor-drm.c |   5 +-
 src/compositor-x11.c | 157 ++-
 src/compositor-x11.h |  60 
 src/main.c   | 142 +-
 5 files changed, 259 insertions(+), 106 deletions(-)
 create mode 100644 src/compositor-x11.h

diff --git a/Makefile.am b/Makefile.am
index f4cff4c..fde6280 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -73,6 +73,7 @@ weston_SOURCES =  \
src/compositor.c\
src/compositor.h\
src/compositor-drm.h\
+   src/compositor-x11.h\
src/input.c \
src/data-device.c   \
src/screenshooter.c \
diff --git a/src/compositor-drm.c b/src/compositor-drm.c
index 21af671..aee42ea 100644
--- a/src/compositor-drm.c
+++ b/src/compositor-drm.c
@@ -3213,7 +3213,10 @@ backend_init(struct weston_compositor *compositor, int 
*argc, char *argv[],
config_base->struct_size > sizeof(struct weston_drm_backend_config))
return -1;
 
-   config = (struct weston_drm_backend_config *)config_base;
+   config = zalloc(sizeof(struct weston_drm_backend_config));
+   if (config == NULL)
+   return -1;
+   memcpy(config, config_base, config_base->struct_size);
 
b = drm_backend_create(compositor, config);
if (b == NULL)
diff --git a/src/compositor-x11.c b/src/compositor-x11.c
index f1cb71b..f4b2f37 100644
--- a/src/compositor-x11.c
+++ b/src/compositor-x11.c
@@ -50,21 +50,17 @@
 #include 
 
 #include "compositor.h"
-#include "gl-renderer.h"
-#include "pixman-renderer.h"
+#include "compositor-x11.h"
 #include "shared/config-parser.h"
 #include "shared/helpers.h"
 #include "shared/image-loader.h"
+#include "gl-renderer.h"
+#include "pixman-renderer.h"
 #include "presentation-time-server-protocol.h"
 #include "linux-dmabuf.h"
 
 #define DEFAULT_AXIS_STEP_DISTANCE 10
 
-static int option_width;
-static int option_height;
-static int option_scale;
-static int option_count;
-
 struct x11_backend {
struct weston_backendbase;
struct weston_compositor *compositor;
@@ -1566,24 +1562,15 @@ init_gl_renderer(struct x11_backend *b)
 
return ret;
 }
+
 static struct x11_backend *
 x11_backend_create(struct weston_compositor *compositor,
-  int fullscreen,
-  int no_input,
-  int use_pixman,
-  int *argc, char *argv[],
-  struct weston_config *config)
+  struct weston_x11_backend_config *config)
 {
struct x11_backend *b;
struct x11_output *output;
-   struct weston_config_section *section;
-   int i, x = 0, output_count = 0;
-   int width, height, scale, count;
-   const char *section_name;
-   char *name, *t, *mode;
-   uint32_t transform;
-
-   weston_log("initializing x11 backend\n");
+   int x = 0;
+   unsigned i;
 
b = zalloc(sizeof *b);
if (b == NULL)
@@ -1609,13 +1596,13 @@ x11_backend_create(struct weston_compositor *compositor,
x11_backend_get_resources(b);
x11_backend_get_wm_info(b);
 
-   if (!b->has_net_wm_state_fullscreen && fullscreen) {
+   if (!b->has_net_wm_state_fullscreen && config->fullscreen) {
weston_log("Can not fullscreen without window manager support"
   "(need _NET_WM_STATE_FULLSCREEN)\n");
-   fullscreen = 0;
+   config->fullscreen = 0;
}
 
-   b->use_pixman = 

[PATCH weston v5 02/11] compositor: Version the backend configuration structures

[Bryce Harrington]

With this struct versioning, it is possible to add new options without
breaking the ABI, as long as all additions are made to the end of a
struct and nothing existing is modified or removed.  When things are
added, the structure's size will increase, and we'll use this size as
our minor version number.  If existing things need to be changed, then
the major version, struct_version, is incremented to indicate the ABI
break.

From our call sites in main these major and minor version will be
recorded as struct_version and struct_size.  Each backend will then
verify these against its own assumptions.  So long as the backend's
struct is equal or larger than what was passed in and the major versions
are equal, we're good; but if it is larger, then this is a fatal error.

Signed-off-by: Bryce Harrington 

---
v5:
 - Move the header changes to a pre-requisite patch from the drm backend

 src/compositor.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/src/compositor.h b/src/compositor.h
index 08b4059..5654b04 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -686,6 +686,22 @@ struct weston_backend_output_config {
  * data.
  */
 struct weston_backend_config {
+   /** Major version for the backend-specific config struct
+*
+* This version must match exactly what the backend expects, otherwise
+* the struct is incompatible.
+*/
+   uint32_t struct_version;
+
+   /** Minor version of the backend-specific config struct
+*
+* This must be set to sizeof(struct backend-specific config).
+* If the value here is smaller than what the backend expects, the
+* extra config members will assume their default values.
+*
+* A value greater than what the backend expects is incompatible.
+*/
+   size_t struct_size;
 };
 
 struct weston_backend {
-- 
1.9.1

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

Re: [PATCH libinput] udev: update the hwdb matches to avoid use of ( and )

[Hans de Goede]

Hi,

On 13-04-16 07:06, Peter Hutterer wrote:

libudev's util_replace_chars() replaces the () with underscores so that match
would work too but let's use ? instead to make it look like a regex.

This now activates the rules for all cyapa touchpads, before they wouldn't
have applied to any device.

https://bugs.freedesktop.org/show_bug.cgi?id=93846#c12

Signed-off-by: Peter Hutterer 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans


---
  udev/90-libinput-model-quirks.hwdb | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/udev/90-libinput-model-quirks.hwdb 
b/udev/90-libinput-model-quirks.hwdb
index d5978f7..242c444 100644
--- a/udev/90-libinput-model-quirks.hwdb
+++ b/udev/90-libinput-model-quirks.hwdb
@@ -62,22 +62,22 @@ libinput:name:*ETPS/2 Elantech Touchpad*:dmi:*
  # The various chromebooks, info from modinfo chromeos_laptop, touchpad names
  # extrapolated from the chromiumos touchad-tests repo
  # https://chromium.googlesource.com/chromiumos/platform/touchpad-tests
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pnFalco:pvr*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pnFalco:pvr*
  libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*Mario*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Butterfly*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Peppy*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Butterfly*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Peppy*
  libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*ZGB*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*pn*Parrot*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Leon*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Falco*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*bvn*coreboot*:pn*Wolf*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*svn*GOOGLE*:pn*Link*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*pn*Parrot*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Leon*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Falco*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*bvn*coreboot*:pn*Wolf*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*svn*GOOGLE*:pn*Link*
  libinput:name:SynPS/2 Synaptics TouchPad:dmi:*pn*Alex*
-libinput:name:Cypress APA Trackpad (cyapa):dmi:*svn*SAMSUNG*:pn*Lumpy*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*svn*SAMSUNG*:pn*Lumpy*
  libinput:name:Atmel maXTouch Touchpad:dmi:*svn*GOOGLE*:pn*Samus*
   LIBINPUT_MODEL_CHROMEBOOK=1

-libinput:name:Cypress APA Trackpad (cyapa):dmi:*
+libinput:name:Cypress APA Trackpad ?cyapa?:dmi:*
   LIBINPUT_MODEL_CYAPA=1

  ##


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

Re: [PATCH libinput] test: add test for no scroll events before the scroll button timeout

[Hans de Goede]

Hi,

On 12-04-16 20:50, Peter Hutterer wrote:

Signed-off-by: Peter Hutterer 


Looks good to me:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
  src/evdev.c|  2 ++
  test/pointer.c | 31 +++
  2 files changed, 33 insertions(+)

diff --git a/src/evdev.c b/src/evdev.c
index f0311c6..a237ce6 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -280,6 +280,8 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
evdev_post_scroll(device, time,
  LIBINPUT_POINTER_AXIS_SOURCE_CONTINUOUS,
  );
+   /* if the button is down but scroll is not active, we're within the
+  timeout where swallow motion events but don't post scroll buttons */

return true;
  }
diff --git a/test/pointer.c b/test/pointer.c
index a34740a..8c7ad46 100644
--- a/test/pointer.c
+++ b/test/pointer.c
@@ -893,6 +893,36 @@ START_TEST(pointer_scroll_button)
  }
  END_TEST

+START_TEST(pointer_scroll_button_no_event_before_timeout)
+{
+   struct litest_device *device = litest_current_device();
+   struct libinput *li = device->libinput;
+   int i;
+
+   disable_button_scrolling(device);
+
+   libinput_device_config_scroll_set_method(device->libinput_device,
+   LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN);
+   libinput_device_config_scroll_set_button(device->libinput_device,
+BTN_LEFT);
+   litest_drain_events(li);
+
+   litest_button_click(device, BTN_LEFT, true);
+   litest_assert_empty_queue(li);
+
+   for (i = 0; i < 10; i++) {
+   litest_event(device, EV_REL, REL_Y, 1);
+   litest_event(device, EV_SYN, SYN_REPORT, 0);
+   }
+   litest_assert_empty_queue(li);
+
+   litest_timeout_buttonscroll();
+   libinput_dispatch(li);
+   litest_button_click(device, BTN_LEFT, false);
+   litest_assert_empty_queue(li);
+}
+END_TEST
+
  START_TEST(pointer_scroll_nowheel_defaults)
  {
struct litest_device *dev = litest_current_device();
@@ -1600,6 +1630,7 @@ litest_setup_tests(void)
litest_add_no_device("pointer:button", pointer_seat_button_count);
litest_add("pointer:scroll", pointer_scroll_wheel, LITEST_WHEEL, 
LITEST_TABLET);
litest_add("pointer:scroll", pointer_scroll_button, 
LITEST_RELATIVE|LITEST_BUTTON, LITEST_ANY);
+   litest_add("pointer:scroll", 
pointer_scroll_button_no_event_before_timeout, LITEST_RELATIVE|LITEST_BUTTON, LITEST_ANY);
litest_add("pointer:scroll", pointer_scroll_nowheel_defaults, 
LITEST_RELATIVE|LITEST_BUTTON, LITEST_WHEEL);
litest_add("pointer:scroll", pointer_scroll_natural_defaults, 
LITEST_WHEEL, LITEST_TABLET);
litest_add("pointer:scroll", pointer_scroll_natural_enable_config, 
LITEST_WHEEL, LITEST_TABLET);


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

Re: [PATCH v2 2/4 libinput] evdev: split scroll button state check out

[Hans de Goede]

Hi,

On 12-04-16 20:50, Peter Hutterer wrote:

Rather than checking the physical key's state, set a flag for the button to be
down. This enables us to use non-physical buttons (middle button emulation).

Signed-off-by: Peter Hutterer 


Looks good to me now:

Reviewed-by: Hans de Goede 

Regards,

Hans



---
changes to v1:
- replaces previous 2/4 patch

  src/evdev.c | 4 +++-
  src/evdev.h | 1 +
  2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/evdev.c b/src/evdev.c
index 7ffc464..2afec6e 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -273,7 +273,7 @@ evdev_post_trackpoint_scroll(struct evdev_device *device,
 uint64_t time)
  {
if (device->scroll.method != LIBINPUT_CONFIG_SCROLL_ON_BUTTON_DOWN ||
-   !hw_is_key_down(device, device->scroll.button))
+   !device->scroll.button_scroll_btn_pressed)
return false;

if (device->scroll.button_scroll_active)
@@ -494,6 +494,8 @@ static void
  evdev_button_scroll_button(struct evdev_device *device,
   uint64_t time, int is_press)
  {
+   device->scroll.button_scroll_btn_pressed = is_press;
+
if (is_press) {
libinput_timer_set(>scroll.timer,
   time + DEFAULT_MIDDLE_BUTTON_SCROLL_TIMEOUT);
diff --git a/src/evdev.h b/src/evdev.h
index 3a7693e..520446d 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -173,6 +173,7 @@ struct evdev_device {
/* Checks if buttons are down and commits the setting */
void (*change_scroll_method)(struct evdev_device *device);
bool button_scroll_active;
+   bool button_scroll_btn_pressed;
double threshold;
double direction_lock_threshold;
uint32_t direction;


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

[PATCH wayland-protocols 2/4] stable/presentation-time: grammatical improvements by Bryce

[Pekka Paalanen]

From: Pekka Paalanen 

Suggested-by: Bryce Harrington 
Signed-off-by: Pekka Paalanen 
---
 stable/presentation-time/presentation-time.xml | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/stable/presentation-time/presentation-time.xml 
b/stable/presentation-time/presentation-time.xml
index 6c3fff8..ad2d132 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -33,8 +33,8 @@
   The main feature of this interface is accurate presentation
   timing feedback to ensure smooth video playback while maintaining
   audio/video synchronization. Some features use the concept of a
-  presentation clock, which is defined in presentation.clock_id
-  event.
+  presentation clock, which is defined in the
+  presentation.clock_id event.
 
   Request 'feedback' can be regarded as an additional wl_surface
   method. It is part of the double-buffered surface state update
@@ -65,9 +65,9 @@
 
 
   
-Informs the server that the client will not be using this
-protocol object anymore. This does not affect any existing
-objects created by this interface.
+Informs the server that the client will no longer be using
+this protocol object. Existing objects created by this object
+are not affected.
   
 
 
@@ -140,7 +140,7 @@
   update because it was superseded or its surface destroyed,
   and the content update is discarded.
 
-  Once a presentation_feedback object has delivered an 'presented'
+  Once a presentation_feedback object has delivered a 'presented'
   or 'discarded' event it is automatically destroyed.
 
 
@@ -225,7 +225,7 @@
 chose. Having a stable presentation output association helps
 clients predict future output refreshes (vblank).
 
-Argument 'refresh' gives the compositor's prediction of how
+The 'refresh' argument gives the compositor's prediction of how
 many nanoseconds after tv_sec, tv_nsec the very next output
 refresh may occur. This is to further aid clients in
 predicting future refreshes, i.e., estimating the timestamps
-- 
2.7.3

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

[PATCH wayland-protocols 4/4] stable/presentation-time: rephrase request intro

[Pekka Paalanen]

From: Pekka Paalanen 

Attempting to clarify the paragraph. The key points are that feedback is
double-buffered, part of a commit as all double-buffered state is, and
it defines the term "content update" used later.

The new phrasing defines not only a content update, but also content
submission which is used further on in the spec. It implies the
double-buffered state semantics without actually using the term (it's
not really state to be applied), and makes a link with the very next
paragraph describing the prensentation time.

Signed-off-by: Pekka Paalanen 
---
 stable/presentation-time/presentation-time.xml | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/stable/presentation-time/presentation-time.xml 
b/stable/presentation-time/presentation-time.xml
index 4d164c1..62ae7be 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -36,11 +36,10 @@
   presentation clock, which is defined in the
   presentation.clock_id event.
 
-  Request 'feedback' can be regarded as an additional wl_surface
-  method. It is part of the double-buffered surface state update
-  mechanism, where other requests first set up the state and then
-  wl_surface.commit atomically applies the state into use. In
-  other words, wl_surface.commit submits a content update.
+  A content update for a wl_surface is submitted by a
+  wl_surface.commit request. Request 'feedback' associates with
+  the wl_surface.commit and provides feedback on the content
+  update, particularly the final realized presentation time.
 
 
 
-- 
2.7.3

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

[PATCH wayland-protocols 3/4] stable/presentation-time: reorganize clock_id documentation

[Pekka Paalanen]

From: Pekka Paalanen 

Move compositor implementors' guidelines to the end. Recombine the
affected paragraphs.

No changes to the wording are made.

Suggested-by: Bryce Harrington 
Signed-off-by: Pekka Paalanen 
---
 stable/presentation-time/presentation-time.xml | 22 ++
 1 file changed, 10 insertions(+), 12 deletions(-)

diff --git a/stable/presentation-time/presentation-time.xml 
b/stable/presentation-time/presentation-time.xml
index ad2d132..4d164c1 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -99,18 +99,10 @@
 presentation interface. The presentation clock does not change
 during the lifetime of the client connection.
 
-The clock identifier is platform dependent. Clients must be
-able to query the current clock value directly, not by asking
-the compositor.
-
-On Linux/glibc, the identifier value is one of the clockid_t
-values accepted by clock_gettime(). clock_gettime() is defined
-by POSIX.1-2001.
-
-Compositors should prefer a clock which does not jump and is
-not slewed e.g. by NTP. The absolute value of the clock is
-irrelevant. Precision of one millisecond or better is
-recommended.
+The clock identifier is platform dependent. On Linux/glibc,
+the identifier value is one of the clockid_t values accepted
+by clock_gettime(). clock_gettime() is defined by
+POSIX.1-2001.
 
 Timestamps in this clock domain are expressed as tv_sec_hi,
 tv_sec_lo, tv_nsec triples, each component being an unsigned
@@ -122,6 +114,12 @@
 Note that clock_id applies only to the presentation clock,
 and implies nothing about e.g. the timestamps used in the
 Wayland core protocol input events.
+
+Compositors should prefer a clock which does not jump and is
+not slewed e.g. by NTP. The absolute value of the clock is
+irrelevant. Precision of one millisecond or better is
+recommended. Clients must be able to query the current clock
+value directly, not by asking the compositor.
   
 
   
-- 
2.7.3

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

[PATCH wayland-protocols 1/4] stable/presentation-time: swap two paragraphs in 'presented'

[Pekka Paalanen]

From: Pekka Paalanen 

Associates better with the surrounding paragraphs by not jumping topics
back and forth.

Suggested-by: Bill Spitzak 
Signed-off-by: Pekka Paalanen 
---
 stable/presentation-time/presentation-time.xml | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/stable/presentation-time/presentation-time.xml 
b/stable/presentation-time/presentation-time.xml
index dc4ae68..6c3fff8 100644
--- a/stable/presentation-time/presentation-time.xml
+++ b/stable/presentation-time/presentation-time.xml
@@ -232,6 +232,10 @@
 targeting the next few vblanks. If such prediction cannot
 usefully be done, the argument is zero.
 
+If the output does not have a constant refresh rate, explicit
+video mode switches excluded, then the refresh argument must
+be zero.
+
 The 64-bit value combined from seq_hi and seq_lo is the value
 of the output's vertical retrace counter when the content
 update was first scanned out to the display. This value must
@@ -240,10 +244,6 @@
 path has a non-zero latency, the time instant specified by
 this counter may differ from the timestamp's.
 
-If the output does not have a constant refresh rate, explicit
-video mode switches excluded, then the refresh argument must
-be zero.
-
 If the output does not have a concept of vertical retrace or a
 refresh cycle, or the output device is self-refreshing without
 a way to query the refresh count, then the arguments seq_hi
-- 
2.7.3

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

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Olivier Fourdan]

Hi Bill,

> 
> > > It allows a client to say "I look best below this size, but if the
> > > compositor wants to fill a larger rectangle, I can draw something nicer
> > > than the compositor can do (the compositor can only pad or scale)".
> >
> > That's something different, isn't it? The compositor sending a configure
> > event and the size specified there must be obeyed by the client (as
> > specified in the spec for maximize and fullscreen state, but the point of
> > using min/max is precisely to let the compositor know that such states are
> > not desirable for that given surface).
> 
> Clients do not have to obey the requested size by the compositor.

The spec reads, for state maximized and fullscreen:


  
  [...]
  

  The surface is maximized. The window geometry specified in the 
configure
  event must be obeyed by the client.

  
  

  The surface is fullscreen. The window geometry specified in the 
configure
  event must be obeyed by the client.

  
  [...]


That's 
https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n343
 
> This is
> how min/max size was being done previously, and how size increments and
> aspect ratios and any other client restrictions on possible size are still
> being done now.

I know. So either the description above is incorrect, or I don't understand 
what "must be obeyed" means in this context.

BTW, that's precisely the patches I wrote for gtk+ for fullscreen and 
maximized, ignore the size increments and now max size when receiving a 
configure event with state maximized or fullscreen.

For reference, that was:

https://bugzilla.gnome.org/show_bug.cgi?id=751368

and now

https://bugzilla.gnome.org/show_bug.cgi?id=764413

> I don't think clients should have to obey fullscreen either, though I'm not
> sure what the documentation says. The compositor can just center the
> surface above black if the client does not resize it, this functionality is
> already supported.

Correct, for fullscreen, this is the case, this is where I think the spec gets 
a tad confusing imho:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n508


  
Make the surface fullscreen.

You can specify an output that you would prefer to be fullscreen.
If this value is NULL, it's up to the compositor to choose which
display will be used to map this surface.

If the surface doesn't cover the whole output, the compositor will
position the surface in the center of the output and compensate with
black borders filling the rest of the output.
  
  


So the client must obey the window geometry specified in the configure event 
when the state is fullscreen, but the surface may not cover the whole output.

> [...]
> 
> > My point was more about the client itself setting min/max and then setting
> > a geometry that falls outside of the limits it sets itself, I reckon that
> > should be a protocol error, the client is sending incompatible requests to
> > the compositor.
> 
> 
> No this absolutely must not be a protocol error.
> 
> *maybe* it could be a protocol error to resize larger than the maximum of
> the current maximum size and the configure request that it is responding
> to, but this is going to lead to synchronization issues since there is no
> serial number indicating the configure request it is processing. And it may
> even have to add a good deal of fudge factor so a client can continue to
> round to size increments. So even this idea looks very difficult and
> pointless to handle.

Yes, I agree, the client can set a geometry following a configure request, and 
that must respect the window geometry specified by the states in the configure 
events, which must be obeyed:

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n450


  
The window geometry of a window is its "visible bounds" from the
user's perspective. Client-side decorations often have invisible
portions like drop-shadows which should be ignored for the
purposes of aligning, placing and constraining windows.

[...]

If responding to a configure event, the window geometry in here
must respect the sizing negotiations specified by the states in
the configure event.

[...]
  

So I think we should clarify the "must be obeyed" part of the configure event 
when state is maximized or fullscreen.

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