1. 11 Oct, 2012 8 commits
    • 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>
    • 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
      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: 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.
  2. 10 Oct, 2012 1 commit
  3. 25 Sep, 2012 1 commit
  4. 13 Sep, 2012 1 commit
  5. 16 Aug, 2012 1 commit
  6. 01 Aug, 2012 1 commit
  7. 22 Jul, 2012 1 commit
  8. 09 Jul, 2012 2 commits
  9. 02 Jul, 2012 2 commits
  10. 28 Jun, 2012 1 commit
  11. 27 Jun, 2012 1 commit
  12. 15 Jun, 2012 1 commit
  13. 01 Jun, 2012 1 commit
  14. 31 May, 2012 3 commits
  15. 29 May, 2012 1 commit
  16. 22 May, 2012 1 commit
  17. 21 May, 2012 1 commit
  18. 16 May, 2012 1 commit
    • Daniel Stone's avatar
      Convert wl_input_device to wl_seat (and friends) · aa0fb0f4
      Daniel Stone authored
      wl_input_device has been both renamed and split.  wl_seat is now a
      virtual object representing a group of logically related input devices
      with related focus.
      It now only generates one event: to let clients know that it has new
      capabilities.  It takes requests which hand back objects for the
      wl_pointer, wl_keyboard and wl_touch interfaces it exposes which all
      provide the old input interface, just under different names.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniel@fooishbar.org>
  19. 10 May, 2012 3 commits
  20. 09 May, 2012 1 commit
  21. 08 May, 2012 1 commit
  22. 03 May, 2012 1 commit
  23. 02 May, 2012 1 commit
  24. 01 May, 2012 1 commit
  25. 20 Apr, 2012 1 commit
  26. 19 Apr, 2012 1 commit
  27. 12 Apr, 2012 1 commit
    • Kristian Høgsberg's avatar
      Switch protocol to using serial numbers for ordering events and requests · 5535f155
      Kristian Høgsberg authored
      The wayland protocol, as X, uses timestamps to match up certain
      requests with input events.  The problem is that sometimes we need to
      send out an event that doesn't have a corresponding timestamped input
      event.  For example, the pointer focus surface goes away and new
      surface needs to receive a pointer enter event.  These events are
      normally timestamped with the evdev event timestamp, but in this case,
      we don't have a evdev timestamp.  So we have to go to gettimeofday (or
      clock_gettime()) and then we don't know if it's coming from the same
      time source etc.
      However for all these cases we don't need a real time timestamp, we
      just need a serial number that encodes the order of events inside the
      server.  So we introduce a serial number mechanism that we can use to
      order events.  We still need real-time timestamps for actual input
      device events (motion, buttons, keys, touch), to be able to reason
      about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
      The serial number also give us a mechanism to key together events that
      are "logically the same" such as a unicode event and a keycode event,
      or a motion event and a relative event from a raw device.