1. 09 Jan, 2018 1 commit
  2. 05 Dec, 2017 1 commit
    • Pekka Paalanen's avatar
      protocol: make get_subsurface double-buffered · de24f4dd
      Pekka Paalanen authored
      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
      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
      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
      Bug: https://phabricator.freedesktop.org/T7358Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: default avatarMartin Gräßlin <mgraesslin@kde.org>
  3. 04 Dec, 2017 1 commit
  4. 02 Oct, 2017 1 commit
  5. 24 Jan, 2017 1 commit
  6. 21 Nov, 2016 2 commits
  7. 16 Nov, 2016 1 commit
  8. 10 Nov, 2016 3 commits
  9. 13 Sep, 2016 1 commit
  10. 12 Aug, 2016 8 commits
  11. 08 Aug, 2016 1 commit
  12. 10 May, 2016 1 commit
  13. 03 May, 2016 2 commits
  14. 29 Apr, 2016 1 commit
  15. 21 Apr, 2016 1 commit
    • Yong Bakos's avatar
      protocol: Correct grammar and spelling · 70850643
      Yong Bakos authored
      Fix grammar, spelling, tense, and other inconsistencies, based on
      correctness, consistency, and precedence both here and influenced
      by wayland-protocols.
      - Standardize lower case for summary attribute values.
      - Minor vertical whitespace removal consistency.
      - Standarize references to coordinates, preferring 'surface local'
      - Fix spelling, grammar, tense, and punctuation.
      Signed-off-by: default avatarYong Bakos <ybakos@humanoriented.com>
  16. 05 Apr, 2016 1 commit
  17. 02 Feb, 2016 1 commit
  18. 16 Jan, 2016 2 commits
    • Carlos Garnacho's avatar
      protocol: Add DnD actions · da7b2489
      Carlos Garnacho authored
      These 2 requests have been added:
      - wl_data_source.set_actions: Notifies the compositor of the available
        actions on the data source.
      - wl_data_offer.set_actions: Notifies the compositor of the available
        actions on the destination side, plus the preferred action.
      Out of the data from these requests, the compositor can determine the action
      both parts agree on (and let the user play a role through eg. keyboard
      modifiers). The chosen option will be notified to both parties
      through the following two requests:
      - wl_data_source.action
      - wl_data_offer.action
      In addition, the destination side can peek the source side actions through
      Compared to the XDND protocol, there's two notable changes:
      - XDND lets the source suggest an action, whereas wl_data_device lets
        the destination prefer a given action. The difference is subtle here,
        it comes off as convenience because it is the drag destination which
        receives the motion events (unlike in X) and can perform action updates.
        The drag destination seems also in a better position to update the
        preferred action based on things like the data being transferred, the
        place being dropped, and whether the drag is client-local.
      - That same source-side preferred action is used in XDND to convey the
        modifier-induced action to the drag destination, which would then ack
        it, or reply with another action that's accepted (or none), this makes
        the XdndPosition/XdndStatus messaging very verbose, and synchronous
        because the drag source always needs to know the latest status/action
        for every position+action sent.
        Here it's the compositor which takes care of modifiers and matching
        available/accepted actions, this allows for the signaling to happen
        only whenever the actions/modifiers change for real.
      Roughly based on previous work by Giulio Camuffo <giuliocamuffo@gmail.com>
      Changes since v10:
      - Narrow down the situations where wl_data_source/offer.accept requests
        are supposed to happen.
      Changes since v9:
      - Deferred the protocol errors to .finish after some IRC chat with Jonas,
        added further errors if actions API is used on selection sources/offers.
      Changes since v8:
      - Defined further the expected behavior on "ask", described the protocol
        errors that may happen. Fix more spaces vs tabs issues.
      Changes since v7:
      - Misc changes after updating the progress notification patch.
      Changes since v6:
      - Further explanations on wl_data_source/offer.set_actions, including a
        description of "ask" actions. Added protocol errors for unknown action
      Changes since v5:
      - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
        scheme for actions. Fixed indentation and other minor formatting issues.
      Changes since v4:
      - Minor rewording.
      Changes since v3:
      - Splitted from DnD progress notification changes.
      - Further rationales in commit log.
      Changes since v2:
      - Renamed notify_actions to set_actions on both sides, seems more consistent
        with the rest of the protocol.
      - Spelled out better which events may be triggered on the compositor side
        by the requests, the circumstances in which events are emitted, and
        what are events useful for in clients.
      - Defined a minimal common ground wrt compositor-side action picking and
      - Acknowledge the possibility of compositor/toolkit defined actions, even
        though none are used at the moment.
      Changes since v1:
      - Added wl_data_offer.source_actions to let know of the actions offered
        by a data source.
      - Renamed wl_data_source.finished to "drag_finished" for clarity
      - Improved wording as suggested by Bryce
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: default avatarMichael Catanzaro <mcatanzaro@igalia.com>
      Reviewed-by: default avatarMike Blumenkrantz <zmike@samsung.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
    • Carlos Garnacho's avatar
      protocol: Improve data source notification around DnD progress · 5c4272b8
      Carlos Garnacho authored
      Currently, there's no means for the DnD origin to know whether the
      destination is actually finished with the DnD transaction, short of
      finalizing it after the first transfer finishes, or leaking it forever.
      But this poses other interoperation problems, drag destinations might
      be requesting several mimetypes at once, might be just poking to find
      out the most suitable format, might want to defer the action to a popup,
      might be poking contents early before the selection was dropped...
      In addition, data_source.cancelled is suitable for the situations where
      the DnD operation fails (not on a drop target, no matching mimetypes,
      etc..), but seems undocumented for that use (and unused in weston's DnD).
      In order to improve the situation, the drag source should be notified
      of all stages of DnD. In addition to documenting the "cancelled" event
      for DnD purposes, The following 2 events have been added:
      - wl_data_source.dnd_drop_performed: Happens when the operation has been
        physically finished (eg. the button is released), it could be the right
        place to reset the pointer cursor back and undo any other state resulting
        from the initial button press.
      - wl_data_source.dnd_finished: Happens when the destination side destroys
        the wl_data_offer, at this point the source can just forget all data
        related to the DnD selection as well, plus optionally deleting the data
        on move operations.
      Changes since v6:
        - Turned wl_data_offer.finish calls with 0/NULL state/mimetype an
          error, made it explicit that it will only result in
          wl_data_offer.dnd_finished being sent if successful.
      Changes since v5:
        - Further rewording of wl_data_offer.finish and wl_data_offer.accept.
          Added error for untimely wl_data_offer.finish requests.
      Changes since v4:
        - Applied rewording suggestions from Jonas Ådahl. Added new
          wl_data_offer.finish request to allow explicit finalization on the
          destination side.
      Changes since v3:
        - Renamed dnd_performed to a more descriptive dnd_drop_performed,
          documented backwards compatible behavior on wl_data_offer.accept and
      Changes since v2:
        - Minor rewording.
      Changes since v1:
        - Renamed events to have a common "dnd" namespace. Made dnd_performed to
          happen invariably, data_device.cancelled may still happen afterwards.
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: default avatarMichael Catanzaro <mcatanzaro@igalia.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: default avatarMike Blumenkrantz <zmike@samsung.com>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
  19. 14 Jan, 2016 1 commit
    • Peter Hutterer's avatar
      protocol: add wl_pointer.frame, axis_source, axis_stop, and axis_discrete · c5356e90
      Peter Hutterer authored
      The frame event groups separate pointer events together. The primary use-case
      for this at the moment is diagonal scrolling - a vertical/horizontal scroll
      event can be grouped together to calculate the correct motion vector.
      Frame events group all wl_pointer events. An example sequence of motion events
      followed by a diagonal scroll followed by a button event is:
      In the future, other extensions may insert additional information about an
      event into the frame. For example, an extension may add information about the
      physical device that generated an event into the frame. For this reason,
      enter/leave events are grouped by a frame event too.
      The axis_source event determines how an axis event was generated. That enables
      clients to judge when to use kinetic scrolling. Only one axis_source event is
      allowed per frame and applies to all events in this frame.
      The axis_stop event notifies a client about the termination of a scroll
      sequence, likewise needed to calculate kinetic scrolling parameters.
      Multiple axis_stop events within the same frame indicate that scrolling has
      stopped in all these axis at the same time.
      The axis_discrete event provides the wheel click count. Previously the axis
      value was some hardcoded number (10), with the discrete steps this enables a
      client to differ between line-based scrolling on a mouse wheel and smooth
      scrolling with a touchpad. The axis_discrete event carries the axis
      information and the discrete value and can occur at any time in the frame
      provided it is ordered before the matching axis event. Specifically, this
      sequence is valid:
      wl_pointer.axis_discrete (vert)
      wl_pointer.axis_discrete (horiz)
      wl_pointer.axis (horiz)
      wl_pointer.axis (vert)
      Enter and leave event also trigger wl_pointer.frame events, where possible the
      compositor should group leave and subsequent enter into the same frame. This
      indicates to the client that the pointer has moved between surfaces and may
      allow a client to shortcut code otherwise triggerd by the leave or enter
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
  20. 07 Dec, 2015 1 commit
  21. 03 Dec, 2015 1 commit
    • Derek Foreman's avatar
      protocol: Add wl_surface.damage_buffer · 3384f69e
      Derek Foreman authored
      wl_surface.damage uses surface local co-ordinates.
      Buffer scale and buffer transforms came along, and EGL surfaces
      have no understanding of them.
      Theoretically, clients pass damage rectangles - in Y-inverted surface
      co-ordinates) to EGLSwapBuffersWithDamage, and the EGL implementation
      passed them on to wayland.  However, for this to work the EGL
      implementation must be able to flip those rectangles into the space
      the compositor is expecting, but it's unable to do so because it
      doesn't know the height of the transformed buffer.
      So, currently, EGLSwapBuffersWithDamage is unusable and EGLSwapBuffers
      has to pass (0,0) - (INT32_MAX, INT32_MAX) damage to function.
      wl_surface.damage_buffer allows damage to be registered on a surface
      in buffer co-ordinates, avoiding this problem.
      Credit where it's due, these ideas are not entirely my own:
      Over a year ago the idea of changing damage co-ordinates to buffer
      co-ordinates was suggested (by Jason Ekstrand), and it was at least
      partially rejected and abandoned.  At the time it was also suggested
      (by Pekka Paalanen) that adding a new wl_surface.damage_buffer request
      was another option.
      This will eventually resolve:
      by making the problem irrelevant.
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
  22. 24 Nov, 2015 1 commit
  23. 20 Nov, 2015 1 commit
  24. 17 Nov, 2015 3 commits
  25. 04 Nov, 2015 1 commit
  26. 09 Oct, 2015 1 commit