1. 29 Apr, 2016 1 commit
    • 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.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
  2. 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: default 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>
  3. 12 Jan, 2016 1 commit
  4. 26 Oct, 2015 1 commit
  5. 12 Jun, 2015 1 commit
  6. 30 Apr, 2015 1 commit
    • Giulio Camuffo's avatar
      introduce new headers wayland-client-core.h and wayland-server-core.h · d74a9c07
      Giulio Camuffo authored
      wayland-client.h and wayland-server.h include the protocol headers generated
      at build time. This means that a libwayland user cannot generate and use
      protocol code created from a wayland.xml newer than the installed libwayland,
      because it is not possible to only include the API header.
      Another use case is language bindings, which would generate their own protocol
      code and which only need to use the library ABI, not the generated C code.
      This commit adds wayland-client-core.h and wayland-server-core.h which do not
      include the protocol headers or any deprecated code.
      Reviewed-by: Jason Ekstrand's avatarJason Ekstrand <jason@jlekstrand.net>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  7. 09 Dec, 2014 1 commit
  8. 25 Nov, 2014 1 commit
  9. 21 Aug, 2014 1 commit
  10. 07 Jul, 2014 1 commit
    • Marek Chalupa's avatar
      client: extend error handling · 886b09c9
      Marek Chalupa authored
      When an error occurs, wl_display_get_error() does not
      provide any way of getting know if it was a local error or if it was
      an error event, respectively what object caused the error and what
      the error was.
      This patch introduces a new function wl_display_get_protocol_error()
      which will return error code, interface and id of the object that
      generated the error.
      wl_display_get_error() will work the same way as before.
      wl_display_get_protocol_error() DOES NOT indicate that a non-protocol
      error happened. It returns valid information only in that case that
      (protocol) error occurred, so it should be used after calling
      wl_display_get_error() with positive result.
      [Pekka Paalanen] Applied another hunk of Bryce's comments to docs,
      	added libtool version bump.
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
      Reviewed-by: default avatarBryce Harrington <b.harrington@samsung.com>
  11. 16 Nov, 2013 1 commit
    • Kristian Høgsberg's avatar
      client: Introduce functions to allocate and marshal proxies atomically · 853c24e6
      Kristian Høgsberg authored
      The server requires clients to only allocate one ID ahead of the previously
      highest ID in order to keep the ID range tight.  Failure to do so will
      make the server close the client connection.  However, the way we allocate
      new IDs is racy.  The generated code looks like:
        new_proxy = wl_proxy_create(...);
        wl_proxy_marshal(proxy, ... new_proxy, ...);
      If two threads do this at the same time, there's a chance that thread A
      will allocate a proxy, then get pre-empted by thread B which then allocates
      a proxy and then passes it to wl_proxy_marshal().  The ID for thread As
      proxy will be one higher that the currently highest ID, but the ID for
      thread Bs proxy will be two higher.  But since thread B prempted thread A
      before it could send its new ID, B will send its new ID first, the server
      will see the ID from thread Bs proxy first, and will reject it.
      We fix this by introducing wl_proxy_marshal_constructor().  This
      function is identical to wl_proxy_marshal(), except that it will
      allocate a wl_proxy for NEW_ID arguments and send it, all under the
      display mutex.  By introducing a new function, we maintain backwards
      compatibility with older code from the generator, and make sure that
      the new generated code has an explicit dependency on a new enough
      A virtual Wayland merit badge goes to Kalle Vahlman, who tracked this
      down and analyzed the issue.
      Reported-by: default avatarKalle Vahlman <kalle.vahlman@movial.com>
  12. 21 Oct, 2013 1 commit
  13. 19 Aug, 2013 1 commit
  14. 12 Aug, 2013 1 commit
    • Rob Bradford's avatar
      wayland-client: Add wl_proxy_get_listener · 4ad58fbb
      Rob Bradford authored
      This is the mirror function to wl_proxy_add_listener and is useful
      inside client libraries to differentiate events on listeners for which
      multiple proxies have been created.
  15. 17 Jun, 2013 1 commit
    • Kristian Høgsberg's avatar
      client: Add wl_display_prepare_read() API to relax thread model assumptions · 3c7e8bfb
      Kristian Høgsberg authored
      The current thread model assumes that the application or toolkit will have
      one thread that either polls the display fd and dispatches events or just
      dispatches in a loop.  Only this main thread will read from the fd while
      all other threads will block on a pthread condition and expect the main
      thread to deliver events to them.
      This turns out to be too restrictive.  We can't assume that there
      always will be a thread like that.  Qt QML threaded rendering will
      block the main thread on a condition that's signaled by a rendering
      thread after it finishes rendering.  This leads to a deadlock when the
      rendering threads blocks in eglSwapBuffers(), and the main thread is
      waiting on the condition.  Another problematic use case is with games
      that has a rendering thread for a splash screen while the main thread
      is busy loading game data or compiling shaders.  The main thread isn't
      responsive and ends up blocking eglSwapBuffers() in the rendering thread.
      We also can't assume that there will be only one thread polling on the
      file descriptor.  A valid use case is a thread receiving data from a
      custom wayland interface as well as a device fd or network socket.
      The thread may want to wait on either events from the wayland
      interface or data from the fd, in which case it needs to poll on both
      the wayland display fd and the device/network fd.
      The solution seems pretty straightforward: just let all threads read
      from the fd.  However, the main-thread restriction was introduced to
      avoid a race.  Simplified, main loops will do something like this:
      	/* Race here if other thread reads from fd and places events
      	 * in main eent queue.  We go to sleep in poll while sitting on
      	 * events that may stall the application if not dispatched. */
      	poll(fds, nfds, -1);
      	/* Race here if other thread reads and doesn't queue any
      	 * events for main queue. wl_display_dispatch() below will block
      	 * trying to read from the fd, while other fds in the mainloop
      	 * are ignored. */
      The restriction that only the main thread can read from the fd avoids
      these races, but has the problems described above.
      This patch introduces new API to solve both problems.  We add
      	int wl_display_prepare_read(struct wl_display *display);
      	int wl_display_read_events(struct wl_display *display);
      wl_display_prepare_read() registers the calling thread as a potential
      reader of events.  Once data is available on the fd, all reader
      threads must call wl_display_read_events(), at which point one of the
      threads will read from the fd and distribute the events to event
      queues.  When that is done, all threads return from
      From the point of view of a single thread, this ensures that between
      calling wl_display_prepare_read() and wl_display_read_events(), no
      other thread will read from the fd and queue events in its event
      queue.  This avoids the race conditions described above, and we avoid
      relying on any one thread to be available to read events.
  16. 26 Feb, 2013 1 commit
  17. 12 Dec, 2012 1 commit
  18. 24 Nov, 2012 1 commit
  19. 19 Oct, 2012 1 commit
  20. 15 Oct, 2012 5 commits
  21. 11 Oct, 2012 5 commits
    • Ander Conselvan de Oliveira's avatar
      client: Fix double locking bug · ff4afd6c
      Ander Conselvan de Oliveira authored
      The function wl_proxy_create_for_id() would try to acquire the display
      lock, but the only call path leading to it would call it with the lock
      already acquired.
      This patch removes the attempt to acquire the lock and makes the
      function static. It was exported before because client had to create
      proxy's manually when the server sent a new object id, but since commit
      9de9e39f [1] this is no longer necessary.
      [1] commit 9de9e39f
          Author: Kristian Høgsberg <krh@bitplanet.net>
          Date:   Thu Jun 28 22:01:58 2012 -0400
              Allocate client proxy automatically for new objects
      v2: Change the right function. Previous patch changed wl_proxy_create()
          instead of wl_proxy_create_for_id().
    • Kristian Høgsberg's avatar
      Split the global registry into its own wl_registry object · 9fe75537
      Kristian Høgsberg authored
      The only way to make the global object listener interface thread safe is to
      make it its own interface and make different listeners different wl_proxies.
      The core of the problem is the callback we do when a global show up or
      disappears, which we can't do with a lock held.  On the other hand we can't
      iterate the global list or the listener list without a lock held as new
      globals or listeners may come and go during the iteration.
      Making a copy of the list under the lock and then iterating after dropping
      the lock wont work either.  In case of the listener list, once we drop the
      lock another thread may unregister a listener and destroy the callbackk
      data, which means that when we eventually call that listener we'll pass it
      free memory and break everything.
      We did already solve the thread-safe callback problem, however.  It's what
      we do for all protocol events.  So we can just make the global registry
      functionality its own new interface and give each thread its own proxy.
      That way, the thread will do its own callbacks (with no locks held) and
      destroy the proxy when it's no longer interested in wl_registry events.
    • Kristian Høgsberg's avatar
      scanner: Generate client stubs for wl_display requests · 8872956d
      Kristian Høgsberg authored
      We used to special case this because of the untyped new-id argument in
      the bind request.  Now that the scanner can handle that, we can
      remove the special case.
      Switching to the generated stubs does bring an API change since we now
      also take the interface version that the client expects as an argument.
      Previously we would take this from the interface struct, but the
      application may implement a lower version than what the interface struct
      provides.  To make sure we don't try to dispatch event the client
      doesn't implement handlers for, we have to use a client supplied version
    • Kristian Høgsberg's avatar
      client: Add wl_event_queue for multi-thread dispatching · 385fe30e
      Kristian Høgsberg authored
      This introduces wl_event_queue, which is what will make multi-threaded
      wayland clients possible and useful.  The driving use case is that of a
      GL rendering thread that renders and calls eglSwapBuffer independently of
      a "main thread" that owns the wl_display and handles input events and
      everything else.  In general, the EGL and GL APIs have a threading model
      that requires the wayland client library to be usable from several threads.
      Finally, the current callback model gets into trouble even in a single
      threaded scenario: if we have to block in eglSwapBuffers, we may end up
      doing unrelated callbacks from within EGL.
      The wl_event_queue mechanism lets the application (or middleware such as
      EGL or toolkits) assign a proxy to an event queue.  Only events from objects
      associated with the queue will be put in the queue, and conversely,
      events from objects associated with the queue will not be queue up anywhere
      else.  The wl_display struct has a built-in event queue, which is considered
      the main and default event queue.  New proxies are associated with the
      same queue as the object that created them (either the object that a
      request with a new-id argument was sent to or the object that sent an
      event with a new-id argument).  A proxy can be moved to a different event
      queue by calling wl_proxy_set_queue().
      A subsystem, such as EGL, will then create its own event queue and associate
      the objects it expects to receive events from with that queue.  If EGL
      needs to block and wait for a certain event, it can keep dispatching event
      from its queue until that events comes in.  This wont call out to unrelated
      code with an EGL lock held.  Similarly, we don't risk the main thread
      handling an event from an EGL object and then calling into EGL from a
      different thread without the lock held.
    • Kristian Høgsberg's avatar
      Change filedescriptor API to be thread safe · 53d24713
      Kristian Høgsberg authored
      The update callback for the file descriptors was always a bit awkward and
      un-intuitive.  The idea was that whenever the protocol code needed to
      write data to the fd it would call the 'update' function.  This function
      would adjust the mainloop so that it polls for POLLOUT on the fd so we
      can eventually flush the data to the socket.
      The problem is that in multi-threaded applications, any thread can issue
      a request, which writes data to the output buffer and thus triggers the
      update callback.  Thus, we'll be calling out with the display mutex
      held and may call from any thread.
      The solution is to eliminate the udpate callback and just require that
      the application or server flushes all connection buffers before blocking.
      This turns out to be a simpler API, although we now require clients to
      deal with EAGAIN and non-blocking writes.  It also saves a few syscalls,
      since the socket will be writable most of the time and most writes will
      complete, so we avoid changing epoll to poll for POLLOUT, then write and
      then change it back for each write.
  22. 16 Aug, 2012 1 commit
  23. 31 May, 2012 1 commit
    • Martin Minarik's avatar
      Wayland: logging · 8e2a7867
      Martin Minarik authored
      The core libwayland libraries should not handle logging, only passing
      the error messages to subscribed functions.
      An application linked to libwayland-server or libwayland-client
      will be able to set own functions (one per library) to handle error
      Change in this series: make the wl_log return int, because
      of compatibility with printf. It will return the number of bytes logged.
  24. 27 Apr, 2012 1 commit
  25. 12 Apr, 2012 1 commit
    • Neil Roberts's avatar
      Add a public header for the version number · 18a770c8
      Neil Roberts authored
      This adds a public header so that applications can get the Wayland
      version number at compile time. This can be used to make applications
      that support compiling against multiple versions of Wayland.
      There is a separate installed header called cogl-version.h which gets
      included by both wayland-client.h and wayland-server.h
      The canonical place for the version number is the configure.ac script
      which splits it into three separate m4 defines for the major, minor
      and micro version. These are copied into the generated
      wayland-version.h header using AC_SUBST. There is also a string form
      of the complete version number.
      The version number is now also automatically copied into the two .pc
      Because the major, minor and micro parts are required it is no longer
      possible to leave the version number as 'master' when building from
      git. Most projects seem to immediately bump the git repo to a fake
      version number (usually odd) after making a release so that there is
      always a relative number that can be used for comparison. This patch
      sets the git version to 0.99.0 under the assumption that the next
      release will be 1.0.0.
  26. 28 Feb, 2012 1 commit
    • Samuel Rødal's avatar
      Rename client side wl_display_destroy() to wl_display_disconnect() · bf5a8fbb
      Samuel Rødal authored
      This avoids the clash with the wayland-server version with the same
      name, and allows linking against both wayland-client and wayland-server
      at the same time, which can be useful for unit testing purposes as
      well as for nested compositing.
      Without this there will be crashes as the wrong wl_display_destroy()
      is called.
  27. 22 Nov, 2011 1 commit
    • Kristian Høgsberg's avatar
      Add support for server allocated object IDs · bdbd6ef8
      Kristian Høgsberg authored
      We set aside a range of the object ID space for use by the server.  This
      allows the server to bind an object to an ID for a client and pass that
      object to the client.  The client can use the object immediately and the
      server can emit events to the object immdiately.
  28. 04 Sep, 2011 1 commit
  29. 27 Aug, 2011 4 commits