1. 12 Sep, 2021 1 commit
  2. 23 Aug, 2021 1 commit
  3. 20 Aug, 2021 1 commit
  4. 08 Nov, 2020 2 commits
    • emersion's avatar
      Update version to 0.12.0 · 238d1c07
      emersion authored
    • Ilia Bozhinov's avatar
      xdg_shell: handle inert popups · 9595f954
      Ilia Bozhinov authored and emersion's avatar emersion committed
      xdg_popups can be destroyed by the compositor when closed. When this happens,
      wlroots makes the xdg_popup surface inert and resets the xdg_surface role to
      Currently, wlroots sends a protocol error and asserts that an xdg_surface has
      a role when committed. This is racy if at the same time the client commits an
      xdg_popup and the compositor closes it. This patch removes the assertion and
      ignores commits on xdg_surfaces without a role set.
  5. 06 Nov, 2020 1 commit
  6. 05 Nov, 2020 7 commits
  7. 04 Nov, 2020 1 commit
  8. 03 Nov, 2020 4 commits
  9. 02 Nov, 2020 1 commit
  10. 31 Oct, 2020 4 commits
  11. 30 Oct, 2020 1 commit
  12. 27 Oct, 2020 1 commit
  13. 20 Oct, 2020 3 commits
  14. 18 Oct, 2020 8 commits
  15. 16 Oct, 2020 1 commit
    • Isaac Freund's avatar
      xdg_positioner: remove unused field · 616f06c2
      Isaac Freund authored and emersion's avatar emersion committed
      The resource field of wlr_xdg_positioner is never initialized or
      accessed within wlroots. The wl_resource for this interface is stored
      in the wlr_xdg_positioner_resource struct.
  16. 14 Oct, 2020 1 commit
  17. 13 Oct, 2020 1 commit
    • Tudor Brindus's avatar
      xwayland: notify requestor when we fail to respond to their request · afeb941c
      Tudor Brindus authored and emersion's avatar emersion committed
      We already mostly did this, but there were a couple of branches
      (`calloc` failures) where we'd bail without letting the other side know.
      Refs swaywm/sway#4007. Likely not going to be a real improvement there
      (if `calloc` fails you're already pretty screwed), but it does address a
      theoretical possibility.
  18. 12 Oct, 2020 1 commit
    • Tudor Brindus's avatar
      xwayland: remove stale transfers from the same requestor · 7bb9d48d
      Tudor Brindus authored and emersion's avatar emersion committed
      It seems that if we ever try to reply to a selection request after
      another has been sent by the same requestor (we reply in FIFO order),
      the requestor never reads from it, and we end up stalling forever on a
      transfer that will never complete.
      It appears that `XCB_SELECTION_REQUEST` has some sort of singleton
      semantics, and new requests for the same selection are meant to replace
      outstanding older ones. I couldn't find a reference for this, but
      empirically this does seem to be the case.
      Real (contrived) case where we don't currently do this, and things break:
      * run fcitx
      * run Slack
      * wl-copy < <(base64 /opt/firefox/libxul.so)  # or some other large file
      * focus Slack (no need to paste)
      fcitx will send in an `XCB_SELECTION_REQUEST`, and we'll start
      processing it. Immediately after, Slack sends its own. fcitx hangs for a
      long, long time. In the meantime, Slack retries and sends another
      selection request. We now have two pending requests from Slack.
      Eventually fcitx gives up (or it can be `pkill`'d), and we start
      processing the first request Slack gave us (FIFO). Slack (Electron?)
      isn't listening on the other end anymore, and this transfer never
      completes. The X11 clipboard becomes unusable until Slack is killed.
      After this patch, the clipboard is immediately usable again after fcitx
      bails. Also added a bunch of debug-level logging that makes diagnosing
      this sort of issue easier.
      Refs swaywm/sway#4007.