[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Git][xorg-team/wayland/wayland-protocols][debian-unstable] 9 commits: xdg-shell: forbid loops in set_parent

Title: GitLab

Héctor Orón Martínez pushed to branch debian-unstable at X Strike Force / wayland / wayland-protocols

Commits:

  • 53cd10ae
    by Simon Ser at 2022-09-17T08:49:35+02:00 
    xdg-shell: forbid loops in set_parent

These don't make sense. Add a protocol error for this case.

Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/105
  • b784987a
    by Isaac Freund at 2022-09-26T17:14:43+00:00 
    ext-session-lock: add note on client termination

See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/262

Signed-off-by: Isaac Freund <mail@isaacfreund.com>
  • dc625d5a
    by Simon Ser at 2022-10-03T20:46:21+00:00 
    ext-idle-notify: new protocol

This patch adds a new ext-idle-notify protocol. It allows clients to be
notified when the user is idle. Use-cases include e.g. power management
daemons.

This protocol is based on the org_kde_kwin_idle interface already being
used by KDE and wlroots compositors. The protocol has been sent to
wayland-protocols in 2015 [1]. This version renames and clarifies the
interfaces, and addresses the review comments.

[1]: https://lists.freedesktop.org/archives/wayland-devel/2015-December/026045.html

Signed-off-by: Simon Ser <contact@emersion.fr>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/8
Reviewed-by: David Edmundson <davidedmundson@kde.org>
  • c6052908
    by Emmanuel Gil Peyrot at 2022-10-03T22:51:02+02:00 
    staging/content-type: Content type hint support

This protocol lets clients advertise which kind of content they expect
to be displayed on a given surface, so that the compositor can make more
informed decisions about its behavior and output configuration.

Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Signed-off-by: Xaver Hugl <xaver.hugl@gmail.com>
  • 03ae934d
    by Simon Ser at 2022-10-03T22:58:13+02:00 
    build: alphabetically sort list of staging protocols

This helps with merge conflicts when a protocol is merged. This is
also more consistent with the other protocol lists above.

Signed-off-by: Simon Ser <contact@emersion.fr>
  • 115ba718
    by Daniel Stone at 2022-10-10T07:58:54+00:00 
    xdg-shell: ack_configure must be strictly monotonic

Clients must send ack_configure in a strictly monotonic order wrt
received configure events. It is an error to send an ack_configure
request for a configure event which was sent prior to the last
ack_configure for that surface, or to send multiple ack_configures for
the same configure event.

Weston and wlroots already use this interpretation, however Mutter and
KWayland are more lax and allow duplicates. This clarification tightens
the spec working to explicitly encode the Weston/wlroots behaviour.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Closes: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/21
  • e631010a
    by Jonas Ådahl at 2022-10-10T10:20:28+02:00 
    build: Bump version to 1.27

Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
  • 6f0b8f6f
    by Héctor Orón Martínez at 2022-10-14T18:13:09+02:00 
    Merge branch 'upstream-unstable' into debian-unstable
  • fa5bbec2
    by Héctor Orón Martínez at 2022-10-14T18:14:54+02:00 
    Release Debian version 1.27-1

Signed-off-by: Héctor Orón Martínez <zumbi@debian.org>

8 changed files:

