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

[Git][xorg-team/wayland/wayland-protocols][upstream-unstable] 6 commits: alpha-modifier: update description summary for get_surface request

Title: GitLab

Dylan Aïssi pushed to branch upstream-unstable at X Strike Force / wayland / wayland-protocols

Commits:

  • 04b966f0
    by YaoBing Xiao at 2024-12-22T09:51:02+00:00 
    alpha-modifier: update description summary for get_surface request

Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>
  • 258d8f88
    by YaoBing Xiao at 2024-12-22T20:11:32+00:00 
    content-type: update description summary for get_surface_content_type request

Signed-off-by: YaoBing Xiao <xiaoyaobing@uniontech.com>
  • 20bcf732
    by James Ramsey at 2025-01-13T06:49:42-05:00 
    ext-idle-notify: Allow for the ignoring of idle inhibitors

Signed-off-by: James Ramsey <james.jehiel.ramsey@gmail.com>
  • bd6289c1
    by Simon Ser at 2025-01-21T08:13:12+00:00 
    linux-dmabuf: link to kernel docs

Replace the EGL links and AddFb2 reference with a link to the
kernel docs. The kernel docs explain all the subtleties of dmabuf
exchange, and already link to EGL (and more).

Signed-off-by: Simon Ser <contact@emersion.fr>
  • 18a0117b
    by Xaver Hugl at 2025-01-29T15:12:48+00:00 
    stable/linux-dmabuf: clarify when the plane_set protocol error is sent

Signed-off-by: Xaver Hugl <xaver.hugl@kde.org>
  • c7b582cb
    by Jonas Ådahl at 2025-01-30T19:42:36+08:00 
    build: Bump version to 1.40

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

5 changed files:

