[PATCH wayland-protocols v2 5/7] xdg-shell: Make get_popup take a xdg_surface instead of wl_surface

[Jonas Ådahl]

The reason for using wl_surface before was that xdg_popup and
xdg_surface (now xdg_toplevel) had no common interface other than
wl_surface, but since xdg_surface is now the base interface, lets use
that.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Mike Blumenkrantz 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index d539c1f..90cf7c2 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -165,7 +165,7 @@
xdg_popup is and how it is used.
   
   
-  
+  
   
   
   
-- 
2.5.5

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

[PATCH wayland-protocols v2 1/7] xdg-shell: Turn xdg_surface into a generic base interface

[Jonas Ådahl]

Split out toplevel window like requests and events into a new interface
called xdg_toplevel, and turn xdg_surface into a generic base interface
which others extends.

xdg_popup is changed to extend the xdg_surface.

The configure event in xdg_surface was split up making
xdg_surface.configure an event only carrying the serial number, while a
new xdg_toplevel.configure event carries the other data previously sent
via xdg_surface.configure. xdg_toplevel.configure is made to extend,
via the latch-state mechanism, xdg_surface.configure and depends on
that event to synchronize state.

Other future xdg_surface based extensions are meant to also extend
xdg_surface.configure for relevant window type dependend state
synchronization.

Signed-off-by: Jonas Ådahl 
Signed-off-by: Mike Blumenkrantz 
---

Changes since v1:

 - moved xdg_surface based role semantics into xdg_surface
 - reworded xdg_toplevel description a bit
 - various minor doc changes


Jonas


 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 271 ---
 1 file changed, 161 insertions(+), 110 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index ce57153..4080119 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -54,11 +54,9 @@
 
 
   
-   This creates an xdg_surface for the given surface and gives it the
-   xdg_surface role. A wl_surface can only be given an xdg_surface role
-   once. If get_xdg_surface is called with a wl_surface that already has
-   an active xdg_surface associated with it, or if it had any other role,
-   an error is raised.
+   This creates an xdg_surface for the given surface. While xdg_surface
+   itself is not a role, the corresponding surface may only be assigned
+   a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
 
See the documentation of xdg_surface for more details about what an
xdg_surface is and how it is used.
@@ -67,29 +65,6 @@
   
 
 
-
-  
-   This creates an xdg_popup for the given surface and gives it the
-   xdg_popup role. A wl_surface can only be given an xdg_popup role
-   once. If get_xdg_popup is called with a wl_surface that already has
-   an active xdg_popup associated with it, or if it had any other role,
-   an error is raised.
-
-   This request must be used in response to some sort of user action
-   like a button press, key press, or touch down event.
-
-   See the documentation of xdg_popup for more details about what an
-   xdg_popup is and how it is used.
-  
-  
-  
-  
-  
-  
-  
-  
-
-
 
   
The ping event asks the client if it's still alive. Pass the
@@ -117,13 +92,23 @@
   
 
   
-
+
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
 
-  It provides requests to treat surfaces like windows, allowing to set
-  properties like maximized, fullscreen, minimized, and to move and resize
-  them, and associate metadata like title and app id.
+  It provides a base set of functionality required to construct user
+  interface elements requiring management by the compositor, such as
+  toplevel windows, menus, etc. The types of functionality are split into
+  xdg_surface roles.
+
+  Creating an xdg_surface does not set the role for a wl_surface. In order
+  to map an xdg_surface, create a role-specific object using, e.g.,
+  get_toplevel, get_popup. The wl_surface for any given xdg_surface can
+  have at most one role, and may not be assigned any role not based on
+  xdg_surface.
+
+  A role must be assigned before any other requests are made to the
+  xdg_surface object.
 
   The client must call wl_surface.commit on the corresponding wl_surface
   for the xdg_surface state to take effect.
@@ -133,12 +118,142 @@
   manipulate a buffer prior to the first xdg_surface.configure call must
   also be treated as errors.
 
-  For a surface to be mapped by the compositor the client must have
-  committed both an xdg_surface state and a buffer.
+  For a surface to be mapped by the compositor the client must have 
assigned
+  one of the xdg_surface based roles, it must have committed both the
+  xdg_surface state and the role dependent state, and it must have 
committed
+  a buffer.
 
 
+
+  
+  
+
+
 
-  
+  
+   Destroy the xdg_surface object. An xdg_surface must only be destroyed
+   after its role object has been destroyed
+  
+
+
+
+  
+   This creates an xdg_toplevel object for the given xdg_surface and gives
+   the associated wl_surface the xdg_toplevel role.
+
+   See the documentation of 

[PATCH wayland-protocols v2 7/7] xdg-shell: Introduce xdg_positioner

[Jonas Ådahl]

xdg_positioner is a method for declarative positioning of child surfaces
(currently only xdg_popup surfaces). A client creates a description of a
positioning logic using the xdg_positioner interface. The xdg_positioner
object is then used when creating a xdg_popup for describing how the
child surface should be positioned in relation to the parent surface.

Signed-off-by: Jonas Ådahl 
Signed-off-by: Mike Blumenkrantz 
---

Changes since v1:

 - Clarify that the rules of xdg_positioner is copied when used, and itself
   doesn't get "attached" to any surface.
 - Make it clear errors are raised on invalid input and when used incorrectly
 - Added xdg_positioner.set_size, in order to not relying on a possibly
   incorrect xdg_surface.set_window_geometry.
 - Added the concept of a "complete" positioner, i.e. one with a set size and
   anchor rect.
 - Fixed bitfield enum field.
 - Made the slide_x/y semantics less undefined.


Jonas

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 248 ++-
 1 file changed, 246 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 2edc341..dfd7e84 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -45,6 +45,8 @@
 summary="the client specified an invalid popup parent surface"/>
   
+  
 
 
 
@@ -57,6 +59,15 @@
   
 
 
+
+  
+   Create a positioner object. A positioner object is used to position
+   surfaces relative to some parent surface. See the interface description
+   and xdg_surface.get_popup for details.
+  
+  
+
+
 
   
This creates an xdg_surface for the given surface. While xdg_surface
@@ -96,6 +107,223 @@
 
   
 
+  
+
+  The xdg_positioner provides an interface for constructing positioning
+  rules used for positioning a child surface relative to another surface
+  in a certain way. It allows methods for defining a rule that will make
+  the child surface stay within the border of the visible area of the
+  screen, with different ways in which the child surface should change
+  its position, including sliding along an axis, or flipping around a
+  rectangle.
+
+  See the various requests for details about possible rules.
+
+  Semantically, an xdg_positioner is a collection of positioning rules. 
When
+  used for positioning a surface, for example when passed as an argument to
+  xdg_surface.get_popup, the compositor copies the rules that were set up 
at
+  the time of the request. Making any changes or destroying the object 
after
+  it was used has no effect on previous usages.
+
+  For a xdg_positioner object to be considered complete, it must have a
+  non-zero size set by set_size, and a non-zero anchor rectangle set by
+  set_anchor_rect. Passing an incomplete xdg_positioner object when
+  positioning a surface raises an error.
+
+
+
+  
+
+
+
+  
+   Notify the compositor that the xdg_positioner will no longer be used.
+  
+
+
+
+  
+   Set the size of the surface that is to be positioned with the positioner
+   object. The size is in surface-local coordinates and corresponds to the
+   window geometry width. See xdg_surface.set_window_geometry.
+
+   If a zero or negative size is set the invalid_input error is raised.
+  
+  
+  
+
+
+
+  
+   Specify the anchor rectangle within the parent surface that the child
+   surface will be placed relative to. The rectangle is relative to the
+   window geometry as defined by xdg_surface.set_window_geometry of the
+   parent surface. The rectangle must be at least 1x1 large.
+
+   When the xdg_positioner object is used to position a child surface, the
+   anchor rectangle may not extend outside the window geometry of the
+   positioned child's parent surface.
+
+   If a zero or negative size is set the invalid_input error is raised.
+  
+  
+  
+  
+  
+
+
+
+  
+  
+  
+  
+  
+
+
+
+  
+   Set the anchor edges of the anchor rectangle. The anchor edges define
+   where on the anchor rectangle the child surface should be positioned
+   relative to. An anchor is a bit mask of up to two values of the anchor
+   enum.
+
+   If two values on the same axis (for example left and right) is set the
+   invalid_input error is raised.
+
+   If no anchor is set on any axis, the anchor position will be positioned
+   at the center of the anchor rectangle on the unset axis. The default
+   value is "none".
+  
+  
+
+
+
+  
+  
+  
+  
+  
+
+
+
+  
+   The gravity defines in what direction a surface would be 

[PATCH wayland-protocols v2 4/7] xdg-shell: Improve error enum formatting some

[Jonas Ådahl]

The long lines stood out, break them by putting the summary on its own
line.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Yong Bakos 
Reviewed-by: Mike Blumenkrantz 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 0d31ca5..d539c1f 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -37,10 +37,14 @@
 
 
   
-  
-  
-  
-  
+  
+  
+  
+  
 
 
 
-- 
2.5.5

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

[PATCH wayland-protocols v2 3/7] xdg-shell: Add error codes for invalid surface state

[Jonas Ådahl]

Signed-off-by: Jonas Ådahl 
Reviewed-by: Mike Blumenkrantz 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 2a30af5..0d31ca5 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -40,6 +40,7 @@
   
   
   
+  
 
 
 
@@ -127,6 +128,7 @@
 
   
   
+  
 
 
 
-- 
2.5.5

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

[PATCH wayland-protocols v2 2/7] xdg-shell: Put xdg_shell events after requests

[Jonas Ådahl]

It makes the structure consistent with most other protocols and
provides a clear separation between what is done by the server and what
is done by the client.

Signed-off-by: Jonas Ådahl 
Reviewed-by: Yong Bakos 
Reviewed-by: Mike Blumenkrantz 
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74 ++--
 1 file changed, 37 insertions(+), 37 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 4080119..2a30af5 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -65,6 +65,14 @@
   
 
 
+
+  
+   A client must respond to a ping event with a pong request or
+   the client may be deemed unresponsive.
+  
+  
+
+
 
   
The ping event asks the client if it's still alive. Pass the
@@ -81,14 +89,6 @@
   
   
 
-
-
-  
-   A client must respond to a ping event with a pong request or
-   the client may be deemed unresponsive.
-  
-  
-
   
 
   
@@ -461,35 +461,6 @@
   
 
 
-
-  
-   This configure event asks the client to resize its toplevel surface or
-   to change its state. It is not sent by itself but as a latched state
-   sent prior to the xdg_surface.configure event. See xdg_surface.configure
-   for details.
-
-   The width and height arguments specify a hint to the window
-   about how its surface should be resized in window geometry
-   coordinates. See set_window_geometry.
-
-   If the width or height arguments are zero, it means the client
-   should decide its own window dimension. This may happen when the
-   compositor need to configure the state of the surface but doesn't
-   have any information about any previous or expected dimension.
-
-   The states listed in the event specify how the width/height
-   arguments should be interpreted, and possibly how it should be
-   drawn.
-
-   Clients must send an ack_configure in response to this. See
-   xdg_surface.configure and xdg_surface.ack_configure for details.
-  
-
-  
-  
-  
-
-
 
   
Set a maximum size for the window.
@@ -644,6 +615,35 @@
   
 
 
+
+  
+   This configure event asks the client to resize its toplevel surface or
+   to change its state. It is not sent by itself but as a latched state
+   sent prior to the xdg_surface.configure event. See xdg_surface.configure
+   for details.
+
+   The width and height arguments specify a hint to the window
+   about how its surface should be resized in window geometry
+   coordinates. See set_window_geometry.
+
+   If the width or height arguments are zero, it means the client
+   should decide its own window dimension. This may happen when the
+   compositor need to configure the state of the surface but doesn't
+   have any information about any previous or expected dimension.
+
+   The states listed in the event specify how the width/height
+   arguments should be interpreted, and possibly how it should be
+   drawn.
+
+   Clients must send an ack_configure in response to this. See
+   xdg_surface.configure and xdg_surface.ack_configure for details.
+  
+
+  
+  
+  
+
+
 
   
The close event is sent by the compositor when the user
-- 
2.5.5

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

[PATCH wayland-protocols v2 6/7] xdg-shell: Make xdg_popup non-grabbing by default

[Jonas Ådahl]

Turn xdg_popup into plain temporary child surfaces without any grabbing
or mapping order requirements by default.

In order to create grabbing popup chains, a new request 'grab' is
introduced which enables more or less the same semantics and
requirements as xdg_popup previously had related to grabbing, stacking
and mapping order.

This enables using xdg_popup for creating tooltips and other user
interface elements that does not want to take an explicit grab.

Signed-off-by: Jonas Ådahl 
Signed-off-by: Mike Blumenkrantz 
---

Changes since v1:

 - various grammatical fixes


Jonas

 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 110 +--
 1 file changed, 68 insertions(+), 42 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 90cf7c2..2edc341 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -158,16 +158,11 @@
This creates an xdg_popup object for the given xdg_surface and gives the
associated wl_surface the xdg_popup role.
 
-   This request must be used in response to some sort of user action like a
-   button press, key press, or touch down event.
-
See the documentation of xdg_popup for more details about what an
xdg_popup is and how it is used.
   
   
   
-  
-  
   
   
 
@@ -666,46 +661,30 @@
 
   
 
-  A popup surface is a short-lived, temporary surface that can be
-  used to implement menus. It takes an explicit grab on the surface
-  that will be dismissed when the user dismisses the popup. This can
-  be done by the user clicking outside the surface, using the keyboard,
-  or even locking the screen through closing the lid or a timeout.
-
-  When the popup is dismissed, a popup_done event will be sent out,
-  and at the same time the surface will be unmapped. The xdg_popup
-  object is now inert and cannot be reactivated, so clients should
-  destroy it. Explicitly destroying the xdg_popup object will also
-  dismiss the popup and unmap the surface.
-
-  Clients will receive events for all their surfaces during this
-  grab (which is an "owner-events" grab in X11 parlance). This is
-  done so that users can navigate through submenus and other
-  "nested" popup windows without having to dismiss the topmost
-  popup.
-
-  Clients that want to dismiss the popup when another surface of
-  their own is clicked should dismiss the popup using the destroy
+  A popup surface is a short-lived, temporary surface. It can be used to
+  implement for example menus, popovers, tooltips and other similar user
+  interface concepts.
+
+  A popup can be made to take an explicit grab. See xdg_popup.grab for
+  details.
+
+  When the popup is dismissed, a popup_done event will be sent out, and at
+  the same time the surface will be unmapped. See the xdg_popup.popup_done
+  event for details.
+
+  Explicitly destroying the xdg_popup object will also dismiss the popup 
and
+  unmap the surface. Clients that want to dismiss the popup when another
+  surface of their own is clicked should dismiss the popup using the 
destroy
   request.
 
   The parent surface must have either the xdg_toplevel or xdg_popup surface
   role.
 
-  Specifying an xdg_popup for the parent means that the popups are
-  nested, with this popup now being the topmost popup. Nested
-  popups must be destroyed in the reverse order they were created
-  in, e.g. the only popup you are allowed to destroy at all times
-  is the topmost one.
-
-  If there is an existing popup when creating a new popup, the
-  parent must be the current topmost popup.
-
-  A parent surface must be mapped before the new popup is mapped.
+  A newly created xdg_popup will be stacked on top of all previously 
created
+  xdg_popup surfaces associated with the same xdg_toplevel.
 