Changes:

  • debian/changelog
    1 
    +wayland-protocols (1.27-1) unstable; urgency=medium
    2 
    +
    3 
    +  [ Debian Janitor ]
    4 
    +  * Bump debhelper from old 10 to 13.
    5 
    +  * Set debhelper-compat version in Build-Depends.
    6 
    +  * Re-export upstream signing key without extra signatures.
    7 
    +  * Update standards version to 4.6.0, no changes needed.
    8 
    +
    9 
    +  [ Héctor Orón Martínez ]
    10 
    +  * New upstream release
    11 
    +  * debian/watch: update to new upstream release site
    12 
    +
    13 
    + -- Héctor Orón Martínez <zumbi@debian.org>  Fri, 14 Oct 2022 18:14:50 +0200
    14 
    +
    1 15 
     wayland-protocols (1.26-1) unstable; urgency=medium
    2 16
    3 17 
       * New upstream release.

  • meson.build
    1 1 
     project('wayland-protocols',
    2 
    -	version: '1.26',
    2 
    +	version: '1.27',
    3 3 
     	meson_version: '>= 0.55.0',
    4 4 
     	license: 'MIT/Expat',
    5 5 
     )
    ... ... @@ -36,10 +36,12 @@ unstable_protocols = {
    36 36 
     }
    37 37
    38 38 
     staging_protocols = {
    39 
    -	'xdg-activation': ['v1'],
    39 
    +	'content-type': ['v1'],
    40 40 
     	'drm-lease': ['v1'],
    41 
    +	'ext-idle-notify': ['v1'],
    41 42 
     	'ext-session-lock': ['v1'],
    42 43 
     	'single-pixel-buffer': ['v1'],
    44 
    +	'xdg-activation': ['v1'],
    43 45 
     }
    44 46
    45 47 
     protocol_files = []

  • stable/xdg-shell/xdg-shell.xml
    ... ... @@ -454,6 +454,7 @@
    454 454 
           <entry name="not_constructed" value="1"/>
    455 455 
           <entry name="already_constructed" value="2"/>
    456 456 
           <entry name="unconfigured_buffer" value="3"/>
    457 
    +      <entry name="invalid_serial" value="4"/>
    457 458 
         </enum>
    458 459
    459 460 
         <request name="destroy" type="destructor">
    ... ... @@ -549,6 +550,17 @@
    549 550 
     	A client may send multiple ack_configure requests before committing, but
    550 551 
     	only the last request sent before a commit indicates which configure
    551 552 
     	event the client really is responding to.
    553 
    +
    554 
    +	Sending an ack_configure request consumes the serial number sent with
    555 
    +	the request, as well as serial numbers sent by all configure events
    556 
    +	sent on this xdg_surface prior to the configure event referenced by
    557 
    +	the committed serial.
    558 
    +
    559 
    +	It is an error to issue multiple ack_configure requests referencing a
    560 
    +	serial from the same configure event, or to issue an ack_configure
    561 
    +	request referencing a serial from a configure event issued before the
    562 
    +	event identified by the last ack_configure request for the same
    563 
    +	xdg_surface. Doing so will raise an invalid_serial error.
    552 564 
           </description>
    553 565 
           <arg name="serial" type="uint" summary="the serial from the configure event"/>
    554 566 
         </request>
    ... ... @@ -608,6 +620,8 @@
    608 620 
         <enum name="error">
    609 621 
           <entry name="invalid_resize_edge" value="0" summary="provided value is
    610 622 
             not a valid variant of the resize_edge enum"/>
    623 
    +      <entry name="invalid_parent" value="1"
    624 
    +        summary="invalid parent toplevel"/>
    611 625 
         </enum>
    612 626
    613 627 
         <request name="set_parent">
    ... ... @@ -628,6 +642,10 @@
    628 642 
     	the now-unmapped surface. If the now-unmapped surface has no parent,
    629 643 
     	its children's parent is unset. If the now-unmapped surface becomes
    630 644 
     	mapped again, its parent-child relationship is not restored.
    645 
    +
    646 
    +	The parent toplevel must not be one of the child toplevel's
    647 
    +	descendants, and the parent must be different from the child toplevel,
    648 
    +	otherwise the invalid_parent protocol error is raised.
    631 649 
           </description>
    632 650 
           <arg name="parent" type="object" interface="xdg_toplevel" allow-null="true"/>
    633 651 
         </request>

  • staging/content-type/README
    1 
    +Content type hint protocol
    2 
    +
    3 
    +Maintainers:
    4 
    +Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
    5 
    +Xaver Hugl <xaver.hugl@gmail.com>

  • staging/content-type/content-type-v1.xml
    1 
    +<?xml version="1.0" encoding="UTF-8"?>
    2 
    +<protocol name="content_type_v1">
    3 
    +  <copyright>
    4 
    +    Copyright © 2021 Emmanuel Gil Peyrot
    5 
    +    Copyright © 2022 Xaver Hugl
    6 
    +
    7 
    +    Permission is hereby granted, free of charge, to any person obtaining a
    8 
    +    copy of this software and associated documentation files (the "Software"),
    9 
    +    to deal in the Software without restriction, including without limitation
    10 
    +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
    11 
    +    and/or sell copies of the Software, and to permit persons to whom the
    12 
    +    Software is furnished to do so, subject to the following conditions:
    13 
    +
    14 
    +    The above copyright notice and this permission notice (including the next
    15 
    +    paragraph) shall be included in all copies or substantial portions of the
    16 
    +    Software.
    17 
    +
    18 
    +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    19 
    +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    20 
    +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
    21 
    +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    22 
    +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
    23 
    +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    24 
    +    DEALINGS IN THE SOFTWARE.
    25 
    +  </copyright>
    26 
    +
    27 
    +  <interface name="wp_content_type_manager_v1" version="1">
    28 
    +    <description summary="surface content type manager">
    29 
    +      This interface allows a client to describe the kind of content a surface
    30 
    +      will display, to allow the compositor to optimize its behavior for it.
    31 
    +
    32 
    +      Warning! The protocol described in this file is currently in the testing
    33 
    +      phase. Backward compatible changes may be added together with the
    34 
    +      corresponding interface version bump. Backward incompatible changes can
    35 
    +      only be done by creating a new major version of the extension.
    36 
    +    </description>
    37 
    +
    38 
    +    <request name="destroy" type="destructor">
    39 
    +      <description summary="destroy the content type manager object">
    40 
    +        Destroy the content type manager. This doesn't destroy objects created
    41 
    +        with the manager.
    42 
    +      </description>
    43 
    +    </request>
    44 
    +
    45 
    +    <enum name="error">
    46 
    +      <entry name="already_constructed" value="0"
    47 
    +             summary="wl_surface already has a content type object"/>
    48 
    +    </enum>
    49 
    +
    50 
    +    <request name="get_surface_content_type">
    51 
    +      <description summary="create a new toplevel decoration object">
    52 
    +        Create a new content type object associated with the given surface.
    53 
    +
    54 
    +        Creating a wp_content_type_v1 from a wl_surface which already has one
    55 
    +        attached is a client error: already_constructed.
    56 
    +      </description>
    57 
    +      <arg name="id" type="new_id" interface="wp_content_type_v1"/>
    58 
    +      <arg name="surface" type="object" interface="wl_surface"/>
    59 
    +    </request>
    60 
    +  </interface>
    61 
    +
    62 
    +  <interface name="wp_content_type_v1" version="1">
    63 
    +    <description summary="content type object for a surface">
    64 
    +      The content type object allows the compositor to optimize for the kind
    65 
    +      of content shown on the surface. A compositor may for example use it to
    66 
    +      set relevant drm properties like "content type".
    67 
    +
    68 
    +      The client may request to switch to another content type at any time.
    69 
    +      When the associated surface gets destroyed, this object becomes inert and
    70 
    +      the client should destroy it.
    71 
    +    </description>
    72 
    +
    73 
    +    <request name="destroy" type="destructor">
    74 
    +      <description summary="destroy the content type object">
    75 
    +        Switch back to not specifying the content type of this surface. This is
    76 
    +        equivalent to setting the content type to none, including double
    77 
    +        buffering semantics. See set_content_type for details.
    78 
    +      </description>
    79 
    +    </request>
    80 
    +
    81 
    +    <enum name="type">
    82 
    +      <description summary="possible content types">
    83 
    +        These values describe the available content types for a surface.
    84 
    +      </description>
    85 
    +      <entry name="none" value="0">
    86 
    +        <description summary="no content type applies">
    87 
    +          The content type none means that either the application has no data
    88 
    +          about the content type, or that the content doesn't fit into one of
    89 
    +          the other categories.
    90 
    +        </description>
    91 
    +      </entry>
    92 
    +      <entry name="photo" value="1">
    93 
    +        <description summary="photo content type">
    94 
    +          The content type photo describes content derived from digital still
    95 
    +          pictures and may be presented with minimal processing.
    96 
    +        </description>
    97 
    +      </entry>
    98 
    +      <entry name="video" value="2">
    99 
    +        <description summary="video content type">
    100 
    +          The content type video describes a video or animation and may be
    101 
    +          presented with more accurate timing to avoid stutter. Where scaling
    102 
    +          is needed, scaling methods more appropriate for video may be used.
    103 
    +        </description>
    104 
    +      </entry>
    105 
    +      <entry name="game" value="3">
    106 
    +        <description summary="game content type">
    107 
    +          The content type game describes a running game. Its content may be
    108 
    +          presented with reduced latency.
    109 
    +        </description>
    110 
    +      </entry>
    111 
    +    </enum>
    112 
    +
    113 
    +    <request name="set_content_type">
    114 
    +      <description summary="specify the content type">
    115 
    +        Set the surface content type. This informs the compositor that the
    116 
    +        client believes it is displaying buffers matching this content type.
    117 
    +
    118 
    +        This is purely a hint for the compositor, which can be used to adjust
    119 
    +        its behavior or hardware settings to fit the presented content best.
    120 
    +
    121 
    +        The content type is double-buffered state, see wl_surface.commit for
    122 
    +        details.
    123 
    +      </description>
    124 
    +      <arg name="content_type" type="uint" enum="content_type"
    125 
    +           summary="the content type"/>
    126 
    +    </request>
    127 
    +  </interface>
    128 
    +</protocol>

  • staging/ext-idle-notify/README
    1 
    +idle_notify protocol
    2 
    +
    3 
    +Maintainers:
    4 
    +Simon Ser <contact@emersion.fr>

  • staging/ext-idle-notify/ext-idle-notify-v1.xml
    1 
    +<?xml version="1.0" encoding="UTF-8"?>
    2 
    +<protocol name="ext_idle_notify_v1">
    3 
    +  <copyright>
    4 
    +    Copyright © 2015 Martin Gräßlin
    5 
    +    Copyright © 2022 Simon Ser
    6 
    +
    7 
    +    Permission is hereby granted, free of charge, to any person obtaining a
    8 
    +    copy of this software and associated documentation files (the "Software"),
    9 
    +    to deal in the Software without restriction, including without limitation
    10 
    +    the rights to use, copy, modify, merge, publish, distribute, sublicense,
    11 
    +    and/or sell copies of the Software, and to permit persons to whom the
    12 
    +    Software is furnished to do so, subject to the following conditions:
    13 
    +
    14 
    +    The above copyright notice and this permission notice (including the next
    15 
    +    paragraph) shall be included in all copies or substantial portions of the
    16 
    +    Software.
    17 
    +
    18 
    +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
    19 
    +    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
    20 
    +    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
    21 
    +    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
    22 
    +    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
    23 
    +    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
    24 
    +    DEALINGS IN THE SOFTWARE.
    25 
    +  </copyright>
    26 
    +
    27 
    +  <interface name="ext_idle_notifier_v1" version="1">
    28 
    +    <description summary="idle notification manager">
    29 
    +      This interface allows clients to monitor user idle status.
    30 
    +
    31 
    +      After binding to this global, clients can create ext_idle_notification_v1
    32 
    +      objects to get notified when the user is idle for a given amount of time.
    33 
    +    </description>
    34 
    +
    35 
    +    <request name="destroy" type="destructor">
    36 
    +      <description summary="destroy the manager">
    37 
    +        Destroy the manager object. All objects created via this interface
    38 
    +        remain valid.
    39 
    +      </description>
    40 
    +    </request>
    41 
    +
    42 
    +    <request name="get_idle_notification">
    43 
    +      <description summary="create a notification object">
    44 
    +        Create a new idle notification object.
    45 
    +
    46 
    +        The notification object has a minimum timeout duration and is tied to a
    47 
    +        seat. The client will be notified if the seat is inactive for at least
    48 
    +        the provided timeout. See ext_idle_notification_v1 for more details.
    49 
    +
    50 
    +        A zero timeout is valid and means the client wants to be notified as
    51 
    +        soon as possible when the seat is inactive.
    52 
    +      </description>
    53 
    +      <arg name="id" type="new_id" interface="ext_idle_notification_v1"/>
    54 
    +      <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
    55 
    +      <arg name="seat" type="object" interface="wl_seat"/>
    56 
    +    </request>
    57 
    +  </interface>
    58 
    +
    59 
    +  <interface name="ext_idle_notification_v1" version="1">
    60 
    +    <description summary="idle notification">
    61 
    +      This interface is used by the compositor to send idle notification events
    62 
    +      to clients.
    63 
    +
    64 
    +      Initially the notification object is not idle. The notification object
    65 
    +      becomes idle when no user activity has happened for at least the timeout
    66 
    +      duration, starting from the creation of the notification object. User
    67 
    +      activity may include input events or a presence sensor, but is
    68 
    +      compositor-specific. If an idle inhibitor is active (e.g. another client
    69 
    +      has created a zwp_idle_inhibitor_v1 on a visible surface), the compositor
    70 
    +      must not make the notification object idle.
    71 
    +
    72 
    +      When the notification object becomes idle, an idled event is sent. When
    73 
    +      user activity starts again, the notification object stops being idle,
    74 
    +      a resumed event is sent and the timeout is restarted.
    75 
    +    </description>
    76 
    +
    77 
    +    <request name="destroy" type="destructor">
    78 
    +      <description summary="destroy the notification object">
    79 
    +        Destroy the notification object.
    80 
    +      </description>
    81 
    +    </request>
    82 
    +
    83 
    +    <event name="idled">
    84 
    +      <description summary="notification object is idle">
    85 
    +        This event is sent when the notification object becomes idle.
    86 
    +
    87 
    +        It's a compositor protocol error to send this event twice without a
    88 
    +        resumed event in-between.
    89 
    +      </description>
    90 
    +    </event>
    91 
    +
    92 
    +    <event name="resumed">
    93 
    +      <description summary="notification object is no longer idle">
    94 
    +        This event is sent when the notification object stops being idle.
    95 
    +
    96 
    +        It's a compositor protocol error to send this event twice without an
    97 
    +        idled event in-between. It's a compositor protocol error to send this
    98 
    +        event prior to any idled event.
    99 
    +      </description>
    100 
    +    </event>
    101 
    +  </interface>
    102 
    +</protocol>

  • staging/ext-session-lock/ext-session-lock-v1.xml
    ... ... @@ -187,6 +187,14 @@
    187 187 
             It is a protocol error to make this request if the locked event has
    188 188 
             not been sent. In that case, the lock object may only be destroyed
    189 189 
             using the destroy request.
    190 
    +
    191 
    +        Note that a correct client that wishes to exit directly after unlocking
    192 
    +        the session must use the wl_display.sync request to ensure the server
    193 
    +        receives and processes the unlock_and_destroy request. Otherwise
    194 
    +        there is no guarantee that the server has unlocked the session due
    195 
    +        to the asynchronous nature of the Wayland protocol. For example,
    196 
    +        the server might terminate the client with a protocol error before
    197 
    +        it processes the unlock_and_destroy request.
    190 198 
           </description>
    191 199 
         </request>
    192 200 
       </interface>

    • —
    View it on GitLab.
    You're receiving this email because of your account on salsa.debian.org. Manage all notifications · Help

    Reply to: