Skip to content
Snippets Groups Projects
  1. Nov 08, 2020
    • Simon Ser's avatar
      Update version to 0.12.0 · 238d1c07
      Simon Ser authored
      0.12.0
      238d1c07
    • Ilia Bozhinov's avatar
      xdg_shell: handle inert popups · 9595f954
      Ilia Bozhinov authored and Simon Ser's avatar Simon Ser 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
      NONE.
      
      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.
      9595f954
  2. Nov 06, 2020
  3. Nov 05, 2020
  4. Nov 04, 2020
  5. Nov 03, 2020
  6. Nov 02, 2020
  7. Oct 31, 2020
  8. Oct 30, 2020
  9. Oct 27, 2020
  10. Oct 20, 2020
  11. Oct 18, 2020
  12. Oct 16, 2020
    • Isaac Freund's avatar
      xdg_positioner: remove unused field · 616f06c2
      Isaac Freund authored and Simon Ser's avatar Simon Ser 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.
      616f06c2
  13. Oct 14, 2020
  14. Oct 13, 2020
    • Tudor Brindus's avatar
      xwayland: notify requestor when we fail to respond to their request · afeb941c
      Tudor Brindus authored and Simon Ser's avatar Simon Ser 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.
      afeb941c
  15. Oct 12, 2020
    • Tudor Brindus's avatar
      xwayland: remove stale transfers from the same requestor · 7bb9d48d
      Tudor Brindus authored and Simon Ser's avatar Simon Ser 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.
      7bb9d48d
  16. Oct 11, 2020
    • Tudor Brindus's avatar
      xwayland: introduce WLR_XWAYLAND for specifying which Xwayland to use · 1b0e4c7e
      Tudor Brindus authored and Simon Ser's avatar Simon Ser committed
      When debugging Xwayland-related issues, a common first step in debugging
      has been to ask the reporter to move their real Xwayland to
      /usr/bin/Xwayland.bin, and create a shell script starting Xwayland with
      extra arguments under the original /usr/bin/Xwayland location.
      
      Introducing a `WLR_XWAYLAND` environment variable makes this less
      invasive, by allowing the user to swap out Xwayland without resorting to
      global system changes (or source patches).
      1b0e4c7e
    • Tudor Brindus's avatar
      xwayland: fix use-after-free in selection handling · feb0e1c7
      Tudor Brindus authored and Simon Ser's avatar Simon Ser committed
      Fixes #2425.
      
      wlroots can only handle one outgoing transfer at a time, so it keeps a
      list of pending selections. The head of the list is the currently-active
      selection, and when that transfer completes and is destroyed, the next
      one is started.
      
      The trouble is when you have a transfer to some app that is misbehaving.
      fcitx is one such application. With really large transfers, fcitx will
      hang and never wake up again. So, you can end up with a transfer list
      that looks like this:
      
      | T1: started | T2: pending | T3: pending | T4: pending |
      
      The file descriptor for transfer T1 is registered in libwayland's epoll
      loop. The rest are waiting in wlroots' list.
      
      As a user, you want your clipboard back, so you `pkill fcitx`. Now
      Xwayland sends `XCB_DESTROY_NOTIFY` to let us know to give up. We clean
      up T4 first.
      
      Due to a bug in wlroots code, we register the (fd, transfer data
      pointer) pair for T1 with libwayland *again*, despite it already being
      registered. We do this 2 more times as we remove T3 and T2.
      
      Finally, we remove T1 and `free` all the memory associated with it,
      before `close`-ing its transfer file descriptor.
      
      However, we still have 3 copies of T1's file descriptor left in the
      epoll loop, since we erroneously added them as part of removing T2/3/4.
      When we `close` the file descriptor as part of T1's teardown, we
      actually cause the epoll loop to wake up the next time around, saying
      "this file descriptor has activity!" (it was closed, so `read`-ing would
      normally return 0 to let us know of EOF).
      
      But instead of returning 0, it returns -1 with `EBADF`, because the file
      descriptor has already been closed. And finally, as part of error-handling
      this, we access the transfer pointer, which was `free`'d. And we crash.
      feb0e1c7
    • Tudor Brindus's avatar
      xwayland: using %m in `wlr_log` is broken, use `wlr_log_errno` instead · ab80ad90
      Tudor Brindus authored and Simon Ser's avatar Simon Ser committed
      This one was awful to track down, but calls to `wlr_log` with %m have
      the errno masked by the `isatty` call in `log_stderr`. Switch them to
      `wlr_log_errno` instead.
      
      Cue quality "how can read(2) POSSIBLY be returning ENOTTY?" moments.
      ab80ad90
Loading