-  When compositors choose to dismiss a popup, they will likely
-  dismiss every nested popup as well. When a compositor dismisses
-  popups, it will follow the same dismissing order as required
-  from the client.
+  The parent of an xdg_popup must be mapped (see the xdg_surface
+  description) before the xdg_popup itself.
 
   The x and y arguments passed when creating the popup object specify
   where the top left of the popup should be placed, relative to the
@@ -714,9 +693,6 @@
 
   The client must call wl_surface.commit on the corresponding wl_surface
   for the xdg_popup state to take effect.
-
-  For a surface to be mapped by the compositor the client must have
-  committed both the xdg_popup state and a buffer.
 
 
 
@@ -729,6 +705,56 @@
   
 
 
+
+  
+   This request makes the created 

[PATCH wayland-protocols 1/4] tablet: add v2 of the tablet protocol

[Peter Hutterer]

This is a straightforward copy/paste with a _v1 -> _v2 rename. No functional
changes otherwise.

Signed-off-by: Peter Hutterer 
---
 Makefile.am|   1 +
 unstable/tablet/tablet-unstable-v2.xml | 641 +
 2 files changed, 642 insertions(+)
 create mode 100644 unstable/tablet/tablet-unstable-v2.xml

diff --git a/Makefile.am b/Makefile.am
index 71d2632..9e2a029 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -8,6 +8,7 @@ unstable_protocols =
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
\
unstable/tablet/tablet-unstable-v1.xml  
\
+   unstable/tablet/tablet-unstable-v2.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
new file mode 100644
index 000..81e9835
--- /dev/null
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -0,0 +1,641 @@
+
+
+
+  
+Copyright 2014 © Stephen "Lyude" Chandler Paul
+Copyright 2015-2016 © Red Hat, Inc.
+
+Permission is hereby granted, free of charge, to any person
+obtaining a copy of this software and associated documentation files
+(the "Software"), to deal in the Software without restriction,
+including without limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of the Software,
+and to permit persons to whom the Software is furnished to do so,
+subject to the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+  
+
+  
+This description provides a high-level overview of the interplay between
+the interfaces defined this protocol. For details, see the protocol
+specification.
+
+More than one tablet may exist, and device-specifics matter. Tablets are
+not represented by a single virtual device like wl_pointer. A client
+binds to the tablet manager object which is just a proxy object. From
+that, the client requests wp_tablet_manager.get_tablet_seat(wl_seat)
+and that returns the actual interface that has all the tablets. With
+this indirection, we can avoid merging wp_tablet into the actual Wayland
+protocol, a long-term benefit.
+
+The wp_tablet_seat sends a "tablet added" event for each tablet
+connected. That event is followed by descriptive events about the
+hardware; currently that includes events for name, vid/pid and
+a wp_tablet.path event that describes a local path. This path can be
+used to uniquely identify a tablet or get more information through
+libwacom. Emulated or nested tablets can skip any of those, e.g. a
+virtual tablet may not have a vid/pid. The sequence of descriptive
+events is terminated by a wp_tablet.done event to signal that a client
+may now finalize any initialization for that tablet.
+
+Events from tablets require a tool in proximity. Tools are also managed
+by the tablet seat; a "tool added" event is sent whenever a tool is new
+to the compositor. That event is followed by a number of descriptive
+events about the hardware; currently that includes capabilities,
+hardware id and serial number, and tool type. Similar to the tablet
+interface, a wp_tablet_tool.done event is sent to terminate that initial
+sequence.
+
+Any event from a tool happens on the wp_tablet_tool interface. When the
+tool gets into proximity of the tablet, a proximity_in event is sent on
+the wp_tablet_tool interface, listing the tablet and the surface. That
+event is followed by a motion event with the coordinates. After that,
+it's the usual motion, axis, button, etc. events. The protocol's
+serialisation means events are grouped by wp_tablet_tool.frame events.
+
+Two special events (that don't exist in X) are down and up. They signal
+"tip touching the surface". For tablets without real proximity
+detection, the sequence is: proximity_in, motion, down, frame.
+
+When the tool leaves proximity, a proximity_out event is sent. If 

[PATCH v3 wayland-protocols 4/4] tablet: Add pad support to the tablet protocol

[Peter Hutterer]

From: Carlos Garnacho 

The pad's interface is similar to the tool interface, a client is notified of
the pad after the tablet_added event.

The pad has three functionalities: buttons, rings and strips.
Buttons are fairly straightforward, rings and strips are separate interfaces
with a pointer-axis-like source/value/frame events.
The two interfaces are effectively identical but for the actual value they
send (degrees vs normalized position).

Buttons are sequentially indexed starting with zero, unlike other protocols
where a linux/input.h-style semantic event code is used. Since we expect all
buttons to have client-specific functionality, an additional event tells the
client when a given button index is not available, usually because the
compositor assignes some function to it (e.g. mode switching, see below).

Specific to the pad device is the set_feedback request which enables a client
to set a user-defined string to display for an OSD on the current mappings.
This request is available for buttons, rings and strips.

Finally, the pad supports "modes", effectively sets of button/ring/strip
configurations.

Signed-off-by: Carlos Garnacho 
Signed-off-by: Peter Hutterer 
---
Changes to v2:
- change to v2 of the protocol
- various comments and suggestions for improved wording incorporated
- ring is in wl_fixed degrees now (was int, in 0.01 of a degree)
- button events changed to sequential indices
- new buttons_reserved event

 unstable/tablet/tablet-unstable-v2.xml | 436 +
 1 file changed, 436 insertions(+)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index d3f57ff..388b4d2 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -172,6 +172,22 @@
   
   
 
+
+
+  
+   This event is sent whenever a new pad is known to the system. Typically,
+   pads are physically attached to tablets and a pad_added event is
+   sent immediately after the wp_tablet_seat.tablet_added.
+   However, some standalone pad devices logically attach to tablets at
+   runtime, and the client must wait for wp_tablet_pad.enter to know
+   the tablet a pad is attached to.
+
+   This event only provides the object id of the pad; and all further
+   features (buttons, strips, rings) are sent through the wp_tablet_pad
+   interface.
+  
+  
+
   
 
   
@@ -636,4 +652,424 @@
 
   
 
+  
+
+  A circular interaction area.
+
+  Events on a ring are logically grouped by the wl_tablet_pad_ring.frame
+  event.
+
+
+
+  
+   Request that the compositor use the provided feedback string
+   associated with this ring. This request should be issued immediately
+   after a wp_tablet_pad.enter, or whenever the ring is mapped to a
+   different action.
+
+   Clients are encouraged to provide context-aware descriptions for
+   the actions associated with the ring; compositors may use this
+   information to offer visual feedback about the button layout
+   (eg. on-screen displays).
+
+   The provided string 'description' is an UTF-8 encoded string to be
+   associated with this ring, and is considered user visible; general
+   internationalization rules apply.
+  
+  
+
+
+
+  
+   This destroys the client's resource for this ring object.
+  
+
+
+
+  
+   Describes the source types for ring events. This indicates to the
+   client how a ring event was physically generated; a client may
+   adjust the user interface accordingly. For example, events
+   from a "finger" source may trigger kinetic scrolling.
+  
+  
+
+
+
+  
+   Source information for ring events.
+
+   This event does not occur on its own. It is sent before a
+   wp_tablet_pad_ring.frame event and carries the source information
+   for all events within that frame.
+
+   The source specifies how this event was generated. If the source is
+   wp_tablet_pad_ring.source.finger, a wp_tablet_pad_ring.stop event
+   will be sent when the user lifts the finger off the device.
+
+   This event is optional. If the source is unknown for an interaction,
+   no event is sent.
+  
+  
+
+
+
+  
+   Sent whenever the angle on a ring changes.
+
+   The angle is provided in degrees clockwise from the logical
+   north of the ring in the pad's current rotation.
+  
+  
+
+
+
+  
+   Stop notification for ring events.
+
+   For some wp_tablet_pad_ring.source types, a wp_tablet_pad_ring.stop
+   event is sent to notify a client that the interaction with the ring
+   has terminated.
+   This enables the client to implement kinetic scrolling.
+   See the wp_tablet_pad_ring.source documentation for 

[PATCH wayland-protocols 2/4] tablet: change all degree values from int to wl_fixed

[Peter Hutterer]

Signed-off-by: Peter Hutterer 
---
 unstable/tablet/tablet-unstable-v2.xml | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 81e9835..e7b8626 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -478,21 +478,21 @@
 
   
Sent whenever one or both of the tilt axes on a tool change. Each tilt
-   value is in 0.01 of a degree, relative to the z-axis of the tablet.
+   value is in degrees, relative to the z-axis of the tablet.
The angle is positive when the top of a tool tilts along the
positive x or y axis.
   
-  
-  
+  
+  
 
 
 
   
Sent whenever the z-rotation axis on the tool changes. The
-   rotation value is in 0.01 of a degree clockwise from the tool's
+   rotation value is in degrees clockwise from the tool's
logical neutral position.
   
-  
+  
 
 
 
@@ -510,10 +510,10 @@
   
Sent whenever the wheel on the tool emits an event. This event
contains two values for the same axis change. The degrees value is
-   in 0.01 of a degree in the same orientation as the
-   wl_pointer.vertical_scroll axis. The clicks value is in discrete
-   logical clicks of the mouse wheel. This value may be zero if the
-   movement of the wheel was less than one logical click.
+   in degrees in the same orientation as the wl_pointer.vertical_scroll
+   axis. The clicks value is in discrete logical clicks of the mouse
+   wheel. This value may be zero if the movement of the wheel was less
+   than one logical click.
 
Clients should choose either value and avoid mixing degrees and
clicks. The compositor may accumulate values smaller than a logical
@@ -521,7 +521,7 @@
Thus, wl_tablet_tool.wheel events with non-zero clicks values may
have different degrees values.
   
-  
+  
   
 
 
-- 
2.7.4

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

[PATCH wayland-protocols 0/4] tablet: switch to v2, add tablet pad

[Peter Hutterer]

The switch to v2 is needed primarily for the ABI break when we go from ints
to fixed for any rotational values. Patch 3/4 restricts the role a surface
can play when assigned as tool cursor, specifically we now only allow a
cursor surface to be assigned to one tool rather than shared across
multiple. This is slightly more work in the client but better defined and
managable in the compositor. See the patch for a detailed explanation.

The last patch adds the pad interface, mostly the same as last time but
rebased onto v2 and with a couple of small additions.

Cheers,
  Peter

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

[PATCH wayland-protocols 3/4] tablet: restrict the cursor surface to one per tool

[Peter Hutterer]

The initial approach was to allow one surface to be re-used between tools,
seats and even used together as wl_pointer cursor surface. This has a few
drawbacks, most of which are related to managing the surface correctly in the
compositor. For example, the same cursor surface could have two different
hotspots. Animated cursors should animate independently rather than update at
the same time.

Furthermore: a client cannot know when a surface will cease being used as a
cursor surface. The basic assumption of "after focus out" is an implementation
detail in the compositor and unless the client unsets the cursor it is not
guaranteed that the surface is released. This again makes sharing a surface
less obvious - you cannot know if the wl_pointer surface is still in use when
you set it for a new wp_tablet_tool.

Avoid these headaches (and push some of them to the clientl) by simply
restricting a wl_surface to be assigned to a single tool. For the 99% use case
where we have one tablet with two tools (pen + eraser) this means we merely
get two extra surfaces, and the two don't usually share the same cursor shape
anyway. If sharing is absolutely, a client may still opt to share the
underlying wl_buffer.

Signed-off-by: Peter Hutterer 
---
 unstable/tablet/tablet-unstable-v2.xml | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index e7b8626..d3f57ff 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -225,13 +225,11 @@
and pending input regions become undefined, and the wl_surface is
unmapped.
 
-   This request gives the surface the role of a cursor. The role
-   assigned by this request is the same as assigned by
-   wl_pointer.set_cursor meaning the same surface can be
-   used both as a wl_pointer cursor and a wp_tablet cursor. If the
-   surface already has another role, it raises a protocol error.
-   The surface may be used on multiple tablets and across multiple
-   seats.
+   This request gives the surface the role of a wp_tablet_tool cursor. A
+   surface may only ever be used as cursor surface for one
+   wp_tablet_tool. If the surface already has another role or has
+   previously been used as cursor surface for a different tool, a
+   protocol error is raised.
   
   
   
-- 
2.7.4

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

Re: [PATCH v2 wayland-protocols] Add pad support to the tablet protocol

[Peter Hutterer]

On Fri, Apr 22, 2016 at 10:05:11AM -0700, Bill Spitzak wrote:
> Considering that the compositor is not doing anything about telling the
> client whether it is using some keyboard keys, I just don't see the need to
> tell it what button pad items it is eating. If this is a problem that needs
> solving it should be solved for all input devices.

tablets are different to keyboards, so we handle them differently. clients
generally don't need to care about whether a specific key code is discarded.
Two main reasons for this:
1) keys have semantic meaning, so a client already knows ahead of time
whether it needs to care about a key. and because of the semantic meaning,
compositors also generally know which keys to handle and discard.
2) some conventions effectively prohibit clients from using reserved keys,
e.g. no client uses Alt-Tab for internal functionality

neither of these reasons are true for tablet pads. Buttons have no semantic
functionality until one has been assigned. And the main purpose of button
pads is to map to custom client-specific functionalities, e.g. button 2 may
be mapped to "select pencil tool" in gimp but "undo" in inkscape. Because of
this, clients need to know whether they can rely on a button event to
arrive, because asking a user to configure a button when the compositor uses
that button for mode switching is bad UI.

Cheers,
   Peter
 
