1. 15 Oct, 2012 5 commits
    • Tiago Vignatti's avatar
      doc: Remove superfluous 'index' · 29c20e2e
      Tiago Vignatti authored
      We're not setting any sort of index. Remove for now.
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@intel.com>
    • Tiago Vignatti's avatar
      doc: publican: Automate version generation · 99c55c96
      Tiago Vignatti authored
      It seems reasonable to use protocol's version for the documentation as well.
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@intel.com>
    • Tiago Vignatti's avatar
      doc: publican: Set table of contents depth to 1 · 2533ed10
      Tiago Vignatti authored
      This way looks more pretty, in particular for the Appendix which spawns a big
      subsections chain.
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@intel.com>
    • Kristian Høgsberg's avatar
      client: Return number of events dispatched from dispatch functions · f8d55a87
      Kristian Høgsberg authored
      To let clients determine whether any events were dispatched, we return
      the number of dispatched events.  An event source with an event queue
      (such as wl_display or an X connection) may queue up event as a result of
      processing a different event source (data on a network socket, timerfd etc).
      After dispatching data from fd (or just before blocking) we have to check
      such event sources, which is what wl_event_source_check() is used for.
      A checked event source will have its handler called with mask=0 just
      before blocking.  If any work is done in any of these handlers, we have
      to check all the checked sources again, since the work could have queued up
      events in a different source.  This is why the event handlers must return
      a positive number if events were handled.  Which in turn is why we need
      the wl_display dispatch functions to return that as well.
    • Kristian Høgsberg's avatar
      client: Add wl_display_dispatch_pending() for dispatching without reading · 78cfa967
      Kristian Høgsberg authored
      If the main thread ends up dispatching a non-main queue, and not in
      a wl_display_dispatch() callback, we may queue up main queue events and read
      all data from the socket fd.  When we get back to the main loop, the
      socket fd is no longer readable and nothing will trigger dispatching of
      the queued up events.
      The new function wl_display_dispatch_pending() will dispatch any pending
      events, but not attempt to read from the socket.  Clients that integrate
      the wayland socket fd into a main loop should call
      wl_display_dispatch_pending() and then wl_display_flush()
      before going back to blocking in poll(2) or similar mechanism.
  2. 11 Oct, 2012 21 commits
    • Kristian Høgsberg's avatar
      client: Discard proxies with no implementation at dispatch time · 18495347
      Kristian Høgsberg authored
      We need to queue up events even if a proxy doesn't have an implementation
      (listener).  In case of server created new objects, the client haven't
      had a chance to set the listener when the first events to the new object
      come in.  So now we always queue up events and discard them at
      dispatch time if they don't have a listener at that point.
    • Kristian Høgsberg's avatar
      client: Don't forget to init and destroy mutex · d4cc1cd0
      Kristian Høgsberg authored
      These chunks were dropped at some point, thanks to David Herrmann for
      spotting the omission.
    • Kristian Høgsberg's avatar
      connection: Print object id for new-id arguments in deubug output · 9272fb8f
      Kristian Høgsberg authored
      We can't use the same behaviour in both the client and the server.  In the
      client this is a wl_proxy pointer in the server it's a pointer to the
      uint32_t object id.  This doesn't fix the problem, but it's a slightly
      more useful default, since we typically use WAYLAND_DEBUG on the client.
    • 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().
    • Pekka Paalanen's avatar
      protocol: clarify multiple wl_surface.attach · eb5fae32
      Pekka Paalanen authored
      Explicitly say what happens with the wl_buffer.release event, if you
      attach several wl_buffers without a commit in between.
      Reported-by: default avatarDavid Herrmann <dh.herrmann@googlemail.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Ander Conselvan de Oliveira's avatar
      data-device: Don't fake an attach event on drag icon surface · 0a27ce1f
      Ander Conselvan de Oliveira authored
      Emit a new drag icon signal instead and let the compositor handle the
      unmapping of the icon surface.
    • Pekka Paalanen's avatar
      protocol: fix clarification of input region on drags and pointers · ae8d4b59
      Pekka Paalanen authored
      The previous clarification did not follow the current implementation in
      Weston, where when a surface stops being a cursor or an icon, it becomes
      a plain unmapped surface again.
      Rewrite the related paragraphs, and fix some typos while at it.
      For start drag, make it explicit of which surface argument we are
      talking about.
      Make the input region undefined when the use ends. Most likely no-one
      will re-use these surfaces for anything else than the same use case, so
      leave some slack for the implementations to avoid useless work on
      resetting the regions.
      Reported-by: default avatarAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Pekka Paalanen's avatar
      protocol: elaborate on wl_buffer · e09ac645
      Pekka Paalanen authored
      Spell out exactly when a client may re-use a wl_buffer or its backing
      storage. Mention the optimization for GL-compositor with wl_shm-clients.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Pekka Paalanen's avatar
      protocol: wl_surface.frame needs wl_surface.commit · a4fd9e65
      Pekka Paalanen authored
      Clarify, when frame request takes effect.
      Explain when to send/receive the callback.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Pekka Paalanen's avatar
      protocol: clarify input region on drags and pointers · b61c0f47
      Pekka Paalanen authored
      Drag icon and cursor surfaces must never receive input, so their input
      region is always empty.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Pekka Paalanen's avatar
      protocol: double-buffered state for wl_surface · 39624020
      Pekka Paalanen authored
      This change breaks the protocol.
      The current protocol is racy in that updates to surface content and
      surface state (e.g. damage, input and opaque regions) are not guaranteed
      to happen at the same time. Due to protocol buffering and handling
      practices, the issues are very hard to trigger.
      Committing damage to a surface at arbitrary times makes it hard to
      track when the wl_buffer is being read by the server, and when it is
      safe to overwrite (the case of wl_shm with a single buffer reused
      This protocol change introduces the concept of double-buffered state.
      Such state is accumulated and cached in the server, unused, until the
      final commit request. The surface will receive its new content and apply
      its new state atomically.
      A wl_surface.commit request is added to the protocol. This is thought to
      be more clear, than having wl_surface.attach committing implicitly, and
      then having another request to commit without attaching, as would be
      required for a GL app that wants to change e.g. input region without
      When these changes are implemented, clients do not have to worry about
      ordering damage vs. input region vs. attach vs. ... anymore. Clients set
      the state in any order they want, and kick it all in with a commit.
      The interactions between wl_surface.attach, (wl_surface.commit,)
      wl_buffer.release, and wl_buffer.destroy have been undocumented. Only
      careful inspection of the compositor code has told when a wl_buffer is
      free for re-use, especially for wl_shm and wrt. wl_surface.damage.
      Try to clarify how it all should work, and what happens if the wl_buffer
      gets destroyed.
      An additional minor fix: allow NULL argument to
      wl_surface.set_opaque_region. The wording in the documentation already
      implied that a nil region is allowed.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Kristian Høgsberg's avatar
      Fix typecheck in case of multiple instances of type meta data · 4f9cf6ec
      Kristian Høgsberg authored
      In most cases the pointer equality test is sufficient.  However, in
      some cases, depending on how things are split across shared objects,
      we can end up with multiple instances of the interface metadata
      constants.  So if the pointers match, the interfaces are equal, if
      they don't match we have to compare the interface names.
    • Ander Conselvan de Oliveira's avatar
      doc: Update drag and drop section and add info about selections · e0680250
      Ander Conselvan de Oliveira authored
      Replace the outdated section about drag and drop support with a
      rewritten section covering the data source/offer mechanism and
      wl_data_device, explaining how selection and drag ang drop works.
    • Kristian Høgsberg's avatar
      connection: Move object lookup out of wl_connection_demarshal() · 5d2b32b1
      Kristian Høgsberg authored
      On the client side where we queue up multiple events before dispatching, we
      need to look up the receiving proxy and argument proxies immediately before
      calling the handler.  Between queueing up multiple events and eventually
      invoking the handler, previous handlers may have destroyed some of the
    • 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
      scanner: Send interface name and version for types new_id args · 85a6a470
      Kristian Høgsberg authored
      This makes the scanner generate the code and meta data to send the
      interface name and version when we pass a typeless new_id.  This way, the
      generic factory mechanism provided by wl_display.bind can be provided by
      any interface.
    • 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
      client: Make wl_display thread safe · de961dc1
      Kristian Høgsberg authored
      Not all entry points are thread safe: global listeners and global lookup
      is still only main thread.
    • Kristian Høgsberg's avatar
      client: Split event handling into demarshal and dispatch steps · ce1f4c29
      Kristian Høgsberg authored
      This lets us demarshal with a mutex held and then do dispatching after
      releasing the mutex.
    • 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.
  3. 10 Oct, 2012 7 commits
  4. 01 Oct, 2012 1 commit
  5. 26 Sep, 2012 1 commit
  6. 25 Sep, 2012 2 commits
    • David Herrmann's avatar
      man: add man-page infrastructure · 49dee9a8
      David Herrmann authored
      This adds a man-page infrastructure based on Docbook XML files. This
      allows us to integrate the man-pages into the publican books later. An
      example page for wl_display_connect() (with an alias
      wl_display_connect_to_fd()) is also added.
      Feel free to add more man-pages. Function calls are put in man3 and
      overview pages into man7. All pages (including aliases) have to be added
      to the Makefile.
      Docbook does generate aliases automatically from the additional names that
      were put in the XML file. However, a small SED script is needed to fixup
      the include-paths in the generated troff files. If someone knows how to
      avoid that (or even install them gzip'ped), please fix it up.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@googlemail.com>
    • Tiago Vignatti's avatar
      protocol: Fix typo · 35d8da8e
      Tiago Vignatti authored
      Signed-off-by: default avatarTiago Vignatti <tiago.vignatti@intel.com>
  7. 13 Sep, 2012 1 commit
  8. 12 Sep, 2012 1 commit
    • David Herrmann's avatar
      event-loop: export wl_event_loop_dispatch_idle() · 003a946a
      David Herrmann authored
      When integrating the wayland event-loop into another event-loop, we
      currently have no chance of checking whether there are pending idle
      sources that have to be called. This patch exports the
      "dispatch_idle_sources()" call so other event loops can call this before
      going to sleep. This is what wl_event_loop_dispatch() currently does so we
      simply allow external event-loops to do the same now.
      To avoid breaking existing applications, we keep the call to
      dispatch_idle_sources() in wl_event_loop_dispatch() for now. However, if
      we want we can remove this later and require every application to call
      this manually. This needs to be discussed, but the overhead is negligible
      so we will probably leave it as it is.
      This finally allows to fully integrate the wayland-server API into
      existing event-loops without any nasty workarounds.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@googlemail.com>
  9. 11 Sep, 2012 1 commit
    • David Herrmann's avatar
      wayland-server: return new ID in wl_client_add_resource() · 9fe135c4
      David Herrmann authored
      wl_client_add_resource() used to return no error even though the new
      resource wasn't added to the client. This currently makes it very easy to
      DOS weston by simply posting thousands of "create_surface" requests with
      an invalid ID. Weston simply assumes the wl_client_add_resource() request
      succeeds but will never destroy the surface again as the "destroy" signal
      is never called (because the surface isn't linked into the wl_map).
      This change makes wl_client_add_resource() return the new ID of the added
      object and 0 on failure. Servers (like weston) can now correctly
      immediately destroy the surface when this call fails instead of leaving
      the surface around and producing memory-leaks.
      Instead of returning -1 on failure and 0 on success, I made it return the
      new ID as this seems more appropriate. We can directly use it when calling
      it with new_id==0.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@googlemail.com>