1. 15 Apr, 2022 1 commit
  2. 11 Apr, 2022 1 commit
    • Kenny Levinsen's avatar
      viewport: Remove mention of wl_surface.attach x/y · 2398378c
      Kenny Levinsen authored and Simon Ser's avatar Simon Ser committed
      This paragraph contains an incomplete definition of how
      wl_surface.attach x/y arguments functions, and makes no reference to the
      similar wl_surface.offset.
      The paragraph states that there is no effect on the behavior of
      wl_surface.attach. Rather than elaborating on its definition and adding
      wl_surface.offset, remove the paragraph and let their definition be up
      to wl_surface itself.
      Signed-off-by: Kenny Levinsen's avatarKenny Levinsen <kl@kl.wtf>
  3. 06 Apr, 2022 1 commit
  4. 29 Mar, 2022 2 commits
    • Simon Ser's avatar
      members: add Simon Zeni for wlroots/Sway · db85bc14
      Simon Ser authored
      Simon Zeni has stepped up as a member for wlroots/Sway.
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
    • Carlos Garnacho's avatar
      text-input: Reword the interpretation of serials to be more specific · 37fa0f4a
      Carlos Garnacho authored and Jonas Ådahl's avatar Jonas Ådahl committed
      Here's a long story. The serial is formerly described as:
        When the client receives a done event with a serial different than the
        number of past commit requests, it must proceed as normal, except it
        should not change the current state of the zwp_text_input_v3 object.
      Upon first reading it might be obvious to interpret "proceed as normal"
      as "apply the changes made by the done event" and "not change the current
      state" as "do not make requests on it until serial matches with
      expectations again". This would turn the serial into a flow control
      mechanism to avoid pushing state changes that we know might be stale.
      GTK however makes another outlandish interpretation, where "proceed as
      normal" means "ignore the changes made by the done event" and "not change
      state of the zwp_text_input_v3 object" is "not change client state". This
      makes the serial a full synchronization mechanism where IM commands that
      are deemed out of sync are symply i...
  5. 25 Mar, 2022 1 commit
  6. 25 Feb, 2022 1 commit
  7. 11 Jun, 2020 3 commits
  8. 25 Feb, 2022 1 commit
  9. 23 Feb, 2022 2 commits
  10. 26 Jan, 2022 1 commit
  11. 19 Jan, 2022 2 commits
  12. 17 Jan, 2022 1 commit
  13. 28 Dec, 2021 1 commit
    • Isaac Freund's avatar
      ext-session-lock-v1: new protocol · a52b8f02
      Isaac Freund authored
      This protocol allows for a privileged Wayland client to lock the
      session and display arbitrary graphics while the session is locked.
      The client is responsible for performing authentication and informing
      the compositor when the session should be unlocked. If the client
      dies while the session is locked the session remains locked, possibly
      permanently depending on compositor policy.
      Signed-off-by: Isaac Freund's avatarIsaac Freund <mail@isaacfreund.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
  14. 24 Nov, 2021 1 commit
  15. 23 Nov, 2021 3 commits
  16. 17 Nov, 2021 1 commit
  17. 10 Nov, 2021 1 commit
  18. 09 Nov, 2021 1 commit
  19. 13 Oct, 2021 1 commit
  20. 11 Oct, 2021 1 commit
  21. 04 Oct, 2021 1 commit
    • Alexander Richardson's avatar
      tests: allow cross-compiling the tests · 78f654ed
      Alexander Richardson authored
      I am trying to cross-compile from macOS for FreeBSD and this is currently
      failing since the tests attempt to build a native binary that links
      against the wayland-client and wayland-server libraries for the FreeBSD
      system. I believe we should be building them for the target system and
      not the current host (especially since there is no way to build
      wayland-client and wayland-server for macOS, but I do want to check that
      the files build correctly for FreeBSD).
      Signed-off-by: Alexander Richardson's avatarAlex Richardson <Alexander.Richardson@cl.cam.ac.uk>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
  22. 19 Sep, 2021 1 commit
  23. 15 Sep, 2021 1 commit
  24. 13 Sep, 2021 1 commit
    • Peter Hutterer's avatar
      pointer-gestures: add hold gestures · 824cea61
      Peter Hutterer authored and Simon Ser's avatar Simon Ser committed
      Hold gestures merely denote "there are fingers on the touchpad but they are
      not moving". As touchpad touches are generally fully abstracted, a client
      cannot currently know when a user is interacting with the touchpad without
      moving - no motion events will be sent in this case.
      The two use-cases here are:
      - hold-to-interact: where a hold gesture is active for some time
        a menu could pop up, or some object is selected, etc.
      - hold-to-cancel: where e.g. kinetic scrolling is currently active, the start
        of a hold gesture can be used to stop the scroll
      Since hold gestures by definition do not have movement, there is no need for
      an "update" stage in the gesture.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  25. 09 Sep, 2021 1 commit
  26. 01 Sep, 2021 4 commits
  27. 28 Aug, 2021 1 commit
  28. 06 Aug, 2021 2 commits
    • Simon Ser's avatar
      readme: fix unformatted label references · 7dffa6f3
      Simon Ser authored
      The newlines prevent the labels from being properly formatted.
      Additionally, the second label reference has a typo (extra "s").
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
    • Xaver Hugl's avatar
      staging/drm-lease: DRM lease protocol support · aa3df408
      Xaver Hugl authored and Simon Ser's avatar Simon Ser committed
      DRM leasing is a feature which allows the DRM master to "lease" a subset
      of its DRM resources to another DRM master via drmModeCreateLease, which
      returns a file descriptor for the new DRM master. We use this protocol
      to negotiate the terms of the lease and transfer this file descriptor to
      In less DRM-specific terms: this protocol allows Wayland compositors to
      give over their GPU resources (like displays) to a Wayland client to
      exclusively control.
      The primary use-case for this is Virtual Reality headsets, which via the
      non-desktop DRM property are generally not used as desktop displays by
      Wayland compositors, and for latency reasons (among others) are most
      useful to games et al if they have direct control over the DRM resources
      associated with it. Basically, these are peripherals which are of no use
      to the compositor and may be of use to a client, but since they are tied
      up in DRM we need to use DRM leasing to get them into client's hands.
      Signed-off-by: Marius Vlad's avatarMarius Vlad <marius.vlad@collabora.com>
      Signed-off-by: Drew DeVault's avatarDrew DeVault <sir@cmpwn.com>
      Signed-off-by: Xaver Hugl's avatarXaver Hugl <xaver.hugl@gmail.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Signed-off-by: David Edmundson's avatarDavid Edmundson <davidedmundson@kde.org>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
  29. 04 Aug, 2021 1 commit
    • Roman Gilg's avatar
      xdg-activation: rewrite and move description of token forwarding · 7460f79e
      Roman Gilg authored
      After a requesting client receives a new token, the client usually forwards the
      token string to another client by a different process, which then uses the
      token in an activate request. For that the token string must be transferred to
      the other process.
      Two default ways of doing that were described in the done event, but the
      description had some issues and it makes more sense to describe them in the
      protocol description itself, which talks about the protocol in a more general
      way. Therefore rewrite the paragraphs about token forwarding between clients
      and place them in the protocol description.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>