1. 29 Jul, 2019 1 commit
    • Jonas Ådahl's avatar
      proxy: Add API to tag proxy objects · 493ab79b
      Jonas Ådahl authored
      When an application and a toolkit share the same Wayland connection,
      it will receive events with each others objects. For example if the
      toolkit manages a set of surfaces, and the application another set, if
      both the toolkit and application listen to pointer focus events,
      they'll receive focus events for each others surfaces.
      
      In order for the toolkit and application layers to identify whether a
      surface is managed by itself or not, it cannot only rely on retrieving
      the proxy user data, without going through all it's own proxy objects
      finding whether it's one of them.
      
      By adding the ability to "tag" a proxy object, the toolkit and
      application can use the tag to identify what the user data pointer
      points to something known.
      
      To create a tag, the recommended way is to define a statically allocated
      constant char array containing some descriptive string. The tag will be
      the pointer to the non-const pointer to the beginning of the array.
      
      For example, to identify whether a focus event is for a surface managed
      by the code in question:
      
      	static const char *my_tag = "my tag";
      
      	static void
      	pointer_enter(void *data,
      		      struct wl_pointer *wl_pointer,
      		      uint32_t serial,
      		      struct wl_surface *surface,
      		      wl_fixed_t surface_x,
      		      wl_fixed_t surface_y)
      	{
      		struct window *window;
      		const char * const *tag;
      
      		tag = wl_proxy_get_tag((struct wl_proxy *) surface);
      
      		if (tag != &my_tag)
      			return;
      
      		window = wl_surface_get_user_data(surface);
      
      		...
      	}
      
      	...
      
      	static void
      	init_window_surface(struct window *window)
      	{
      		struct wl_surface *surface;
      
      		surface = wl_compositor_create_surface(compositor);
      		wl_surface_set_user_data(surface, window);
      		wl_proxy_set_tag((struct wl_proxy *) surface,
      				 &my_tag);
      	}
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      493ab79b
  2. 05 Jun, 2019 1 commit
  3. 29 Jan, 2019 1 commit
    • Christopher James Halse Rogers's avatar
      proto, server: Add internal server error message. (v2) · d3251402
      Christopher James Halse Rogers authored
      Many languages such as C++ or Rust have an unwinding error-reporting
      mechanism. Code in these languages can (and must!) wrap request handling
      callbacks in unwind guards to avoid undefined behaviour.
      
      As a consequence such code will detect internal server errors, but have
      no way to communicate such failures to the client.
      
      This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that
      such code can notify (and disconnect) clients which hit internal bugs.
      While servers can currently abuse other wl_display errors for the same
      effect, adding an explicit error code allows clients to tell the
      difference between errors which are their fault and errors which are the
      server's fault. This is particularly interesting for automated bug
      reporting.
      
      v2: Rename error from "internal" to "implementation", in sympathy with
          X11's BadImplementation error.
          Add more justification in the commit message.
      Signed-off-by: 's avatarChristopher James Halse Rogers <christopher.halse.rogers@canonical.com>
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      d3251402
  4. 28 Jun, 2018 1 commit
  5. 07 Mar, 2018 2 commits
  6. 09 Jan, 2018 5 commits
    • 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: 's avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      239ba393
    • 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: 's avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      4485ed1f
    • 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: 's avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
      Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
      9744de9f
    • 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: 's avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
      430c7820
    • 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
      proxy.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: 's avatarDerek Foreman <derekf@osg.samsung.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
      b39d8933
  7. 28 Dec, 2017 4 commits
  8. 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:
      
      https://lists.freedesktop.org/archives/wayland-devel/2017-November/035664.html
      
      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
      at:
      
      https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html.
      
      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>
      1b6521e6
  9. 04 Dec, 2017 1 commit
  10. 21 Nov, 2016 1 commit
  11. 03 May, 2016 1 commit
  12. 29 Apr, 2016 2 commits
    • Jonas Ådahl's avatar
      client: Fix wl_display_roundtrip_queue() race condition · 6fe12f02
      Jonas Ådahl authored
      Without this commit, wl_display_roundtrip_queue() is vulnerable to a
      race condition, causing the callback to be dispatched on the wrong
      queue.
      
      The race condition happens if some non-main thread calls
      wl_display_roundtrip_queue() with its thread local queue, and the main
      thread reads and dispatches the callback event from the
      wl_display_sync() call before the thread local queue is set.
      
      The issue is fixed by using a proxy wrapper, making the initialization
      of the callback proxy atomic, effectively making it no longer possible
      for some other thread to dispatch the proxy before the correct thread
      local queue is set.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      [Pekka: check display_wrapper]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      6fe12f02
    • Jonas Ådahl's avatar
      client: Introduce proxy wrappers · 6d29c0da
      Jonas Ådahl authored
      Using the libwayland-client client API with multiple threads with
      thread local queues are prone to race conditions.
      
      The problem is that one thread can read and queue events after another
      thread creates a proxy but before it sets the queue.
      
      This may result in the event to the proxy being silently dropped, or
      potentially dispatched on the wrong thread had the creating thread set
      the implementation before setting the queue.
      
      This patch introduces API to solve this case by introducing "proxy
      wrappers". In short, a proxy wrapper is a wl_proxy struct that will
      never itself proxy any events, but may be used by the client to set a
      queue, and use it instead of the original proxy when sending requests
      that creates new proxies. When sending requests, the wrapper will
      work in the same way as the normal proxy object, but the proxy created
      by sending a request (for example wl_display.sync) will inherit to the
      same proxy queue as the wrapper.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=91273Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: 's avatarDerek Foreman <derekf@osg.samsung.com>
      6d29c0da
  13. 28 Apr, 2016 1 commit
  14. 05 Apr, 2016 1 commit
  15. 26 Feb, 2016 1 commit
  16. 19 Jan, 2016 1 commit
    • Jason Ekstrand's avatar
      Track protocol object versions inside wl_proxy. · 557032e3
      Jason Ekstrand authored
      This provides a standardized mechanism for tracking protocol object
      versions in client code.  The wl_display object is created with version 1.
      Every time an object is created from within wl_registry_bind, it gets the
      bound version.  Every other time an object is created, it simply inherits
      it's version from the parent object that created it.
      
      (comments and minor reformatting added
      by Derek Foreman <derekf@osg.samsung.com>)
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      
      Second trivial commit squashed into this one:
      Authored by Derek Foreman <derekf@osg.samsung.com>
      Signed-off-by: 's avatarDerek Foreman <derekf@osg.samsung.com>
      (it's literally one of code and a lot of comments)
      
      This sets wl_display's version (for proxy version query purposes)
      to 0.  Any proxy created with unversioned API (this happens when
      a client compiled with old headers links against new wayland)
      will inherit this 0.
      
      This gives us a way for new libraries linked by old clients to
      realize they can't know a proxy's version.
      
      wl_display's version being unqueryable (always returning 0) is
      an acceptable side effect, since it's a special object you can't
      bind specific versions of anyway.
      
      Second half:
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      557032e3
  17. 16 Jan, 2016 5 commits
  18. 13 Jan, 2016 1 commit
  19. 12 Jan, 2016 2 commits
  20. 16 Nov, 2015 1 commit
  21. 08 Oct, 2015 1 commit
  22. 06 Oct, 2015 4 commits
  23. 24 Aug, 2015 1 commit