> On Fri, Apr 22, 2016 at 3:30 AM, Carlos Garnacho  wrote:
> 
> > Hi!,
> >
> > On Fri, Apr 22, 2016 at 4:02 AM, Peter Hutterer
> >  wrote:
> > > On Thu, Apr 21, 2016 at 05:46:24PM -0700, Jason Gerecke wrote:
> > >> On Mon, Apr 18, 2016 at 10:00 PM, Peter Hutterer
> > >>  wrote:
> > >> > From: Carlos Garnacho 
> > >> >
> > >> > The pad's interface is similar to the tool interface, a client is
> > notified of
> > >> > the pad after the tablet_added event.
> > >> >
> > >> > The pad has three functionalities: buttons, rings and strips.
> > >> > Buttons are fairly straightforward, rings and strips are separate
> > interfaces
> > >> > with a pointer-axis-like source/value/frame events.
> > >> > The two interfaces are effectively identical but for the actual value
> > they
> > >> > send (degrees vs normalized position).
> > >> >
> > >> > Specific to the pad device is the set_feedback request which enables
> > a client
> > >> > to set a user-defined string to display for an OSD on the current
> > mappings.
> > >> > This request is available for buttons, rings and strips.
> > >> >
> > >> > Finally, the pad supports "modes", effectively sets of
> > button/ring/strip
> > >> > configurations.
> > >> >
> > >> > Signed-off-by: Carlos Garnacho 
> > >> > Signed-off-by: Peter Hutterer 
> > >> > ---
> > >> > Changes to v1:
> > >> > - typos fixed
> > >> >
> > >> >  unstable/tablet/tablet-unstable-v1.xml | 423
> > -
> > >> >  1 file changed, 421 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/unstable/tablet/tablet-unstable-v1.xml
> > b/unstable/tablet/tablet-unstable-v1.xml
> > >> > index 907126c..36b9ae8 100644
> > >> > --- a/unstable/tablet/tablet-unstable-v1.xml
> > >> > +++ b/unstable/tablet/tablet-unstable-v1.xml
> > >> > @@ -115,7 +115,7 @@
> > >> >  interface version number is reset.
> > >> >
> > >> >
> > >> > -  
> > >> > +  
> > >> >  
> > >> >An object that provides access to the graphics tablets
> > available on this
> > >> >system. All tablets are associated with a seat, to get access
> > to the
> > >> > @@ -139,7 +139,7 @@
> > >> >  
> > >> >
> > >> >
> > >> > -  
> > >> > +  
> > >> >  
> > >> >An object that provides access to the graphics tablets
> > available on this
> > >> >seat. After binding to this interface, the compositor sends a
> > set of
> > >> > @@ -172,6 +172,23 @@
> > >> >
> > >> > > summary="the newly added tablet tool"/>
> > >> >  
> > >> > +
> > >> > +
> > >> > +
> > >> > +
> > >> > +  
> > >> > +   This event is sent whenever a new pad is known to the system.
> > Typically,
> > >> > +   pads are physically attached to tablets and a pad_added event
> > is
> > >> > +   sent immediately after the wp_tablet_seat.tablet_added.
> > >> > +   However, some standalone pad devices logically attach to
> > tablets at
> > >> > +   runtime, the client must wait for wp_tablet_pad.enter to know
> > the
> > >> > +   tablet a pad is attached to.
> > >> > +
> > >>
> > >> If a compositor wanted to support "bare" pad devices, I'm assuming
> > >> they'd have to fake one or more wp_tablet objects for that use,
> > >> correct?
> > >
> > > yeah, I think so. but there is the question of what a standalone pad (I
> > > assume you're talking about the EKR) would do in a wacom/tablet context?
> > > and whether the EKR would just be better off as a buttonset device when
> > it's
> > 

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

[Bryce Harrington]

On Tue, May 10, 2016 at 03:33:59PM +0300, Pekka Paalanen wrote:
> On Fri, 29 Apr 2016 15:40:35 -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.
> > 
> > With the use_current_mode moved into the main config class, the
> > drm_config wrapper is redundant.  Dropping it helps make the drm backend
> > config initialization more consistent with the other backends.
> > 
> > Also, enforce destruction of the backend config object after
> > initialization.  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 
> > Reviewed-by: Pekka Paalanen 
> > 
> > ---
> > v6:
> >  - Drop use of drm_config config wrapper
> > v7:
> >  - Update to master
> >  - Put backend configs on stack instead of zalloc()
> >  - Enforce destruction of backend config object
> >(Squashed patch as requested by pq)
> > 
> >  src/compositor-drm.c | 24 +++-
> >  src/compositor-drm.h |  3 ++-
> >  src/main.c   | 46 --
> >  3 files changed, 33 insertions(+), 40 deletions(-)
> 
> Hi,
> 
> I decided to do some cleaning up here, and squashed these two patches.
> It was getting annoying to review one patch and then see the follow-up
> in the same series void some of the earlier comments that would have
> caused a reject.
> 
> To put things short, pushed:
>59987fa..1c0e40d  master -> master
> 
> I also wrote the commit message for this patch from scratch. I do not
> recall any of the conversion patches before this one to actually
> document *why* we are doing this. This and other changes you can find
> listed upstream. I thought I won't bother you with yet another round,
> but just fix what I thought was important at the moment and push it.
> 
> Let's deal with any comments and fallout in follow-ups.

Sounds good, it's nice to see this patch series finally get wrapped up,
and I agree there's plenty more work here for the future.

> Thank you Bryce for picking this up, and Benoit too.
> 
> 
> Thanks,
> pq

Bryce

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIVAwUBVzHVNyNf5bQRqqqnAQi7BRAAl9cYXrOI+479pAQgxZg8POy+Hab+sOJH
> TK6Yd8viwAu/bsiHHlFYywmBFBVG1/JGp/eVmy92gFAADSMv1xANAhYQkPVxq2Yu
> qAjp9CVLQo1OEysB042BHYPCsgblFUF37gsu5I2B+z7aF5o1caVh7Qu47eE95gzp
> u0u62qf2TLYUz6kT0FmhL/Yh5vNoXIPn3nm/lP+B2LgY7kNKyAzQjKZRg/j5fReb
> XBAvGkOxhY/9ByEgEYjthfafp166Pv5GuoRsSOfSK8zgTSZV6jVkMBMIVmTFLD4S
> n7AUpzAu4xxYdKga6qYEwvtNtg7ZbujA411n+CuB8uq8W5SleTFxmQtsLnmGzagx
> wdkAmdV5yxRNtcOFnI1w9uIQRyaRX0yOVBlij7ezgJxZo22VJ2j1chdvo0Eb19zl
> O1OjEMCl6YbFyRf5AyS6cVIWjZKUirYGuRpb9MJWNKLH/WDFYiyVrljh7r7vNhCp
> 21HO+XOaTNLghPmMGuGs+0Iux81RktELMO3PQFJRw4uEjJGsTxD7hzUlrFMroeCT
> dOlCubc+z4XtGX8rL2x1OWsRNxvmbGrEmL1V2TzukMo+rHYoyskpZdPdgdYvuUV2
> knWFvTV8oAmQAEGeG6iPf1FeLNz0oJCUP5oyOjexLF+WbnRNLDvEITTGd4NbM8wj
> Bp1LEXkc2Zo=
> =RHBO
> -END PGP SIGNATURE-

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

Re: [PATCH wayland 1/1] connection: Move wl_interface_equal to util

[Bryce Harrington]

On Mon, May 09, 2016 at 03:41:14PM +0300, Pekka Paalanen wrote:
> On Sun,  8 May 2016 08:44:08 -0500
> Yong Bakos  wrote:
> 
> > From: Yong Bakos 
> > 
> > Move the wl_interface_equal prototype to the top of wayland-private, where
> > it is not buried in the middle of map, connection and closure functions.
> > 
> > Move the implementation out of connection and into util. This is a utility
> > function, not specific to connections, and has call sites within connection,
> > wayland-client and wayland-server.
> > 
> > Signed-off-by: Yong Bakos 
> > ---
> >  src/connection.c  | 13 -
> >  src/wayland-private.h |  8 
> >  src/wayland-util.c| 13 +
> >  3 files changed, 17 insertions(+), 17 deletions(-)
> > 
> > diff --git a/src/connection.c b/src/connection.c
> > index 747229e..c3293a9 100644
> > --- a/src/connection.c
> > +++ b/src/connection.c
> > @@ -798,19 +798,6 @@ wl_connection_demarshal(struct wl_connection 
> > *connection,
> >  }
> >  
> >  int
> > -wl_interface_equal(const struct wl_interface *a, const struct wl_interface 
> > *b)
> > -{
> > -   /* In most cases the pointer equality test is sufficient.
> > -* However, in some cases, depending on how things are split
> > -* across shared objects, we can end up with multiple
> > -* instances of the interface metadata constants.  So if the
> > -* pointers match, the interfaces are equal, if they don't
> > -* match we have to compare the interface names. */
> > -
> > -   return a == b || strcmp(a->name, b->name) == 0;
> > -}
> > -
> > -int
> >  wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map 
> > *objects)
> >  {
> > struct wl_object *object;
> > diff --git a/src/wayland-private.h b/src/wayland-private.h
> > index 994bc45..a9a07a8 100644
> > --- a/src/wayland-private.h
> > +++ b/src/wayland-private.h
> > @@ -55,6 +55,10 @@ struct wl_object {
> >  extern struct wl_object global_zombie_object;
> >  #define WL_ZOMBIE_OBJECT ((void*)_zombie_object)
> >  
> > +int
> > +wl_interface_equal(const struct wl_interface *iface1,
> > +  const struct wl_interface *iface2);
> > +
> >  /* Flags for wl_map_insert_new and wl_map_insert_at.  Flags can be queried 
> > with
> >   * wl_map_lookup_flags.  The current implementation has room for 1 bit 
> > worth of
> >   * flags.  If more flags are ever added, the implementation of wl_map will 
> > have
> > @@ -103,10 +107,6 @@ struct wl_connection;
> >  struct wl_closure;
> >  struct wl_proxy;
> >  
> > -int
> > -wl_interface_equal(const struct wl_interface *iface1,
> > -  const struct wl_interface *iface2);
> > -
> >  struct wl_connection *
> >  wl_connection_create(int fd);
> >  
> > diff --git a/src/wayland-util.c b/src/wayland-util.c
> > index 748476a..5bfb7e1 100644
> > --- a/src/wayland-util.c
> > +++ b/src/wayland-util.c
> > @@ -35,6 +35,19 @@
> >  
> >  struct wl_object global_zombie_object;
> >  
> > +int
> > +wl_interface_equal(const struct wl_interface *a, const struct wl_interface 
> > *b)
> > +{
> > +   /* In most cases the pointer equality test is sufficient.
> > +* However, in some cases, depending on how things are split
> > +* across shared objects, we can end up with multiple
> > +* instances of the interface metadata constants.  So if the
> > +* pointers match, the interfaces are equal, if they don't
> > +* match we have to compare the interface names.
> > +*/
> > +   return a == b || strcmp(a->name, b->name) == 0;
> > +}
> > +
> >  WL_EXPORT void
> >  wl_list_init(struct wl_list *list)
> >  {
> 
> Reviewed-by: Pekka Paalanen 

Reviewed-by: Bryce Harrington 

> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> 
> iQIVAwUBVzCFcSNf5bQRqqqnAQjtfBAAmOgNH+tI3mDtBCTwTnPfslCyeDHlZmoa
> JSvXlkyfxUx0C2TmC4pDUI89JB7pEHM1b2m3u8OotMDBgTf9Vawb9pQuCZB0W8MX
> 406+41f/m4Lbfo6R66wMiec5swHDxIMA2iu2lR42NKoQEAMfHlkA6QPnZhhJhWNv
> PT0lwIMG7S82x8j3iHOj/faXCG1WnK1zNL7ZAFCp7Ug1i4o2KeEZqpqS2MRDy/T0
> O6U3tZHLi42vtxXqsWPY6X4/J2YIysbTM4K17IZlkgxiRUstBncoRdNf0Upo5rPc
> ZaHBO0wmf55uzUNxgTC3Mh1XopgtNn6/jGV7UlW/U3avSv+cNx8x0k0Geq9K1cch
> 8lX0RxyEyFlPn6pDk9S27wNdh0SLx7yhfpiCms6x+CHCF2mVjSbViM0d4g1VY5Uw
> gT69+fhvnbdaJygh35oReoo86PZOpR61phWmeQkToXaj+FnEG8Pl5HSTpqG5tARH
> G0OXoLdTIXC4yJZUVA15KiUB3QKJmYxiryX3LYrlqiCZI0UCPBY1pI59Nczmy7wo
> IlQiL3PJIOMGNTqL+Fuzn42DPhfbxugxnTeFTlGyDrzPnUUjCpTqAUrc7r+25OCi
> vb3wKtH6kgCoEJCY8gI9zKy0PpbMg40DIQDpTfC38ee4rDsvLwzfkYyqrOLK/sPO
> HXM1WjdzO4Q=
> =yi7J
> -END PGP SIGNATURE-


> ___
> 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 1/1] doc: Formalize file comment in wayland-client.h, wayland-server.h

[Bryce Harrington]

On Sun, May 08, 2016 at 02:42:28PM -0500, Yong Bakos wrote:
> From: Yong Bakos 
> 
> Publican was generating a subtle error during a build:
> Error: no ID for constraint linkend: Server-wayland-server-core_8h.
> 
> This was caused by doxygen applying the doc comment at the top of
> wayland-server.h as the documentation for struct wl_object. As such, the
> generated documentation for wl_object was also very incorrect.
> 
> Make the file doc comments in wayland-client.h and wayland-server.h real
> doxygen file doc comments with the \file command, add a \brief, make the
> inclusion warning a \warning, correct the language of the comment in
> wayland-server.h, and remove one unnecessary line break.
> 
> This squelches the publican error, removes the bad wl_object documentation,
> and makes the comment appear in the generated html documentation.
> 
> References: d74a9c079b1aeb44f69b4132dc2c38362e21f281
> 
> Signed-off-by: Yong Bakos 

LGTM,

Reviewed-by: Bryce Harrington 

> ---
>  src/wayland-client.h | 7 +--
>  src/wayland-server.h | 9 ++---
>  2 files changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/src/wayland-client.h b/src/wayland-client.h
> index 3856535..9f70fa3 100644
> --- a/src/wayland-client.h
> +++ b/src/wayland-client.h
> @@ -23,8 +23,11 @@
>   * SOFTWARE.
>   */
>  
> -
> -/** Use of this header file is discouraged. Prefer including
> +/** \file
> + *
> + *  \brief Include the client API and protocol C API.
> + *
> + *  \warning Use of this header file is discouraged. Prefer including
>   *  wayland-client-core.h instead, which does not include the
>   *  client protocol header and as such only defines the library
>   *  API.
> diff --git a/src/wayland-server.h b/src/wayland-server.h
> index b6d0e2b..3124703 100644
> --- a/src/wayland-server.h
> +++ b/src/wayland-server.h
> @@ -23,10 +23,13 @@
>   * SOFTWARE.
>   */
>  
> -
> -/** Use of this header file is discouraged. Prefer including
> +/** \file
> + *
> + *  \brief Include the server API, deprecations and protocol C API.
> + *
> + *  \warning Use of this header file is discouraged. Prefer including
>   *  wayland-server-core.h instead, which does not include the
> - *  client protocol header and as such only defines the library
> + *  server protocol header and as such only defines the library
>   *  API, excluding the deprecated API below.
>   */
>  
> -- 
> 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 weston v4 00/14] compositor-wayland: refactor the configuration API

[Benoit Gschwind]

v4:
 - reorder patches
 - more spacing and lines wraping fix.
 - shorter the patches set
 - use glue code instead of renaming/refactoring when moving code

v3:
 - rebase to master
 - heavy patches spliting to help review as suggested by Pekka
 - spacing and lines wraping
 - rename functions and variables as suggested by Pekka

Benoit Gschwind (14):
  compositor-wayland: fix spacing and lines wraping
  compositor-wayland: fix too long lines
  compositor-wayland: rename wayland_output_init_from_config
  compositor-wayland: rename misleading output arg of
weston_wayland_output_config_init
  compositor-wayland: add versionning to config structure
  compositor-wayland: move configuration parsing to weston main.c
  compositor-wayland: rename load_wayland_backend_config arg "config" to
wc
  compositor-wayland: replace and remove new_config in
load_wayland_backend_config
  compositor-wayland: rename wayland_backend_config_add_new_output
function
  compositor-wayland: rename wayland_backend_config_release function
  compositor-wayland: rename out_config arg of
load_wayland_backend_config
  compositor-wayland: rename new_config arg of
weston_wayland_backend_config_release
  compositor-wayland: rename new_config arg of
weston_wayland_backend_config_add_new_output
  compositor-wayland: move weston_wayland_backend_config_release call
from load_wayland_backend_config to caller

 src/compositor-wayland.c | 208 ++-
 src/compositor-wayland.h |   3 +
 src/main.c   | 225 +++
 3 files changed, 236 insertions(+), 200 deletions(-)

-- 
2.7.3

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

[PATCH weston v4 13/14] compositor-wayland: rename new_config arg of weston_wayland_backend_config_add_new_output

[Benoit Gschwind]