Changes:

  • meson.build
    1 1 
     project('wayland-protocols',
    2 
    -	version: '1.39',
    2 
    +	version: '1.40',
    3 3 
     	meson_version: '>= 0.58.0',
    4 4 
     	license: 'MIT/Expat',
    5 5 
     )

  • stable/linux-dmabuf/linux-dmabuf-v1.xml
    ... ... @@ -26,13 +26,11 @@
    26 26
    27 27 
       <interface name="zwp_linux_dmabuf_v1" version="5">
    28 28 
         <description summary="factory for creating dmabuf-based wl_buffers">
    29 
    -      Following the interfaces from:
    30 
    -      https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_image_dma_buf_import.txt
    31 
    -      https://www.khronos.org/registry/EGL/extensions/EXT/EGL_EXT_image_dma_buf_import_modifiers.txt
    32 
    -      and the Linux DRM sub-system's AddFb2 ioctl.
    33 
    -
    34 29 
           This interface offers ways to create generic dmabuf-based wl_buffers.
    35 30
    31 
    +      For more information about dmabuf, see:
    32 
    +      https://www.kernel.org/doc/html/next/userspace-api/dma-buf-alloc-exchange.html
    33 
    +
    36 34 
           Clients can use the get_surface_feedback request to get dmabuf feedback
    37 35 
           for a particular surface. If the client wants to retrieve feedback not
    38 36 
           tied to a surface, they can use the get_default_feedback request.
    ... ... @@ -201,7 +199,9 @@
    201 199 
           You must use consecutive plane indices ('plane_idx' argument for 'add')
    202 200 
           from zero to the number of planes used by the drm_fourcc format code.
    203 201 
           All planes required by the format must be given exactly once, but can
    204 
    -      be given in any order. Each plane index can be set only once.
    202 
    +      be given in any order. Each plane index can only be set once; subsequent
    203 
    +      calls with a plane index which has already been set will result in a
    204 
    +      plane_set error being generated.
    205 205 
         </description>
    206 206
    207 207 
         <enum name="error">

  • staging/alpha-modifier/alpha-modifier-v1.xml
    ... ... @@ -48,7 +48,7 @@
    48 48 
         </enum>
    49 49
    50 50 
         <request name="get_surface">
    51 
    -      <description summary="create a new toplevel decoration object">
    51 
    +      <description summary="create a new alpha modifier surface object">
    52 52 
             Create a new alpha modifier surface object associated with the
    53 53 
             given wl_surface. If there is already such an object associated with
    54 54 
             the wl_surface, the already_constructed error will be raised.

  • staging/content-type/content-type-v1.xml
    ... ... @@ -48,7 +48,7 @@
    48 48 
         </enum>
    49 49
    50 50 
         <request name="get_surface_content_type">
    51 
    -      <description summary="create a new toplevel decoration object">
    51 
    +      <description summary="create a new content type object">
    52 52 
             Create a new content type object associated with the given surface.
    53 53
    54 54 
             Creating a wp_content_type_v1 from a wl_surface which already has one

  • staging/ext-idle-notify/ext-idle-notify-v1.xml
    ... ... @@ -24,7 +24,7 @@
    24 24 
         DEALINGS IN THE SOFTWARE.
    25 25 
       </copyright>
    26 26
    27 
    -  <interface name="ext_idle_notifier_v1" version="1">
    27 
    +  <interface name="ext_idle_notifier_v1" version="2">
    28 28 
         <description summary="idle notification manager">
    29 29 
           This interface allows clients to monitor user idle status.
    30 30
    ... ... @@ -54,9 +54,30 @@
    54 54 
           <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
    55 55 
           <arg name="seat" type="object" interface="wl_seat"/>
    56 56 
         </request>
    57 
    +
    58 
    +    <!-- Version 2 additions -->
    59 
    +
    60 
    +    <request name="get_input_idle_notification" since="2">
    61 
    +      <description summary="create a notification object">
    62 
    +        Create a new idle notification object to track input from the
    63 
    +        user, such as keyboard and mouse movement. Because this object is
    64 
    +        meant to track user input alone, it ignores idle inhibitors.
    65 
    +
    66 
    +        The notification object has a minimum timeout duration and is tied to a
    67 
    +        seat. The client will be notified if the seat is inactive for at least
    68 
    +        the provided timeout. See ext_idle_notification_v1 for more details.
    69 
    +
    70 
    +        A zero timeout is valid and means the client wants to be notified as
    71 
    +        soon as possible when the seat is inactive.
    72 
    +      </description>
    73 
    +      <arg name="id" type="new_id" interface="ext_idle_notification_v1"/>
    74 
    +      <arg name="timeout" type="uint" summary="minimum idle timeout in msec"/>
    75 
    +      <arg name="seat" type="object" interface="wl_seat"/>
    76 
    +    </request>
    77 
    +
    57 78 
       </interface>
    58 79
    59 
    -  <interface name="ext_idle_notification_v1" version="1">
    80 
    +  <interface name="ext_idle_notification_v1" version="2">
    60 81 
         <description summary="idle notification">
    61 82 
           This interface is used by the compositor to send idle notification events
    62 83 
           to clients.
    ... ... @@ -65,9 +86,17 @@
    65 86 
           becomes idle when no user activity has happened for at least the timeout
    66 87 
           duration, starting from the creation of the notification object. User
    67 88 
           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.
    89 
    +      compositor-specific.
    90 
    +
    91 
    +      How this notification responds to idle inhibitors depends on how
    92 
    +      it was constructed. If constructed from the
    93 
    +      get_idle_notification request, then if an idle inhibitor is
    94 
    +      active (e.g. another client has created a zwp_idle_inhibitor_v1
    95 
    +      on a visible surface), the compositor must not make the
    96 
    +      notification object idle. However, if constructed from the
    97 
    +      get_input_idle_notification request, then idle inhibitors are
    98 
    +      ignored, and only input from the user, e.g. from a keyboard or
    99 
    +      mouse, counts as activity.
    71 100
    72 101 
           When the notification object becomes idle, an idled event is sent. When
    73 102 
           user activity starts again, the notification object stops being idle,

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

    Reply to: