1. 15 Feb, 2018 1 commit
  2. 09 Feb, 2018 12 commits
  3. 22 Jan, 2018 1 commit
  4. 19 Jan, 2018 2 commits
  5. 09 Jan, 2018 7 commits
    • Derek Foreman's avatar
      tests: Check for wrong fd delivery with zombie objects · ff992951
      Derek Foreman authored
      Until recently, if an event attempting to deliver an fd to a zombie
      object was demarshalled after the object was made into a zombie, we
      leaked the fd and left it in the buffer.
      If another event attempting to deliver an fd to a live object was in that
      same buffer, the zombie's fd would be delivered instead.
      This test recreates that situation.
      While this is a ridiculously contrived way to force this race - delivering
      an event from a destruction handler - I do have reports of this race
      being hit in real world code.
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
    • Derek Foreman's avatar
      tests: Add a test for fd leaks on zombie objects · f74c9b98
      Derek Foreman authored
      Until recently, if a client destroying a resource raced with the
      server generating an event on that resource that delivered a file
      descriptor, we would leak the fd.
      This tests for a leaked fd from that race condition.
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
    • Derek Foreman's avatar
      client: Consume file descriptors destined for zombie proxies · 239ba393
      Derek Foreman authored
      We need to close file descriptors sent to zombie proxies to avoid leaking
      them, and perhaps more importantly, to prevent them from being dispatched
      in events on other objects (since they would previously be left in the
      buffer and potentially fed to following events destined for live proxies)
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
    • Derek Foreman's avatar
      client: Replace the singleton zombie with bespoke zombies · 4485ed1f
      Derek Foreman authored
      Using the singleton zombie object doesn't allow us to posthumously retain
      object interface information, which makes it difficult to properly inter
      future events destined for the recently deceased proxy.
      Notably, this makes it impossible for zombie proxy destined file
      descriptors to be properly consumed.
      When we create a proxy, we now create a zombie-state object to hold
      information about the file descriptors in events it can receive. This
      will allow us, in a future patch, to close those FDs.
      [daniels: Split Derek's patch into a few smaller ones.]
      Signed-off-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
    • Daniel Stone's avatar
      client: Plug a race in proxy destruction vs. dispatch · 9744de9f
      Daniel Stone authored
      Closures created to hold events which will be dispatched on the client,
      take a reference to the proxy for the object the event was sent to, as
      well as the proxies for all objects referenced in that event.
      These references are dropped immediately before dispatch, with the
      display lock also being released. This leaves the potential for a
      vanishingly small race, where another thread drops the last reference
      on one of the proxies used in an event as it is being dispatched.
      Fix this by splitting decrease_closure_args_refcount into two functions:
      one which validates the objects (to ensure that clients are not returned
      objects which they have destroyed), and another which unrefs all proxies
      on the closure (object event was sent to, all referenced objects) as
      well as the closure itself. For symmetry, increase_closure_args_refcount
      is now the place where the refcount for the proxy for the object the
      event was sent to, is increased.
      This also happens to fix a bug: previously, if an event was sent to a
      client-destroyed object, and the event had object arguments, a reference
      would be leaked on the proxy for each of the object arguments.
      Found by inspection whilst reviewing the zombie-FD-leak series.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
      Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
    • Daniel Stone's avatar
      client: Add wl_proxy_unref helper · 430c7820
      Daniel Stone authored
      Rather than open-coded decrement-and-maybe-free, introduce a
      wl_proxy_unref helper to do this for us. This will come in useful for
      future patches, where we may also have to free a zombie object.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
    • Daniel Stone's avatar
      client: Use refcount exclusively for destruction · b39d8933
      Daniel Stone authored
      Commit e273c7cd added a refcount to wl_proxy. The refcount is set to 1
      on creation, decreased when the client explicitly destroys the proxy,
      and is increased and decreased every time an event referencing that
      proxy is queued.
      Assuming no bugs, this means the refcount cannot reach 0 without the
      proxy being explicitly destroyed. However, some (not all) of the
      proxy-unref paths were only destroying the proxy if it had already been
      deleted. This should already be enforced by refcounting, so remove the
      check and rely solely on the refcount as the arbiter of when to free a
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
  6. 28 Dec, 2017 4 commits
  7. 27 Dec, 2017 6 commits
  8. 18 Dec, 2017 1 commit
    • Pekka Paalanen's avatar
      doc: start documenting Xwayland · 14761780
      Pekka Paalanen authored
      This is a rough intro to what Xwayland is and does, with just one
      implementation detail so far (Window identification).
      I paid no attention to formatting details, those can be polished in
      follow-ups. I just want the prose out.
      I also just quickly whacked up the diagram, would be happy to see
      someone replace it with a nicer one. I just didn't have time to learn
      dot for now.
      - typo fix
      - rephrase "talking to hardware" as "driving the displays"
      - mention circular dependency in intro
      - add section to explain rootless and rootful modes
      - remove paragraph about Xwayland protocol usage
      - move TBD part to the end under a new section header
      - use "advantage" and "disadvantage" instead of "pro" and "con"
      - slight rewording on rootful mode and rootless mode paragraphs
      - removed the paragraph about the lack of shell and special Wayland
        protocol extensions
      - removed the commented out list of ideas to write
      - typo fixes pointed out by Yong
      Cc: Olivier Fourdan <ofourda...
  9. 11 Dec, 2017 1 commit
    • Matthew Hoosier's avatar
      client: Allow absolute paths in WAYLAND_DISPLAY · 1b6521e6
      Matthew Hoosier authored
      In order to support system compositor instances, it is necessary to
      allow clients' wl_display_connect() to find the compositor's listening
      socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see
      the discussion beginning here:
      This change adjusts the client-side connection logic so that, if
      WAYLAND_DISPLAY is formatted as an absolute pathname, the socket
      connection attempt is made to just $WAYLAND_DISPLAY rather than
      usual user-private location $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.
      This change is based on Davide Bettio's submission of the same concept
      v4 changes:
      * Improved internal comments and some boundary-condition
        error checks in test case.
      * Refer to compositor as "Wayland server" rather than "Wayland
        display" in wl_display_connect() doxygen comments.
      * Remove redundant descriptions of parameter-interpretation
        mechanics from wl_display_connect() manpage. Reworked things
        to make it clear that 'name' and $WAYLAND_DISLAY are each
        capable of encoding absolute server socket paths.
      * Remove callout to reference implementation behavior in protocol
        documented. In its place there is now a simple statement that
        implementations can optionally support absolute socket paths.
      v3 changes:
      * Added test case.
      * Clarified documentation to note that 'name' parameter to wl_display_connect()
        can also be an absolute path.
      v2 changes:
      * Added backward incompatibility note to wl_display_connect() manpage.
      * Rephased wl_display_connect() manpage changes to precisely match actual
        changed behavior.
      * Added mention of new absolute path behavior in wl_display_connect()
        doxygen comments.
      * Mentioned new absolute path interpretation of WAYLAND_DISPLAY in
        protocol documentation.
      Signed-off-by: Matt Hoosier's avatarMatt Hoosier <matt.hoosier@gmail.com>
      Acked-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  10. 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: Martin Flöser's avatarMartin Gräßlin <mgraesslin@kde.org>
  11. 04 Dec, 2017 4 commits