Rename new_config to config to follow legacy naming scheme.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/main.c b/src/main.c
index 285a10d..d0a962f 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1104,18 +1104,18 @@ weston_wayland_backend_config_release(struct 
weston_wayland_backend_config *conf
  * structure is NOT cleared nor set to default values.
  */
 static struct weston_wayland_backend_output_config *
-weston_wayland_backend_config_add_new_output(struct 
weston_wayland_backend_config *new_config)
+weston_wayland_backend_config_add_new_output(struct 
weston_wayland_backend_config *config)
 {
struct weston_wayland_backend_output_config *outputs;
const size_t element_size = sizeof(struct 
weston_wayland_backend_output_config);
 
-   outputs = realloc(new_config->outputs,
- (new_config->num_outputs + 1) * element_size);
+   outputs = realloc(config->outputs,
+ (config->num_outputs + 1) * element_size);
if (!outputs)
return NULL;
-   new_config->num_outputs += 1;
-   new_config->outputs = outputs;
-   return &(new_config->outputs[new_config->num_outputs - 1]);
+   config->num_outputs += 1;
+   config->outputs = outputs;
+   return &(config->outputs[config->num_outputs - 1]);
 }
 
 static int
-- 
2.7.3

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

[PATCH weston v4 12/14] compositor-wayland: rename new_config arg of weston_wayland_backend_config_release

[Benoit Gschwind]

Rename new_config to config to follow legacy naming scheme.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/src/main.c b/src/main.c
index e28a576..285a10d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1086,16 +1086,16 @@ weston_wayland_output_config_init(struct 
weston_wayland_backend_output_config *o
 }
 
 static void
-weston_wayland_backend_config_release(struct weston_wayland_backend_config 
*new_config)
+weston_wayland_backend_config_release(struct weston_wayland_backend_config 
*config)
 {
int i;
 
-   for (i = 0; i < new_config->num_outputs; ++i) {
-   free(new_config->outputs[i].name);
+   for (i = 0; i < config->num_outputs; ++i) {
+   free(config->outputs[i].name);
}
-   free(new_config->cursor_theme);
-   free(new_config->display_name);
-   free(new_config->outputs);
+   free(config->cursor_theme);
+   free(config->display_name);
+   free(config->outputs);
 }
 
 /*
-- 
2.7.3

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

[PATCH weston v4 01/14] compositor-wayland: fix spacing and lines wraping

[Benoit Gschwind]

Signed-off-by: Benoit Gschwind 
---
 src/compositor-wayland.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index d0d1082..9351687 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2326,8 +2326,10 @@ wayland_backend_destroy(struct wayland_backend *b)
 }
 
 static void
-wayland_backend_config_release(struct weston_wayland_backend_config 
*new_config) {
+wayland_backend_config_release(struct weston_wayland_backend_config 
*new_config)
+{
int i;
+
for (i = 0; i < new_config->num_outputs; ++i) {
free(new_config->outputs[i].name);
}
@@ -2342,21 +2344,23 @@ wayland_backend_config_release(struct 
weston_wayland_backend_config *new_config)
  * structure is NOT cleared nor set to default values.
  */
 static struct weston_wayland_backend_output_config *
-wayland_backend_config_add_new_output(struct weston_wayland_backend_config 
*new_config) {
+wayland_backend_config_add_new_output(struct weston_wayland_backend_config 
*new_config)
+{
struct weston_wayland_backend_output_config *outputs;
+
outputs = realloc(new_config->outputs,
- (new_config->num_outputs+1)*sizeof(struct 
weston_wayland_backend_output_config));
+ (new_config->num_outputs + 1) * sizeof(struct 
weston_wayland_backend_output_config));
if (!outputs)
return NULL;
new_config->num_outputs += 1;
new_config->outputs = outputs;
-   return &(new_config->outputs[new_config->num_outputs-1]);
+   return &(new_config->outputs[new_config->num_outputs - 1]);
 }
 
 static int
-load_wayland_backend_config(struct weston_compositor *compositor, int *argc, 
char *argv[],
-struct weston_config *config,
-struct weston_wayland_backend_config *out_config)
+load_wayland_backend_config(struct weston_compositor *compositor, int *argc,
+   char *argv[], struct weston_config *config,
+   struct weston_wayland_backend_config *out_config)
 {
struct weston_wayland_backend_config new_config = { 0, };
struct weston_config_section *section;
-- 
2.7.3

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

[PATCH weston v4 11/14] compositor-wayland: rename out_config arg of load_wayland_backend_config

[Benoit Gschwind]

Rename the out_config arg of load_wayland_backend_config to follow
legacy naming convention.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 42 +-
 1 file changed, 21 insertions(+), 21 deletions(-)

diff --git a/src/main.c b/src/main.c
index e03bde7..e28a576 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1121,7 +1121,7 @@ weston_wayland_backend_config_add_new_output(struct 
weston_wayland_backend_confi
 static int
 load_wayland_backend_config(struct weston_compositor *compositor, int *argc,
char *argv[], struct weston_config *wc,
-   struct weston_wayland_backend_config *out_config)
+   struct weston_wayland_backend_config *config)
 {
struct weston_config_section *section;
struct weston_wayland_backend_output_config *oc;
@@ -1133,42 +1133,42 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
{ WESTON_OPTION_INTEGER, "width", 0,  },
{ WESTON_OPTION_INTEGER, "height", 0,  },
{ WESTON_OPTION_INTEGER, "scale", 0,  },
-   { WESTON_OPTION_STRING, "display", 0, _config->display_name 
},
-   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, 
_config->use_pixman },
+   { WESTON_OPTION_STRING, "display", 0, >display_name },
+   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, >use_pixman },
{ WESTON_OPTION_INTEGER, "output-count", 0,  },
-   { WESTON_OPTION_BOOLEAN, "fullscreen", 0, 
_config->fullscreen },
-   { WESTON_OPTION_BOOLEAN, "sprawl", 0, _config->sprawl },
+   { WESTON_OPTION_BOOLEAN, "fullscreen", 0, >fullscreen },
+   { WESTON_OPTION_BOOLEAN, "sprawl", 0, >sprawl },
};
 
width = 0;
height = 0;
scale = 0;
-   out_config->display_name = NULL;
-   out_config->use_pixman = 0;
+   config->display_name = NULL;
+   config->use_pixman = 0;
count = 1;
-   out_config->fullscreen = 0;
-   out_config->sprawl = 0;
+   config->fullscreen = 0;
+   config->sprawl = 0;
parse_options(wayland_options,
  ARRAY_LENGTH(wayland_options), argc, argv);
 
-   out_config->cursor_size = 32;
-   out_config->cursor_theme = NULL;
-   out_config->base.struct_size = sizeof(struct 
weston_wayland_backend_config);
-   out_config->base.struct_version = WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
+   config->cursor_size = 32;
+   config->cursor_theme = NULL;
+   config->base.struct_size = sizeof(struct weston_wayland_backend_config);
+   config->base.struct_version = WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
 
section = weston_config_get_section(wc, "shell", NULL, NULL);
weston_config_section_get_string(section, "cursor-theme",
-_config->cursor_theme, NULL);
+>cursor_theme, NULL);
weston_config_section_get_int(section, "cursor-size",
- _config->cursor_size, 32);
+ >cursor_size, 32);
 
-   if (out_config->sprawl) {
+   if (config->sprawl) {
/* do nothing, everything is already set */
return 0;
}
 
-   if (out_config->fullscreen) {
-   oc = weston_wayland_backend_config_add_new_output(out_config);
+   if (config->fullscreen) {
+   oc = weston_wayland_backend_config_add_new_output(config);
if (!oc)
goto err_outputs;
 
@@ -1195,7 +1195,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
}
free(name);
 
-   oc = weston_wayland_backend_config_add_new_output(out_config);
+   oc = weston_wayland_backend_config_add_new_output(config);
 
if (!oc)
goto err_outputs;
@@ -1213,7 +1213,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
scale = 1;
while (count > 0) {
 
-   oc = weston_wayland_backend_config_add_new_output(out_config);
+   oc = weston_wayland_backend_config_add_new_output(config);
 
if (!oc)
goto err_outputs;
@@ -1230,7 +1230,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
return 0;
 
 err_outputs:
-   weston_wayland_backend_config_release(out_config);
+   weston_wayland_backend_config_release(config);
return -1;
 }
 
-- 
2.7.3

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

[PATCH weston v4 08/14] compositor-wayland: replace and remove new_config in load_wayland_backend_config

[Benoit Gschwind]

Remove the unseless intermediate variable new_config in the function
load_wayland_backend_config, replacing it by the existing variable
out_config.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 44 
 1 file changed, 20 insertions(+), 24 deletions(-)

diff --git a/src/main.c b/src/main.c
index 24321e7..231f1b9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1123,7 +1123,6 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
char *argv[], struct weston_config *wc,
struct weston_wayland_backend_config *out_config)
 {
-   struct weston_wayland_backend_config new_config = {{ 0, }};
struct weston_config_section *section;
struct weston_wayland_backend_output_config *oc;
int count, width, height, scale;
@@ -1134,43 +1133,42 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
{ WESTON_OPTION_INTEGER, "width", 0,  },
{ WESTON_OPTION_INTEGER, "height", 0,  },
{ WESTON_OPTION_INTEGER, "scale", 0,  },
-   { WESTON_OPTION_STRING, "display", 0, _config.display_name 
},
-   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, 
_config.use_pixman },
+   { WESTON_OPTION_STRING, "display", 0, _config->display_name 
},
+   { WESTON_OPTION_BOOLEAN, "use-pixman", 0, 
_config->use_pixman },
{ WESTON_OPTION_INTEGER, "output-count", 0,  },
-   { WESTON_OPTION_BOOLEAN, "fullscreen", 0, 
_config.fullscreen },
-   { WESTON_OPTION_BOOLEAN, "sprawl", 0, _config.sprawl },
+   { WESTON_OPTION_BOOLEAN, "fullscreen", 0, 
_config->fullscreen },
+   { WESTON_OPTION_BOOLEAN, "sprawl", 0, _config->sprawl },
};
 
width = 0;
height = 0;
scale = 0;
-   new_config.display_name = NULL;
-   new_config.use_pixman = 0;
+   out_config->display_name = NULL;
+   out_config->use_pixman = 0;
count = 1;
-   new_config.fullscreen = 0;
-   new_config.sprawl = 0;
+   out_config->fullscreen = 0;
+   out_config->sprawl = 0;
parse_options(wayland_options,
  ARRAY_LENGTH(wayland_options), argc, argv);
 
-   new_config.cursor_size = 32;
-   new_config.cursor_theme = NULL;
-   new_config.base.struct_size = sizeof(struct 
weston_wayland_backend_config);
-   new_config.base.struct_version = WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
+   out_config->cursor_size = 32;
+   out_config->cursor_theme = NULL;
+   out_config->base.struct_size = sizeof(struct 
weston_wayland_backend_config);
+   out_config->base.struct_version = WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
 
section = weston_config_get_section(wc, "shell", NULL, NULL);
weston_config_section_get_string(section, "cursor-theme",
-_config.cursor_theme, NULL);
+_config->cursor_theme, NULL);
weston_config_section_get_int(section, "cursor-size",
- _config.cursor_size, 32);
+ _config->cursor_size, 32);
 
-   if (new_config.sprawl) {
+   if (out_config->sprawl) {
/* do nothing, everything is already set */
-   *out_config = new_config;
return 0;
}
 
-   if (new_config.fullscreen) {
-   oc = wayland_backend_config_add_new_output(_config);
+   if (out_config->fullscreen) {
+   oc = wayland_backend_config_add_new_output(out_config);
if (!oc)
goto err_outputs;
 
@@ -1180,7 +1178,6 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
oc->transform = WL_OUTPUT_TRANSFORM_NORMAL;
oc->scale = 1;
 
-   *out_config = new_config;
return 0;
}
 
@@ -1198,7 +1195,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
}
free(name);
 
-   oc = wayland_backend_config_add_new_output(_config);
+   oc = wayland_backend_config_add_new_output(out_config);
 
if (!oc)
goto err_outputs;
@@ -1216,7 +1213,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
scale = 1;
while (count > 0) {
 
-   oc = wayland_backend_config_add_new_output(_config);
+   oc = wayland_backend_config_add_new_output(out_config);
 
if (!oc)
goto err_outputs;
@@ -1230,11 +1227,10 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
--count;
}
 
-   *out_config = new_config;
return 0;
 
 err_outputs:
-  

[PATCH weston v4 04/14] compositor-wayland: rename misleading output arg of weston_wayland_output_config_init

[Benoit Gschwind]

Rename the misleading output argument to output_config in the
weston_wayland_output_config_init function.

Signed-off-by: Benoit Gschwind 
---
 src/compositor-wayland.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index adeb59b..0d485f8 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -1096,7 +1096,7 @@ err_name:
  * "compositor-wayland: move configuration parsing to weston"
  */
 static void
-weston_wayland_output_config_init(struct weston_wayland_backend_output_config 
*output,
+weston_wayland_output_config_init(struct weston_wayland_backend_output_config 
*output_config,
  struct weston_config_section *config_section,
  int option_width, int option_height,
  int option_scale)
@@ -1104,46 +1104,46 @@ weston_wayland_output_config_init(struct 
weston_wayland_backend_output_config *o
char *mode, *t, *str;
unsigned int slen;
 
-   weston_config_section_get_string(config_section, "name", >name,
+   weston_config_section_get_string(config_section, "name", 
_config->name,
 NULL);
-   if (output->name) {
-   slen = strlen(output->name);
+   if (output_config->name) {
+   slen = strlen(output_config->name);
slen += strlen(WINDOW_TITLE " - ");
str = malloc(slen + 1);
if (str)
snprintf(str, slen + 1, WINDOW_TITLE " - %s",
-output->name);
-   free(output->name);
-   output->name = str;
+output_config->name);
+   free(output_config->name);
+   output_config->name = str;
}
-   if (!output->name)
-   output->name = strdup(WINDOW_TITLE);
+   if (!output_config->name)
+   output_config->name = strdup(WINDOW_TITLE);
 
weston_config_section_get_string(config_section,
 "mode", , "1024x600");
-   if (sscanf(mode, "%dx%d", >width, >height) != 2) {
+   if (sscanf(mode, "%dx%d", _config->width, 
_config->height) != 2) {
weston_log("Invalid mode \"%s\" for output %s\n",
-  mode, output->name);
-   output->width = 1024;
-   output->height = 640;
+  mode, output_config->name);
+   output_config->width = 1024;
+   output_config->height = 640;
}
free(mode);
 
if (option_width)
-   output->width = option_width;
+   output_config->width = option_width;
if (option_height)
-   output->height = option_height;
+   output_config->height = option_height;
 
-   weston_config_section_get_int(config_section, "scale", >scale, 
1);
+   weston_config_section_get_int(config_section, "scale", 
_config->scale, 1);
 
if (option_scale)
-   output->scale = option_scale;
+   output_config->scale = option_scale;
 
weston_config_section_get_string(config_section,
 "transform", , "normal");
-   if (weston_parse_transform(t, >transform) < 0)
+   if (weston_parse_transform(t, _config->transform) < 0)
weston_log("Invalid transform \"%s\" for output %s\n",
-  t, output->name);
+  t, output_config->name);
free(t);
 
 }
-- 
2.7.3

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

[PATCH weston v4 05/14] compositor-wayland: add versionning to config structure

[Benoit Gschwind]

The patch use temporary code that prepare the patch:
"compositor-wayland: move configuration parsing to weston main.c"

Signed-off-by: Benoit Gschwind 
---
 src/compositor-wayland.c | 29 ++---
 src/compositor-wayland.h |  3 +++
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 0d485f8..8b3eafb 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2367,7 +2367,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
char *argv[], struct weston_config *config,
struct weston_wayland_backend_config *out_config)
 {
-   struct weston_wayland_backend_config new_config = { 0, };
+   struct weston_wayland_backend_config new_config = {{ 0, }};
struct weston_config_section *section;
struct weston_wayland_backend_output_config *oc;
int count, width, height, scale;
@@ -2398,6 +2398,8 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
 
new_config.cursor_size = 32;
new_config.cursor_theme = NULL;
+   new_config.base.struct_size = sizeof(struct 
weston_wayland_backend_config);
+   new_config.base.struct_version = WESTON_WAYLAND_BACKEND_CONFIG_VERSION;
 
section = weston_config_get_section(config, "shell", NULL, NULL);
weston_config_section_get_string(section, "cursor-theme",
@@ -2480,6 +2482,11 @@ err_outputs:
return -1;
 }
 
+static void
+config_init_to_defaults(struct weston_wayland_backend_config *config)
+{
+}
+
 WL_EXPORT int
 backend_init(struct weston_compositor *compositor, int *argc, char *argv[],
 struct weston_config *config,
@@ -2489,14 +2496,30 @@ backend_init(struct weston_compositor *compositor, int 
*argc, char *argv[],
struct wayland_output *output;
struct wayland_parent_output *poutput;
struct weston_wayland_backend_config new_config;
+   struct weston_wayland_backend_config foreign_config = {{ 0, }};
int x, count;
 
if (load_wayland_backend_config(compositor, argc, argv, config,
-   _config) < 0) {
-   wayland_backend_config_release(_config);
+   _config) < 0) {
+   wayland_backend_config_release(_config);
return -1;
}
 
+   /* temporary assign to prepare the following patch:
+* "compositor-wayland: move configuration parsing to weston" */
+   config_base = _config.base;
+
+   if (config_base == NULL ||
+   config_base->struct_version != 
WESTON_WAYLAND_BACKEND_CONFIG_VERSION ||
+   config_base->struct_size > sizeof(struct 
weston_wayland_backend_config)) {
+   weston_log("wayland backend config structure is invalid\n");
+   wayland_backend_config_release(_config);
+   return -1;
+   }
+
+   config_init_to_defaults(_config);
+   memcpy(_config, config_base, config_base->struct_size);
+
b = wayland_backend_create(compositor, _config, argc, argv, config);
 
if (!b)
diff --git a/src/compositor-wayland.h b/src/compositor-wayland.h
index 5af5ea7..de69b98 100644
--- a/src/compositor-wayland.h
+++ b/src/compositor-wayland.h
@@ -32,6 +32,8 @@
 extern "C" {
 #endif
 
+#define WESTON_WAYLAND_BACKEND_CONFIG_VERSION 1
+
 struct weston_wayland_backend_output_config {
int width;
int height;
@@ -41,6 +43,7 @@ struct weston_wayland_backend_output_config {
 };
 
 struct weston_wayland_backend_config {
+   struct weston_backend_config base;
int use_pixman;
int sprawl;
char *display_name;
-- 
2.7.3

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

[PATCH weston v4 10/14] compositor-wayland: rename wayland_backend_config_release function

[Benoit Gschwind]

Rename the wayland_backend_config_release function to
weston_wayland_backend_config_release to follow legacy naming scheme.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/main.c b/src/main.c
index 28e7e1d..e03bde7 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1086,7 +1086,7 @@ weston_wayland_output_config_init(struct 
weston_wayland_backend_output_config *o
 }
 
 static void
-wayland_backend_config_release(struct weston_wayland_backend_config 
*new_config)
+weston_wayland_backend_config_release(struct weston_wayland_backend_config 
*new_config)
 {
int i;
 
@@ -1230,7 +1230,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
return 0;
 
 err_outputs:
-   wayland_backend_config_release(out_config);
+   weston_wayland_backend_config_release(out_config);
return -1;
 }
 
@@ -1248,7 +1248,7 @@ load_wayland_backend(struct weston_compositor *c, char 
const * backend,
 
/* load the actual wayland backend and configure it */
ret = load_backend_new(c, backend, );
-   wayland_backend_config_release();
+   weston_wayland_backend_config_release();
return ret;
 }
 
-- 
2.7.3

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

[PATCH weston v4 09/14] compositor-wayland: rename wayland_backend_config_add_new_output function

[Benoit Gschwind]

Rename wayland_backend_config_add_new_output to
weston_wayland_backend_config_add_new_output to follow the legacy naming
scheme.

Signed-off-by: Benoit Gschwind 
---
 src/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/main.c b/src/main.c
index 231f1b9..28e7e1d 100644
--- a/src/main.c
+++ b/src/main.c
@@ -1104,7 +1104,7 @@ wayland_backend_config_release(struct 
weston_wayland_backend_config *new_config)
  * structure is NOT cleared nor set to default values.
  */
 static struct weston_wayland_backend_output_config *
-wayland_backend_config_add_new_output(struct weston_wayland_backend_config 
*new_config)
+weston_wayland_backend_config_add_new_output(struct 
weston_wayland_backend_config *new_config)
 {
struct weston_wayland_backend_output_config *outputs;
const size_t element_size = sizeof(struct 
weston_wayland_backend_output_config);
@@ -1168,7 +1168,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
}
 
if (out_config->fullscreen) {
-   oc = wayland_backend_config_add_new_output(out_config);
+   oc = weston_wayland_backend_config_add_new_output(out_config);
if (!oc)
goto err_outputs;
 
@@ -1195,7 +1195,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
}
free(name);
 
-   oc = wayland_backend_config_add_new_output(out_config);
+   oc = weston_wayland_backend_config_add_new_output(out_config);
 
if (!oc)
goto err_outputs;
@@ -1213,7 +1213,7 @@ load_wayland_backend_config(struct weston_compositor 
*compositor, int *argc,
scale = 1;
while (count > 0) {
 
-   oc = wayland_backend_config_add_new_output(out_config);
+   oc = weston_wayland_backend_config_add_new_output(out_config);
 
if (!oc)
goto err_outputs;
-- 
2.7.3

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

[PATCH weston v4 02/14] compositor-wayland: fix too long lines

[Benoit Gschwind]

Signed-off-by: Benoit Gschwind 
---
 src/compositor-wayland.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/compositor-wayland.c b/src/compositor-wayland.c
index 9351687..4799f90 100644
--- a/src/compositor-wayland.c
+++ b/src/compositor-wayland.c
@@ -2347,9 +2347,10 @@ static struct weston_wayland_backend_output_config *
 wayland_backend_config_add_new_output(struct weston_wayland_backend_config 
*new_config)
 {
struct weston_wayland_backend_output_config *outputs;
+   const size_t element_size = sizeof(struct 
weston_wayland_backend_output_config);
 
outputs = realloc(new_config->outputs,
- (new_config->num_outputs + 1) * sizeof(struct 
weston_wayland_backend_output_config));
+ (new_config->num_outputs + 1) * element_size);
if (!outputs)
return NULL;
new_config->num_outputs += 1;
-- 
2.7.3

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

Protocol for window previews/thumbnails

[ade low]

I think that it would be a good idea to have a standard, cross-compositor
protocol for getting previews/thumbnails of windows, similar to XComposite.

This protocol should be as fast as possible and use as little system
resources as possible. It should probably provide a handle to the native
window surface.

It will also be necessary to receive damage events on these surfaces. I
don't know if this should be included in this protocol or if this should be
a separate protocol?

Does anyone have any ideas on the best way to design such a protocol?

Thank you

Regards

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

Re: [PATCH weston] desktop-shell: Don’t reconfigure an already fullscreen surface

[Yong Bakos]

On May 9, 2016, at 8:22 PM, Emmanuel Gil Peyrot  wrote:
> 
> When we receive an wl_shell_surface::set_fullscreen request for a
> surface that was already fullscreen, don’t do anything if the
> parameters are the same as the initial request.
> 
> This prevents bogus or malicious clients from being able to always stay
> on front by flooding the compositor with set_fullscreen requests after
> the user has put them in the background with a mod+tab.
> 
> Signed-off-by: Emmanuel Gil Peyrot 

Makes sense, and I can't immediately think of a use case where this wouldn't
make sense. So fwiw,
Reviewed-by: Yong Bakos 

yong


> ---
> desktop-shell/shell.c | 7 +++
> 1 file changed, 7 insertions(+)
> 
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 1c39a12..7d5bca9 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -2561,6 +2561,13 @@ shell_surface_set_fullscreen(struct wl_client *client,
>   struct shell_surface *shsurf = wl_resource_get_user_data(resource);
>   struct weston_output *output;
> 
> + if (shsurf->fullscreen_output == shsurf->output &&
> + shsurf->fullscreen.type == method &&
> + shsurf->fullscreen.framerate == framerate) {
> + send_configure_for_surface(shsurf);
> + return;
> + }
> +
>   if (output_resource)
>   output = wl_resource_get_user_data(output_resource);
>   else
> -- 
> 2.8.2
> 
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

Re: [PATCH weston 1/2] compositor: fix comments about weston_compositor::surface_list

[Yong Bakos]

On May 10, 2016, at 9:10 AM, Pekka Paalanen  wrote:
> 
> From: Pekka Paalanen 
> 
> a7af70436b7dccfacd736626d6719b3e751fd985 converted the surface list into
> a view list.
> 
> It looks like weston_surface::output's comment about surface list does
> not apply to view list. Still, many places assume weston_surface::output
> is not NULL when processing "visible" surfaces, e.g. those reachable via
> the view list.
> 
> The comment on weston_view::output is updated, but I could not figure
> out the actual relationship between that and being on the view list.
> 
> weston_view::link is documented to be in weston_compositor::view_list,
> and weston_compositor::view_list is documented to contain weston_views.
> 
> Signed-off-by: Pekka Paalanen 

All comment additions in 1 and 2 look good to me.

Reviewed-by: Yong Bakos 

yong


> ---
> src/compositor.h | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/src/compositor.h b/src/compositor.h
> index a95f05d..7851000 100644
> --- a/src/compositor.h
> +++ b/src/compositor.h
> @@ -754,7 +754,7 @@ struct weston_compositor {
>   struct wl_list output_list;
>   struct wl_list seat_list;
>   struct wl_list layer_list;
> - struct wl_list view_list;
> + struct wl_list view_list;   /* struct weston_view::link */
>   struct wl_list plane_list;
>   struct wl_list key_binding_list;
>   struct wl_list modifier_binding_list;
> @@ -890,7 +890,7 @@ struct weston_view {
>   struct wl_list surface_link;
>   struct wl_signal destroy_signal;
> 
> - struct wl_list link;
> + struct wl_list link; /* weston_compositor::view_list */
>   struct weston_layer_entry layer_link; /* part of geometry */
>   struct weston_plane *plane;
> 
> @@ -951,7 +951,7 @@ struct weston_view {
>   /*
>* Which output to vsync this surface to.
>* Used to determine, whether to send or queue frame events.
> -  * Must be NULL, if 'link' is not in weston_compositor::surface_list.
> +  * Must be NULL, if 'link' is not in weston_compositor::view_list.
>*/
>   struct weston_output *output;
> 
> @@ -1021,7 +1021,6 @@ struct weston_surface {
>   /*
>* Which output to vsync this surface to.
>* Used to determine, whether to send or queue frame events.
> -  * Must be NULL, if 'link' is not in weston_compositor::surface_list.
>*/
>   struct weston_output *output;
> 
> -- 
> 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 weston 3/3] ivi-shell: add API for weston_surface -> ivi_layout_surface

[Pekka Paalanen]

From: Pekka Paalanen 

Add ivi-layout API for getting an ivi_layout_surface from a
weston_surface if it exists. This can be used by controllers that hook
up to core Weston callbacks and get handed a weston_surface, but need to
use ivi-layout API to manipulate it.

The only ways ivi-layout itself would be able to go from weston_surface
to ivi_layout_surface are either searching through the list of all
ivi_layout_surfaces or adding a dummy destroy listener to the
weston_surface. Therefore the implementation is delegated to
ivi-shell.c.

Ivi-shell.c can easily look up the ivi_shell_surface for a
weston_surface, and that will map 1:1 to an ivi_layout_surface.

Signed-off-by: Pekka Paalanen 
---
 ivi-shell/ivi-layout-export.h |  9 +
 ivi-shell/ivi-layout.c|  1 +
 ivi-shell/ivi-shell.c | 12 
 ivi-shell/ivi-shell.h |  5 +
 4 files changed, 27 insertions(+)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 33aa820..e437d9e 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -567,6 +567,15 @@ struct ivi_layout_interface {
void *target, size_t size,
int32_t x, int32_t y,
int32_t width, int32_t height);
+
+   /**
+* Returns the ivi_layout_surface or NULL
+*
+* NULL is returned if there is no ivi_layout_surface corresponding
+* to the given weston_surface.
+*/
+   struct ivi_layout_surface *
+   (*get_surface)(struct weston_surface *surface);
 };
 
 #ifdef __cplusplus
diff --git a/ivi-shell/ivi-layout.c b/ivi-shell/ivi-layout.c
index 1601787..0aa3edb 100644
--- a/ivi-shell/ivi-layout.c
+++ b/ivi-shell/ivi-layout.c
@@ -1992,6 +1992,7 @@ static struct ivi_layout_interface ivi_layout_interface = 
{
.add_listener_create_surface= 
ivi_layout_add_listener_create_surface,
.add_listener_remove_surface= 
ivi_layout_add_listener_remove_surface,
.add_listener_configure_surface = 
ivi_layout_add_listener_configure_surface,
+   .get_surface= shell_get_ivi_layout_surface,
.get_surfaces   = ivi_layout_get_surfaces,
.get_id_of_surface  = ivi_layout_get_id_of_surface,
.get_surface_from_id= 
ivi_layout_get_surface_from_id,
diff --git a/ivi-shell/ivi-shell.c b/ivi-shell/ivi-shell.c
index c502c74..59ffe0c 100644
--- a/ivi-shell/ivi-shell.c
+++ b/ivi-shell/ivi-shell.c
@@ -93,6 +93,18 @@ get_ivi_shell_surface(struct weston_surface *surface)
return shsurf;
 }
 
+struct ivi_layout_surface *
+shell_get_ivi_layout_surface(struct weston_surface *surface)
+{
+   struct ivi_shell_surface *shsurf;
+
+   shsurf = get_ivi_shell_surface(surface);
+   if (!shsurf)
+   return NULL;
+
+   return shsurf->layout_surface;
+}
+
 void
 shell_surface_send_configure(struct weston_surface *surface,
 int32_t width, int32_t height)
diff --git a/ivi-shell/ivi-shell.h b/ivi-shell/ivi-shell.h
index 45faceb..369e5f8 100644
--- a/ivi-shell/ivi-shell.h
+++ b/ivi-shell/ivi-shell.h
@@ -73,4 +73,9 @@ void
 shell_surface_send_configure(struct weston_surface *surface,
 int32_t width, int32_t height);
 
+struct ivi_layout_surface;
+
+struct ivi_layout_surface *
+shell_get_ivi_layout_surface(struct weston_surface *surface);
+
 #endif /* WESTON_IVI_SHELL_H */
-- 
2.7.3

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

[PATCH weston 0/3] misc ivi-shell patches

[Pekka Paalanen]

From: Pekka Paalanen 

Hi,

these patches are a by-product from working on the IVI-surface remoting
project.

Patch 3 is adding new API, and we are past alpha release in the 1.11 release
cycle, so we might want to postpone that one to 1.12. The others should be fine
before beta, though.

Thanks,
pq


Pekka Paalanen (3):
  ivi-shell-user-interface: ignore all but first seat
  ivi-layout: clarify get_layers_under_surface doc
  ivi-shell: add API for weston_surface -> ivi_layout_surface

 clients/ivi-shell-user-interface.c |  4 
 ivi-shell/ivi-layout-export.h  | 14 +-
 ivi-shell/ivi-layout.c |  1 +
 ivi-shell/ivi-shell.c  | 12 
 ivi-shell/ivi-shell.h  |  5 +
 5 files changed, 35 insertions(+), 1 deletion(-)

-- 
2.7.3

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

[PATCH weston 2/3] ivi-layout: clarify get_layers_under_surface doc

[Pekka Paalanen]

From: Pekka Paalanen 

This is derived from the implementation. I was not sure whether "under"
referred to object relationships or region intersections.

Signed-off-by: Pekka Paalanen 
---
 ivi-shell/ivi-layout-export.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/ivi-shell/ivi-layout-export.h b/ivi-shell/ivi-layout-export.h
index 9c5225c..33aa820 100644
--- a/ivi-shell/ivi-layout-export.h
+++ b/ivi-shell/ivi-layout-export.h
@@ -393,7 +393,10 @@ struct ivi_layout_interface {
(*get_properties_of_layer)(struct ivi_layout_layer *ivilayer);
 
/**
-* \brief Get all ivi_ayers under the given ivi_surface
+* \brief Get all ivi-layers under the given ivi-surface
+*
+* This means all the ivi-layers the ivi-surface was added to. It has
+* no relation to geometric overlaps.
 *
 * \return IVI_SUCCEEDED if the method call was successful
 * \return IVI_FAILED if the method call was failed
-- 
2.7.3

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

[PATCH weston 1/3] ivi-shell-user-interface: ignore all but first seat

[Pekka Paalanen]

From: Pekka Paalanen 

This client should support binding to multiple seats, but as it does
not, make a quick and dirty fix to ignore all seats beyond the first
one.

Signed-off-by: Pekka Paalanen 
---
 clients/ivi-shell-user-interface.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/clients/ivi-shell-user-interface.c 
b/clients/ivi-shell-user-interface.c
index 0a24ed6..06b79a2 100644
--- a/clients/ivi-shell-user-interface.c
+++ b/clients/ivi-shell-user-interface.c
@@ -591,6 +591,10 @@ registry_handle_global(void *data, struct wl_registry 
*registry, uint32_t name,
wl_registry_bind(registry, name, _shm_interface, 1);
wl_shm_add_listener(p_wlCtx->wlShm, _listenter, p_wlCtx);
} else if (!strcmp(interface, "wl_seat")) {
+   /* XXX: should be handling multiple wl_seats */
+   if (p_wlCtx->wlSeat)
+   return;
+
p_wlCtx->wlSeat =
wl_registry_bind(registry, name, _seat_interface, 1);
wl_seat_add_listener(p_wlCtx->wlSeat, _Listener, data);
-- 
2.7.3

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

[PATCH weston 2/2] compositor: surface and view output comment fixes

[Pekka Paalanen]

From: Pekka Paalanen 

weston_surface::output and weston_view::output as used for different
purposes. Only the surface output is used for frame callbacks.

The uses of the view output are much more vague and hard to describe.

Also fix a comment mistake in weston_surface_assign_output().

Signed-off-by: Pekka Paalanen 
---
 src/compositor.c | 8 +++-
 src/compositor.h | 5 +++--
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/src/compositor.c b/src/compositor.c
index ee47a82..40d8baf 100644
--- a/src/compositor.c
+++ b/src/compositor.c
@@ -1082,16 +1082,15 @@ weston_surface_update_output_mask(struct weston_surface 
*es, uint32_t mask)
}
 }
 
-
 /** Recalculate which output(s) the surface has views displayed on
  *
  * \param es  The surface to remap to outputs
  *
  * Finds the output that is showing the largest amount of one
  * of the surface's various views.  This output becomes the
- * surface's primary output for vsync and frame event purposes.
+ * surface's primary output for vsync and frame callback purposes.
  *
- * Also notes the primary outputs of all of the surface's views
+ * Also notes all outputs of all of the surface's views
  * in the output_mask for the surface.
  */
 static void
@@ -1136,8 +1135,7 @@ weston_surface_assign_output(struct weston_surface *es)
  *
  * Identifies the set of outputs that the view is visible on,
  * noting them into the output_mask.  The output that the view
- * is most visible on is set as the view's primary output for
- * vsync and frame event purposes.
+ * is most visible on is set as the view's primary output.
  *
  * Also does the same for the view's surface.  See
  * weston_surface_assign_output().
diff --git a/src/compositor.h b/src/compositor.h
index 7851000..0801f20 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -949,8 +949,9 @@ struct weston_view {
} transform;
 
/*
-* Which output to vsync this surface to.
-* Used to determine, whether to send or queue frame events.
+* The primary output for this view.
+* Used for picking the output for driving view animations, inheriting
+* the primary output for related views in shells, etc.
 * Must be NULL, if 'link' is not in weston_compositor::view_list.
 */
struct weston_output *output;
-- 
2.7.3

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

[PATCH weston 1/2] compositor: fix comments about weston_compositor::surface_list

[Pekka Paalanen]

From: Pekka Paalanen 

a7af70436b7dccfacd736626d6719b3e751fd985 converted the surface list into
a view list.

It looks like weston_surface::output's comment about surface list does
not apply to view list. Still, many places assume weston_surface::output
is not NULL when processing "visible" surfaces, e.g. those reachable via
the view list.

The comment on weston_view::output is updated, but I could not figure
out the actual relationship between that and being on the view list.

weston_view::link is documented to be in weston_compositor::view_list,
and weston_compositor::view_list is documented to contain weston_views.

Signed-off-by: Pekka Paalanen 
---
 src/compositor.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/compositor.h b/src/compositor.h
index a95f05d..7851000 100644
--- a/src/compositor.h
+++ b/src/compositor.h
@@ -754,7 +754,7 @@ struct weston_compositor {
struct wl_list output_list;
struct wl_list seat_list;
struct wl_list layer_list;
-   struct wl_list view_list;
+   struct wl_list view_list;   /* struct weston_view::link */
struct wl_list plane_list;
struct wl_list key_binding_list;
struct wl_list modifier_binding_list;
@@ -890,7 +890,7 @@ struct weston_view {
struct wl_list surface_link;
struct wl_signal destroy_signal;
 
-   struct wl_list link;
+   struct wl_list link; /* weston_compositor::view_list */
struct weston_layer_entry layer_link; /* part of geometry */
struct weston_plane *plane;
 
@@ -951,7 +951,7 @@ struct weston_view {
/*
 * Which output to vsync this surface to.
 * Used to determine, whether to send or queue frame events.
-* Must be NULL, if 'link' is not in weston_compositor::surface_list.
+* Must be NULL, if 'link' is not in weston_compositor::view_list.
 */
struct weston_output *output;
 
@@ -1021,7 +1021,6 @@ struct weston_surface {
/*
 * Which output to vsync this surface to.
 * Used to determine, whether to send or queue frame events.
-* Must be NULL, if 'link' is not in weston_compositor::surface_list.
 */
struct weston_output *output;
 
-- 
2.7.3

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

[PATCH weston 1/3] eventdemo: do not print pointer frames alone

[Pekka Paalanen]

From: Pekka Paalanen 

Print pointer frames only if any pointer related events are printed
first.

This avoids flooding the output with "pointer frame" just because of
motion.

Signed-off-by: Pekka Paalanen 
---
 clients/eventdemo.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index e323aa5..f1558d2 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -35,6 +35,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -93,6 +94,8 @@ struct eventdemo {
struct display *display;
 
int x, y, w, h;
+
+   bool print_pointer_frame;
 };
 
 /**
@@ -223,11 +226,14 @@ static void
 button_handler(struct widget *widget, struct input *input, uint32_t time,
   uint32_t button, enum wl_pointer_button_state state, void *data)
 {
+   struct eventdemo *e = data;
int32_t x, y;
 
if (!log_button)
return;
 
+   e->print_pointer_frame = true;
+
input_get_position(input, , );
printf("button time: %d, button: %d, state: %s, x: %d, y: %d\n",
   time, button,
@@ -249,9 +255,13 @@ static void
 axis_handler(struct widget *widget, struct input *input, uint32_t time,
 uint32_t axis, wl_fixed_t value, void *data)
 {
+   struct eventdemo *e = data;
+
if (!log_axis)
return;
 
+   e->print_pointer_frame = true;
+
printf("axis time: %d, axis: %s, value: %f\n",
   time,
   axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
@@ -262,7 +272,13 @@ axis_handler(struct widget *widget, struct input *input, 
uint32_t time,
 static void
 pointer_frame_handler(struct widget *widget, struct input *input, void *data)
 {
+   struct eventdemo *e = data;
+
+   if (!e->print_pointer_frame)
+   return;
+
printf("pointer frame\n");
+   e->print_pointer_frame = false;
 }
 
 static void
@@ -270,6 +286,9 @@ axis_source_handler(struct widget *widget, struct input 
*input,
uint32_t source, void *data)
 {
const char *axis_source;
+   struct eventdemo *e = data;
+
+   e->print_pointer_frame = true;
 
switch (source) {
case WL_POINTER_AXIS_SOURCE_WHEEL:
@@ -294,6 +313,9 @@ axis_stop_handler(struct widget *widget, struct input 
*input,
  uint32_t time, uint32_t axis,
  void *data)
 {
+   struct eventdemo *e = data;
+
+   e->print_pointer_frame = true;
printf("axis stop time: %d, axis: %s\n",
   time,
   axis == WL_POINTER_AXIS_VERTICAL_SCROLL ? "vertical" :
@@ -304,6 +326,9 @@ static void
 axis_discrete_handler(struct widget *widget, struct input *input,
  uint32_t axis, int32_t discrete, void *data)
 {
+   struct eventdemo *e = data;
+
+   e->print_pointer_frame = true;
printf("axis discrete axis: %d value: %d\n", axis, discrete);
 }
 
@@ -328,6 +353,7 @@ motion_handler(struct widget *widget, struct input *input, 
uint32_t time,
 
if (log_motion) {
printf("motion time: %d, x: %f, y: %f\n", time, x, y);
+   e->print_pointer_frame = true;
}
 
if (x > e->x && x < e->x + e->w)
-- 
2.7.3

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

[PATCH weston 3/3] eventdemo: do not print axis events if not requested

[Pekka Paalanen]

From: Pekka Paalanen 

Signed-off-by: Pekka Paalanen 
---
 clients/eventdemo.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index 38eb904..64b3d01 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -288,6 +288,9 @@ axis_source_handler(struct widget *widget, struct input 
*input,
const char *axis_source;
struct eventdemo *e = data;
 
+   if (!log_axis)
+   return;
+
e->print_pointer_frame = true;
 
switch (source) {
@@ -315,6 +318,9 @@ axis_stop_handler(struct widget *widget, struct input 
*input,
 {
struct eventdemo *e = data;
 
+   if (!log_axis)
+   return;
+
e->print_pointer_frame = true;
printf("axis stop time: %d, axis: %s\n",
   time,
@@ -328,6 +334,9 @@ axis_discrete_handler(struct widget *widget, struct input 
*input,
 {
struct eventdemo *e = data;
 
+   if (!log_axis)
+   return;
+
e->print_pointer_frame = true;
printf("axis discrete axis: %d value: %d\n", axis, discrete);
 }
-- 
2.7.3

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

[PATCH weston 2/3] eventdemo: use zalloc

[Pekka Paalanen]

From: Pekka Paalanen 

Zero-initialize the struct, just in case.

Signed-off-by: Pekka Paalanen 
---
 clients/eventdemo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clients/eventdemo.c b/clients/eventdemo.c
index f1558d2..38eb904 100644
--- a/clients/eventdemo.c
+++ b/clients/eventdemo.c
@@ -373,7 +373,7 @@ eventdemo_create(struct display *d)
 {
struct eventdemo *e;
 
-   e = malloc(sizeof (struct eventdemo));
+   e = zalloc(sizeof (struct eventdemo));
if (e == NULL)
return NULL;
 
-- 
2.7.3

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

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

[Pekka Paalanen]

On Fri, 29 Apr 2016 15:40:35 -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.
> 
> With the use_current_mode moved into the main config class, the
> drm_config wrapper is redundant.  Dropping it helps make the drm backend
> config initialization more consistent with the other backends.
> 
> Also, enforce destruction of the backend config object after
> initialization.  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 
> Reviewed-by: Pekka Paalanen 
> 
> ---
> v6:
>  - Drop use of drm_config config wrapper
> v7:
>  - Update to master
>  - Put backend configs on stack instead of zalloc()
>  - Enforce destruction of backend config object
>(Squashed patch as requested by pq)
> 
>  src/compositor-drm.c | 24 +++-
>  src/compositor-drm.h |  3 ++-
>  src/main.c   | 46 --
>  3 files changed, 33 insertions(+), 40 deletions(-)

Hi,

I decided to do some cleaning up here, and squashed these two patches.
It was getting annoying to review one patch and then see the follow-up
in the same series void some of the earlier comments that would have
caused a reject.

To put things short, pushed:
   59987fa..1c0e40d  master -> master

I also wrote the commit message for this patch from scratch. I do not
recall any of the conversion patches before this one to actually
document *why* we are doing this. This and other changes you can find
listed upstream. I thought I won't bother you with yet another round,
but just fix what I thought was important at the moment and push it.

Let's deal with any comments and fallout in follow-ups.

Thank you Bryce for picking this up, and Benoit too.


Thanks,
pq


pgpBUJ5AJqUck.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 v7 2/3] drm: port the drm backend to the new init api

[Pekka Paalanen]

On Sat, 30 Apr 2016 11:35:22 +0200
Benoit Gschwind  wrote:

> Hello Bryce,
> 
> I have some comments after a trivial rebase.
> 
> Le 30/04/2016 00:40, Bryce Harrington a écrit :
> > From: Giulio Camuffo 
> > 
> > Signed-off-by: Bryce Harrington 
> > Reviewed-by: Quentin Glidic 
> > Acked-by: Pekka Paalanen 
> > Tested-by: Benoit Gschwind 
> > 
> > Signed-off-by: Bryce Harrington 
> > ---
> > 
> > v5:
> >   - Update to reflect format rename to gdb_format
> >   - Initialize width/height (suggested by pq)
> >   - squash drm structure versioning (suggested by pq)
> > v6:
> >   - Fix gcc warning about missing braces.  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.)
> >   - Code and comments reformatting for consistency with other backend
> > configs
> >   - Don't use underscore prefix in header guard
> >   - Add stub config_init_to_defaults()
> >   - Define the version number in the header
> >   - Allocate config on stack
> > v7:
> >   - Update to master
> > 
> >  Makefile.am  |   3 +
> >  src/compositor-drm.c | 212 
> > +--
> >  src/compositor-drm.h | 126 ++
> >  src/compositor.h |   2 -
> >  src/main.c   |  98 +++-
> >  5 files changed, 311 insertions(+), 130 deletions(-)
> >  create mode 100644 src/compositor-drm.h

> >  
> > -   ec = weston_compositor_create(display, NULL);
> > +   ec = weston_compositor_create(display, config);  
> 
> This modification grabbed my attention. I think this is a bad choice. If
> a backend need the configuration file structure, he should not use this
> place to store it. The proper place, imo, is within the backend
> structure that store others data about the backend. That also mean the
> structure must be passed to the backend via the configuration structure.
> And finally, as other backend often does not need to keep the
> configuration file, the configuration should be copied in the case of
> drm and freed as soon as it is not useful anymore.

Hi,

that particular thing has cought my eye every time this patch has been
posted, and every time I have to remind myself, that the argument to
weston_compositor_create() is void *user_data.

The user_data will not be used by any backends - and they could not use
a weston_config anyway. In libweston, weston_config does not exist.
Also the backends won't touch user_data, they don't know what it is.

It *is* used in drm_configure_output() where it is retrieved with
weston_compositor_get_user_data(). This code is in main.c so it's fine.

The only surprise here is that the weston_compositor user_data is just
the weston_config, but once you get over that, it is ok.

> 
> In more general manner, the following callback has a useless signature:
> 
> drm_configure_output(struct weston_compositor *c,
>struct weston_drm_backend_config *backend_config,
>const char *name,
>struct weston_drm_backend_output_config *config)
> 
> It should take at less a void * as user data, the one you provided
> within the configuration of the backend. Passing the full configuration
> structure does look useless.

weston_compositor has user_data and is already passed in, so neither
backend_config or a user_data is absolutely necessary in the callback
signature.

Passing backend_config may actually be harmful, but the following patch
in this series changes it again.

However, it doesn't matter much at this point. I'm sure we will be
revisiting this later. Right now the important thing is to remove all
weston_config usage from the backends.


Thanks,
pq


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

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Pekka Paalanen]

On Tue, 10 May 2016 17:42:59 +0800
Jonas Ådahl  wrote:

> On Tue, May 10, 2016 at 11:19:29AM +0300, Pekka Paalanen wrote:
> > On Mon, 9 May 2016 07:58:32 -0500
> > Yong Bakos  wrote:
> >   
> > > Hi Pekka,
> > > Two minor nits in the description, noted inline below.
> > > 
> > > yong
> > > 
> > > On May 9, 2016, at 6:45 AM, Pekka Paalanen  wrote:  
> > > > 
> > > > From: Pekka Paalanen 
> > > > 
> > > > The existing specification was not explicitly clear on when
> > > > wl_subcompositor.get_subsurface request actually adds the sub-surface to
> > > > the parent in the compositor's scenegraph. The implicit assumption was
> > > > that this happens immediately, but it was not written anywhere.
> > > > 
> > > > If it happens immediately, the client doing things in a wrong order may
> > > > cause a glitch on screen. Particularly, if the wl_surface B that is
> > > > going to be a sub-surface for wl_surface A (the parent) already has a
> > > > buffer committed, and the parent surface is mapped, then get_subsurface
> > > > will (may?) cause wl_surface B to become mapped immediately. That leaves
> > > > no time to set up the sub-surface z-order or position before mapping,
> > > > hence there can be a visible glitch.
> > > > 
> > > > The way to avoid that, given that the parent surface is mapped, is to
> > > > not commit a buffer to wl_surface B until all the sub-surface setup is
> > > > done.
> > > > 
> > > > However, doing the sub-surface setup always requires a wl_surface.commit
> > > > on the parent surface unless the defaults happen to be correct.
> > > > 
> > > > To make setting up a subsurface slightly easier by removing one
> > > > possibility for a glitch, this patch amends the specification to require
> > > > a wl_surface.commit on the parent surface for get_subsurface to
> > > > complete. The sub-surface cannot become mapped before a parent commit.
> > > > 
> > > > This change may break existing clients that relied on the glitchy
> > > > sequence to not need a parent surface commit to map the sub-surface.
> > > > However, presumably all uses would at least issue a
> > > > wl_subsurface.set_position, which requires a parent surface commit to
> > > > apply. That would guarantee that there is a parent surface commit after
> > > > get_subsurface, and so reduces the chances of breaking anything.
> > > > 
> > > > In other cases, this change may simply remove a possibility for the
> > > > glitch.
> > > > 
> > > > This patch also adds a note about changing wl_surface.commit behaviour
> > > > on wl_subcompositor.get_subsurface. (That could be a separate patch.)

> > > > +
> > > > +   This request modifies the behaviour of wl_surface.commit 
> > > > request on
> > > 
> > > requests  
> > 
> > "request" is used as a noun here and there is only one, so I think it's
> > correct as is.
> > 
> > Or which one did you mean? I think the latter is also singular, but I
> > was thinking in interface terms, not as "from now on commits will
> > behave differently" which would be true too, thinking in runtime terms.
> > 
> > Alternative suggestions?  
> 
> It seems to be missing a 'the', as in, it should be:
> 
> "This request modifies the behaviour of the wl_surface.commit request
> on the sub-surface.."
> 
> or simply without the second "request" at all, as in:
> 
> "This request modifies the behaviour of wl_surface.commit on the
> sub-surface, ..."

I'll go with the latter one, thanks,
pq

> 
> 
> Jonas
> 
> > 
> > 
> > Thanks,
> > pq
> >   
> > > > +   the sub-surface, see the documentation on wl_subsurface 
> > > > interface.
> > > >   
> > > > 


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

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Martin Graesslin]

Looks good to me, thanks for addressing this.

Cheers,
Martin G.

On Monday, May 9, 2016 2:45:05 PM CEST Pekka Paalanen wrote:
> From: Pekka Paalanen 
> 
> The existing specification was not explicitly clear on when
> wl_subcompositor.get_subsurface request actually adds the sub-surface to
> the parent in the compositor's scenegraph. The implicit assumption was
> that this happens immediately, but it was not written anywhere.
> 
> If it happens immediately, the client doing things in a wrong order may
> cause a glitch on screen. Particularly, if the wl_surface B that is
> going to be a sub-surface for wl_surface A (the parent) already has a
> buffer committed, and the parent surface is mapped, then get_subsurface
> will (may?) cause wl_surface B to become mapped immediately. That leaves
> no time to set up the sub-surface z-order or position before mapping,
> hence there can be a visible glitch.
> 
> The way to avoid that, given that the parent surface is mapped, is to
> not commit a buffer to wl_surface B until all the sub-surface setup is
> done.
> 
> However, doing the sub-surface setup always requires a wl_surface.commit
> on the parent surface unless the defaults happen to be correct.
> 
> To make setting up a subsurface slightly easier by removing one
> possibility for a glitch, this patch amends the specification to require
> a wl_surface.commit on the parent surface for get_subsurface to
> complete. The sub-surface cannot become mapped before a parent commit.
> 
> This change may break existing clients that relied on the glitchy
> sequence to not need a parent surface commit to map the sub-surface.
> However, presumably all uses would at least issue a
> wl_subsurface.set_position, which requires a parent surface commit to
> apply. That would guarantee that there is a parent surface commit after
> get_subsurface, and so reduces the chances of breaking anything.
> 
> In other cases, this change may simply remove a possibility for the
> glitch.
> 
> This patch also adds a note about changing wl_surface.commit behaviour
> on wl_subcompositor.get_subsurface. (That could be a separate patch.)
> 
> The behaviour of wl_subsurface.destroy remains as specified, even though
> it is now slightly asymmetrical to get_subsurface. This is emphasized by
> adding the word "immediately". The effects of destruction were already
> explicitly documented, as is the way to achieve synchronized unmapping,
> so changing destruction behaviour would likely be more disruptive, and
> also open up more corner cases (what would happen between destroy and
> unmapping?).
> 
> Bug: https://phabricator.freedesktop.org/T7358
> Cc: Martin Gräßlin 
> Cc: Jonas Ådahl 
> Cc: Chris Michael 
> Signed-off-by: Pekka Paalanen 
> ---
>  protocol/wayland.xml | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 92e3f43..1546b46 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -2487,6 +2487,14 @@
>   The to-be sub-surface must not already have another role, and it
>   must not have an existing wl_subsurface object. Otherwise a protocol
>   error is raised.
> +
> + Adding sub-surfaces to a parent is a double-buffered operation on the
> + parent (see wl_surface.commit). The effect of adding a sub-surface
> + becomes visible on the next time the state of the parent surface is
> + applied.
> +
> + This request modifies the behaviour of wl_surface.commit request on
> + the sub-surface, see the documentation on wl_subsurface interface.
>
> 
> @@ -2557,7 +2565,7 @@
>   that was turned into a sub-surface with a
>   wl_subcompositor.get_subsurface request. The wl_surface's association
>   to the parent is deleted, and the wl_surface loses its role as
> - a sub-surface. The wl_surface is unmapped.
> + a sub-surface. The wl_surface is unmapped immediately.
>
>  



signature.asc
Description: This is a digitally signed message part.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols, weston v3 0/17] Stabilize wl_scaler as wp_viewporter

[Pekka Paalanen]

On Fri, 6 May 2016 15:07:19 +0300
Pekka Paalanen  wrote:

> On Thu, 5 May 2016 15:46:46 -0700
> Bryce Harrington  wrote:
> 
> > On Wed, May 04, 2016 at 05:33:10PM -0700, Bryce Harrington wrote:  
> > > On Tue, Apr 26, 2016 at 03:50:52PM +0300, Pekka Paalanen wrote:
> > > > From: Pekka Paalanen 
> > > > 
> > > > Hi,
> > > > 
> > > > here is the v3 of the stabilization series, which I hope to the final 
> > > > to be
> > > > merged.
> > > > 
> > > > The wayland-protocols patches are essentially the same as v2, except few
> > > > cosmetic changes as suggested by review comments. There are mentioned 
> > > > in the
> > > > review log in each patch, if there were any.
> > > > 
> > > > The weston patches are v3 too, though v2 was never posted. The changes 
> > > > to v1
> > > > are:
> > > > - patches 6-7 are new (simple preparation)
> > > > - patches 8-12 are the same as v1
> > > > - patches 13-17 are new, accounting for the spec changes from
> > > >   wayland-protocols v1
> > > > 
> > > > Note, that there are now tests for the wp_viewporter API. \o/
> > > > 
> > > > 
> > > > Wayland-protocols:
> > > > 
> > > > Pekka Paalanen (5):
> > > >   stable: add viewporter draft
> > > >   stable/viewporter: remove wp_viewport.set request
> > > >   stable/viewporter: rename and build
> > > >   stable/viewporter: rephrase a wp_viewport paragraph
> > > >   stable/viewporter: add more error cases
> > > > 
> > > >  Makefile.am  |   1 +
> > > >  stable/viewporter/README |   7 ++
> > > >  stable/viewporter/viewporter.xml | 189 
> > > > +++
> > > >  3 files changed, 197 insertions(+)
> > > >  create mode 100644 stable/viewporter/README
> > > >  create mode 100644 stable/viewporter/viewporter.xml
> > > 
> > > For landing these 5 wayland-protocol patches, either as stable or
> > > unstable, as Jonas decides:
> > > 
> > >   Acked-by: Bryce Harrington   
> 
> Recorded.

Hi,

the wayland-protocols patches are now pushed:
   cc276df..83bdaa5  master -> master

Now we just need a wayland-protocols release. We should have a couple
of days for the last minute "oops" just in case.


> > >
> > > > Weston:
> > > > 
> > > > Pekka Paalanen (12):
> > > >   compositor: constify weston_surface_build_buffer_matrix()
> > > >   compositor: refactor into convert_size_by_transform_scale()
> > > >   compositor: migrate to stable viewporter.xml
> > > >   compositor: rename scaler to viewport(er)
> > > >   clients/scaler: migrate to wp_viewporter
> > > >   clients/simple-damage: migrate to wp_viewporter
> > > >   protocol: remove scaler.xml
> > > >   compositor: fix wp_viewport use after free
> > > >   compositor: check viewport source rect validity
> > > >   compositor: check viewport dst size validity
> > > >   compositor: fix wp_viewport.set_source errors
> > > >   tests: add wp_viewporter tests
> > 
> > The first two patches in this set don't depend on the protocol and look
> > fine to land during beta.  The rest I'm not sure about, they're a bit
> > more than a mere rename of the protocol and add functionality.  I don't
> > have anything against them but wouldn't want to land them on my R-b
> > alone, and unless they're particularly urgent it would be much more
> > comfortable to land them post-release.  I reviewed all the patches and
> > aside from the nitpicks already mentioned, for purposes of landing post
> > release you can consider them:
> > 
> > Reviewed-by: Bryce Harrington   
> 
> Recorded.
> 
> Yes, they missed 1.11 now, will be for 1.12, expect the first two I
> already pushed with your reviews.

This still holds, weston patches won't land until 1.11 is out.


Thanks,
pq

> > > >  Makefile.am |  27 ++-
> > > >  clients/scaler.c|  43 ++--
> > > >  clients/simple-damage.c |  32 +--
> > > >  configure.ac|   2 +
> > > >  protocol/scaler.xml | 208 --
> > > >  src/compositor.c| 343 +++---
> > > >  src/compositor.h|   5 +-
> > > >  tests/viewporter-test.c | 553 
> > > > 
> > > >  8 files changed, 823 insertions(+), 390 deletions(-)
> > > >  delete mode 100644 protocol/scaler.xml
> > > >  create mode 100644 tests/viewporter-test.c
> > > >   



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

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Jonas Ådahl]

On Tue, May 10, 2016 at 11:19:29AM +0300, Pekka Paalanen wrote:
> On Mon, 9 May 2016 07:58:32 -0500
> Yong Bakos  wrote:
> 
> > Hi Pekka,
> > Two minor nits in the description, noted inline below.
> > 
> > yong
> > 
> > On May 9, 2016, at 6:45 AM, Pekka Paalanen  wrote:
> > > 
> > > From: Pekka Paalanen 
> > > 
> > > The existing specification was not explicitly clear on when
> > > wl_subcompositor.get_subsurface request actually adds the sub-surface to
> > > the parent in the compositor's scenegraph. The implicit assumption was
> > > that this happens immediately, but it was not written anywhere.
> > > 
> > > If it happens immediately, the client doing things in a wrong order may
> > > cause a glitch on screen. Particularly, if the wl_surface B that is
> > > going to be a sub-surface for wl_surface A (the parent) already has a
> > > buffer committed, and the parent surface is mapped, then get_subsurface
> > > will (may?) cause wl_surface B to become mapped immediately. That leaves
> > > no time to set up the sub-surface z-order or position before mapping,
> > > hence there can be a visible glitch.
> > > 
> > > The way to avoid that, given that the parent surface is mapped, is to
> > > not commit a buffer to wl_surface B until all the sub-surface setup is
> > > done.
> > > 
> > > However, doing the sub-surface setup always requires a wl_surface.commit
> > > on the parent surface unless the defaults happen to be correct.
> > > 
> > > To make setting up a subsurface slightly easier by removing one
> > > possibility for a glitch, this patch amends the specification to require
> > > a wl_surface.commit on the parent surface for get_subsurface to
> > > complete. The sub-surface cannot become mapped before a parent commit.
> > > 
> > > This change may break existing clients that relied on the glitchy
> > > sequence to not need a parent surface commit to map the sub-surface.
> > > However, presumably all uses would at least issue a
> > > wl_subsurface.set_position, which requires a parent surface commit to
> > > apply. That would guarantee that there is a parent surface commit after
> > > get_subsurface, and so reduces the chances of breaking anything.
> > > 
> > > In other cases, this change may simply remove a possibility for the
> > > glitch.
> > > 
> > > This patch also adds a note about changing wl_surface.commit behaviour
> > > on wl_subcompositor.get_subsurface. (That could be a separate patch.)
> > > 
> > > The behaviour of wl_subsurface.destroy remains as specified, even though
> > > it is now slightly asymmetrical to get_subsurface. This is emphasized by
> > > adding the word "immediately". The effects of destruction were already
> > > explicitly documented, as is the way to achieve synchronized unmapping,
> > > so changing destruction behaviour would likely be more disruptive, and
> > > also open up more corner cases (what would happen between destroy and
> > > unmapping?).
> > > 
> > > Bug: https://phabricator.freedesktop.org/T7358
> > > Cc: Martin Gräßlin 
> > > Cc: Jonas Ådahl 
> > > Cc: Chris Michael 
> > > Signed-off-by: Pekka Paalanen 
> > > ---
> > > protocol/wayland.xml | 10 +-
> > > 1 file changed, 9 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > > index 92e3f43..1546b46 100644
> > > --- a/protocol/wayland.xml
> > > +++ b/protocol/wayland.xml
> > > @@ -2487,6 +2487,14 @@
> > >   The to-be sub-surface must not already have another role, and it
> > >   must not have an existing wl_subsurface object. Otherwise a protocol
> > >   error is raised.
> > > +
> > > + Adding sub-surfaces to a parent is a double-buffered operation on the
> > > + parent (see wl_surface.commit). The effect of adding a sub-surface
> > > + becomes visible on the next time the state of the parent surface is  
> > 
> > visible the next time
> > 
> 
> Yes.
> 
> > > + applied.
> > > +
> > > + This request modifies the behaviour of wl_surface.commit request on  
> > 
> > requests
> 
> "request" is used as a noun here and there is only one, so I think it's
> correct as is.
> 
> Or which one did you mean? I think the latter is also singular, but I
> was thinking in interface terms, not as "from now on commits will
> behave differently" which would be true too, thinking in runtime terms.
> 
> Alternative suggestions?

It seems to be missing a 'the', as in, it should be:

"This request modifies the behaviour of the wl_surface.commit request
on the sub-surface.."

or simply without the second "request" at all, as in:

"This request modifies the behaviour of wl_surface.commit on the
sub-surface, ..."


Jonas

> 
> 
> Thanks,
> pq
> 
> > > + the sub-surface, see the documentation on wl_subsurface interface.
> > >   
> > > 
> > >> > @@ -2557,7 +2565,7 @@
> > >   that was turned into a 

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Jonas Ådahl]

On Tue, May 10, 2016 at 11:27:25AM +0300, Pekka Paalanen wrote:
> On Tue, 10 May 2016 11:43:04 +0800
> Jonas Ådahl  wrote:
> 
> > On Mon, May 09, 2016 at 02:45:05PM +0300, Pekka Paalanen wrote:
> > > From: Pekka Paalanen 
> > > 
> > > The existing specification was not explicitly clear on when
> > > wl_subcompositor.get_subsurface request actually adds the sub-surface to
> > > the parent in the compositor's scenegraph. The implicit assumption was
> > > that this happens immediately, but it was not written anywhere.
> > > 
> > > If it happens immediately, the client doing things in a wrong order may
> > > cause a glitch on screen. Particularly, if the wl_surface B that is
> > > going to be a sub-surface for wl_surface A (the parent) already has a
> > > buffer committed, and the parent surface is mapped, then get_subsurface
> > > will (may?) cause wl_surface B to become mapped immediately. That leaves
> > > no time to set up the sub-surface z-order or position before mapping,
> > > hence there can be a visible glitch.
> > > 
> > > The way to avoid that, given that the parent surface is mapped, is to
> > > not commit a buffer to wl_surface B until all the sub-surface setup is
> > > done.
> > > 
> > > However, doing the sub-surface setup always requires a wl_surface.commit
> > > on the parent surface unless the defaults happen to be correct.
> > > 
> > > To make setting up a subsurface slightly easier by removing one
> > > possibility for a glitch, this patch amends the specification to require
> > > a wl_surface.commit on the parent surface for get_subsurface to
> > > complete. The sub-surface cannot become mapped before a parent commit.
> > > 
> > > This change may break existing clients that relied on the glitchy
> > > sequence to not need a parent surface commit to map the sub-surface.
> > > However, presumably all uses would at least issue a
> > > wl_subsurface.set_position, which requires a parent surface commit to
> > > apply. That would guarantee that there is a parent surface commit after
> > > get_subsurface, and so reduces the chances of breaking anything.
> > > 
> > > In other cases, this change may simply remove a possibility for the
> > > glitch.
> > > 
> > > This patch also adds a note about changing wl_surface.commit behaviour
> > > on wl_subcompositor.get_subsurface. (That could be a separate patch.)
> > > 
> > > The behaviour of wl_subsurface.destroy remains as specified, even though
> > > it is now slightly asymmetrical to get_subsurface. This is emphasized by
> > > adding the word "immediately". The effects of destruction were already
> > > explicitly documented, as is the way to achieve synchronized unmapping,
> > > so changing destruction behaviour would likely be more disruptive, and
> > > also open up more corner cases (what would happen between destroy and
> > > unmapping?).
> > > 
> > > Bug: https://phabricator.freedesktop.org/T7358
> > > Cc: Martin Gräßlin 
> > > Cc: Jonas Ådahl 
> > > Cc: Chris Michael 
> > > Signed-off-by: Pekka Paalanen   
> > 
> > Reviewed-by: Jonas Ådahl 
> > 
> > It would be very nice to have a test for this somewhere. It's hard to
> > test automatically, since its the output from the renderer that this
> > effects, and we can't easily test that, but at least a manually
> > checked test.
> 
> Yes, I will need to write one for fixing weston anyway.
> 
> 
> Considering that the weston fixes and tests might not make it in 1.11
> release, should this patch be merged for Wayland 1.11 or not?

That is a good question. Considering it is unclear (while still
unlikely) if this will actually break anything, it might be a good idea
to be a bit conservative here, and it would be good with an
implementation to just have tested, while having weston implement it
according to the specification released along side it.

It is not a strong opinion though.


Jonas

> 
> 
> Thanks,
> pq
> 
> > > ---
> > >  protocol/wayland.xml | 10 +-
> > >  1 file changed, 9 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > > index 92e3f43..1546b46 100644
> > > --- a/protocol/wayland.xml
> > > +++ b/protocol/wayland.xml
> > > @@ -2487,6 +2487,14 @@
> > >   The to-be sub-surface must not already have another role,
> > > and it must not have an existing wl_subsurface object. Otherwise a
> > > protocol error is raised.
> > > +
> > > + Adding sub-surfaces to a parent is a double-buffered
> > > operation on the
> > > + parent (see wl_surface.commit). The effect of adding a
> > > sub-surface
> > > + becomes visible on the next time the state of the parent
> > > surface is
> > > + applied.
> > > +
> > > + This request modifies the behaviour of wl_surface.commit
> > > request on
> > > + the sub-surface, see the documentation on wl_subsurface
> > > interface. 
> > >  
> > > > > 

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Pekka Paalanen]

On Mon, 09 May 2016 11:48:07 -0500
Derek Foreman  wrote:

> On 09/05/16 06:45 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen 
> > 
> > The existing specification was not explicitly clear on when
> > wl_subcompositor.get_subsurface request actually adds the sub-surface to
> > the parent in the compositor's scenegraph. The implicit assumption was
> > that this happens immediately, but it was not written anywhere.  
> 
> Was weston implemented with this assumption?

I think I did, yes.

But weston also has another bug:
https://bugs.freedesktop.org/show_bug.cgi?id=94735

Weston needs fixing and verifying in any case.
https://phabricator.freedesktop.org/T7359

> > If it happens immediately, the client doing things in a wrong order may
> > cause a glitch on screen. Particularly, if the wl_surface B that is
> > going to be a sub-surface for wl_surface A (the parent) already has a
> > buffer committed, and the parent surface is mapped, then get_subsurface
> > will (may?) cause wl_surface B to become mapped immediately. That leaves
> > no time to set up the sub-surface z-order or position before mapping,
> > hence there can be a visible glitch.  
> 
> It would be really cool to have a test for this glitch in weston. :)

Yeah, and I'd love to write that test, but we'll see when I can get to
it and fixing weston. It will need to use screenshot-based testing,
where the baseline test is racy (cursor may or may not be in the
picture).

> Anyway,
> Reviewed-by: Derek Foreman 


Thanks,
pq

> > The way to avoid that, given that the parent surface is mapped, is to
> > not commit a buffer to wl_surface B until all the sub-surface setup is
> > done.
> > 
> > However, doing the sub-surface setup always requires a wl_surface.commit
> > on the parent surface unless the defaults happen to be correct.
> > 
> > To make setting up a subsurface slightly easier by removing one
> > possibility for a glitch, this patch amends the specification to require
> > a wl_surface.commit on the parent surface for get_subsurface to
> > complete. The sub-surface cannot become mapped before a parent commit.
> > 
> > This change may break existing clients that relied on the glitchy
> > sequence to not need a parent surface commit to map the sub-surface.
> > However, presumably all uses would at least issue a
> > wl_subsurface.set_position, which requires a parent surface commit to
> > apply. That would guarantee that there is a parent surface commit after
> > get_subsurface, and so reduces the chances of breaking anything.
> > 
> > In other cases, this change may simply remove a possibility for the
> > glitch.
> > 
> > This patch also adds a note about changing wl_surface.commit behaviour
> > on wl_subcompositor.get_subsurface. (That could be a separate patch.)
> > 
> > The behaviour of wl_subsurface.destroy remains as specified, even though
> > it is now slightly asymmetrical to get_subsurface. This is emphasized by
> > adding the word "immediately". The effects of destruction were already
> > explicitly documented, as is the way to achieve synchronized unmapping,
> > so changing destruction behaviour would likely be more disruptive, and
> > also open up more corner cases (what would happen between destroy and
> > unmapping?).
> > 
> > Bug: https://phabricator.freedesktop.org/T7358
> > Cc: Martin Gräßlin 
> > Cc: Jonas Ådahl 
> > Cc: Chris Michael 
> > Signed-off-by: Pekka Paalanen 
> > ---
> >  protocol/wayland.xml | 10 +-
> >  1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 92e3f43..1546b46 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -2487,6 +2487,14 @@
> > The to-be sub-surface must not already have another role, and it
> > must not have an existing wl_subsurface object. Otherwise a protocol
> > error is raised.
> > +
> > +   Adding sub-surfaces to a parent is a double-buffered operation on the
> > +   parent (see wl_surface.commit). The effect of adding a sub-surface
> > +   becomes visible on the next time the state of the parent surface is
> > +   applied.
> > +
> > +   This request modifies the behaviour of wl_surface.commit request on
> > +   the sub-surface, see the documentation on wl_subsurface interface.
> >
> >  
> > > @@ -2557,7 +2565,7 @@
> > that was turned into a sub-surface with a
> > wl_subcompositor.get_subsurface request. The wl_surface's association
> > to the parent is deleted, and the wl_surface loses its role as
> > -   a sub-surface. The wl_surface is unmapped.
> > +   a sub-surface. The wl_surface is unmapped immediately.
> >
> >  
> >  
> >   
> 



pgpk4Kgrg54wS.pgp
Description: OpenPGP digital signature
___
wayland-devel mailing list

Re: [PATCH wayland] protocol: make get_subsurface double-buffered

[Pekka Paalanen]

On Mon, 9 May 2016 07:58:32 -0500
Yong Bakos  wrote:

> Hi Pekka,
> Two minor nits in the description, noted inline below.
> 
> yong
> 
> On May 9, 2016, at 6:45 AM, Pekka Paalanen  wrote:
> > 
> > From: Pekka Paalanen 
> > 
> > The existing specification was not explicitly clear on when
> > wl_subcompositor.get_subsurface request actually adds the sub-surface to
> > the parent in the compositor's scenegraph. The implicit assumption was
> > that this happens immediately, but it was not written anywhere.
> > 
> > If it happens immediately, the client doing things in a wrong order may
> > cause a glitch on screen. Particularly, if the wl_surface B that is
> > going to be a sub-surface for wl_surface A (the parent) already has a
> > buffer committed, and the parent surface is mapped, then get_subsurface
> > will (may?) cause wl_surface B to become mapped immediately. That leaves
> > no time to set up the sub-surface z-order or position before mapping,
> > hence there can be a visible glitch.
> > 
> > The way to avoid that, given that the parent surface is mapped, is to
> > not commit a buffer to wl_surface B until all the sub-surface setup is
> > done.
> > 
> > However, doing the sub-surface setup always requires a wl_surface.commit
> > on the parent surface unless the defaults happen to be correct.
> > 
> > To make setting up a subsurface slightly easier by removing one
> > possibility for a glitch, this patch amends the specification to require
> > a wl_surface.commit on the parent surface for get_subsurface to
> > complete. The sub-surface cannot become mapped before a parent commit.
> > 
> > This change may break existing clients that relied on the glitchy
> > sequence to not need a parent surface commit to map the sub-surface.
> > However, presumably all uses would at least issue a
> > wl_subsurface.set_position, which requires a parent surface commit to
> > apply. That would guarantee that there is a parent surface commit after
> > get_subsurface, and so reduces the chances of breaking anything.
> > 
> > In other cases, this change may simply remove a possibility for the
> > glitch.
> > 
> > This patch also adds a note about changing wl_surface.commit behaviour
> > on wl_subcompositor.get_subsurface. (That could be a separate patch.)
> > 
> > The behaviour of wl_subsurface.destroy remains as specified, even though
> > it is now slightly asymmetrical to get_subsurface. This is emphasized by
> > adding the word "immediately". The effects of destruction were already
> > explicitly documented, as is the way to achieve synchronized unmapping,
> > so changing destruction behaviour would likely be more disruptive, and
> > also open up more corner cases (what would happen between destroy and
> > unmapping?).
> > 
> > Bug: https://phabricator.freedesktop.org/T7358
> > Cc: Martin Gräßlin 
> > Cc: Jonas Ådahl 
> > Cc: Chris Michael 
> > Signed-off-by: Pekka Paalanen 
> > ---
> > protocol/wayland.xml | 10 +-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> > 
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 92e3f43..1546b46 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -2487,6 +2487,14 @@
> > The to-be sub-surface must not already have another role, and it
> > must not have an existing wl_subsurface object. Otherwise a protocol
> > error is raised.
> > +
> > +   Adding sub-surfaces to a parent is a double-buffered operation on the
> > +   parent (see wl_surface.commit). The effect of adding a sub-surface
> > +   becomes visible on the next time the state of the parent surface is  
> 
> visible the next time
> 

Yes.

> > +   applied.
> > +
> > +   This request modifies the behaviour of wl_surface.commit request on  
> 
> requests

"request" is used as a noun here and there is only one, so I think it's
correct as is.

Or which one did you mean? I think the latter is also singular, but I
was thinking in interface terms, not as "from now on commits will
behave differently" which would be true too, thinking in runtime terms.

Alternative suggestions?


Thanks,
pq

> > +   the sub-surface, see the documentation on wl_subsurface interface.
> >   
> > 
> >> @@ -2557,7 +2565,7 @@
> > that was turned into a sub-surface with a
> > wl_subcompositor.get_subsurface request. The wl_surface's association
> > to the parent is deleted, and the wl_surface loses its role as
> > -   a sub-surface. The wl_surface is unmapped.
> > +   a sub-surface. The wl_surface is unmapped immediately.
> >   
> > 
> > 
> > -- 
> > 2.7.3
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel  
> 



pgpu4nJkLjSwV.pgp
Description: OpenPGP