1. 01 May, 2014 1 commit
  2. 30 Apr, 2014 1 commit
  3. 25 Apr, 2014 3 commits
    • Andrew Wedgbury's avatar
      Use non-blocking timerfd to prevent blocking when updating timer event sources · 3e962728
      Andrew Wedgbury authored
      This implements a simple fix for the blocking problem that occurs when
      updating a timer event source after the timer expires, but before its
      callback is dispatched. This can happen when another event happens during the
      same epoll wakeup as the timer event, and causes the read() call in
      wl_event_source_timer_dispatch() to block for the updated duration of the
      We never want this read() call to block, so I believe it makes sense for the
      timerfd to be non-blocking, and we simply ignore the case where the read fails
      with EAGAIN. We still report all other errors as before, and still ignore the
      actual value read from the socket.
      With this change, the event_loop_timer_updates unit test case I submitted
      previously now passes, and weston appears to work as before.
    • Andrew Wedgbury's avatar
      test: Add test showing blocking problem when updating timers · 74df22be
      Andrew Wedgbury authored
      I've noticed a blocking problem in Wayland's event-loop code when updating
      timer event sources. The problem occurs if you update the timer at a point
      after is has expired, but before it has been dispatched, i.e. from an event
      callback that happens during the same epoll wakeup.
      When the timer is subsequently dispatched, wl_event_source_timer_dispatch
      blocks for the duration of the new timeout in its call to read() from the
      timer fd (which is the expected behaviour according to the man page for
      This isn't too uncommon a scenario - for example, a socket with an associated
      timeout timer. You'd typically want to update the timer when reading from the
      socket. This is how I noticed the issue, since I was setting a timeout of
      1 minute, and saw my server blocking for this duration!
      The following patch adds a (currently failing) test case to Wayland's
      event-loop-test.c. It demonstrates the problem using two timers, which are
      set to expire at the same time. The first timer to receive its expiry
      callback updates the other timer with a much larger timeout, which then
      causes the test to block for this timeout before calling the second timer's
      As for a fix, I'm not so sure (which is why I thought I'd post the failing
      test case first to show what I mean). I notice that it doesn't actually do
      anything with the value read from the timerfd socket, which gives the number
      of times the timer expired since the last read, or when the timer was last
      updated (which blocks if the timer hasn't yet expired). I believe this value
      should always read as 1 anyway, since we don't use periodic timers.
      A simple fix would be to use the TFD_NONBLOCK option when creating the
      timerfd, ensuring that the read call won't block. We'd then have to ignore
      the case when the read returns EAGAIN.
    • Giulio Camuffo's avatar
  4. 21 Apr, 2014 1 commit
  5. 07 Apr, 2014 2 commits
  6. 03 Apr, 2014 2 commits
  7. 01 Apr, 2014 2 commits
  8. 26 Mar, 2014 1 commit
  9. 25 Mar, 2014 1 commit
    • Jasper St. Pierre's avatar
      server: Kill some unnecessary logs · 1bf13ae9
      Jasper St. Pierre authored
      In order to set a logging function all the time, the output we get
      needs to be useful. Logging about trivial things like the socket
      we're using and when clients disconnect doesn't realy help anyone.
  10. 11 Mar, 2014 2 commits
    • Bryce W. Harrington's avatar
      tests: Fix build of noinst fixed-benchmark test · 3adcf6f1
      Bryce W. Harrington authored
      Solves this build error:
        tests/fixed-benchmark.o: In function `benchmark':
        ./wayland/tests/fixed-benchmark.c:82: undefined reference to `clock_gettime'
        ./wayland/tests/fixed-benchmark.c:84: undefined reference to `clock_gettime'
      Signed-off-by: default avatarBryce Harrington <b.harrington@samsung.com>
    • Pekka Paalanen's avatar
      protocol: try to clarify frame callback semantics · 2c319d34
      Pekka Paalanen authored
      "the callback event will arrive after the next output refresh" is wrong,
      if you interpret "output refresh" as framebuffer flip or the moment when
      the new pixels turn into light the first time. Weston has probably never
      worked this way.
      Weston triggers the frame callbacks when it submits repainting commands
      to the GPU, which is before the framebuffer flip.
      Strike the incorrect claim, and the rest of the paragraph which no
      longer offers useful information.
      As a replacement, expand on the "throttling and driving animations"
      characteristic. The main purpose is to let clients animate at the
      display refresh rate, while avoiding drawing frames that will never be
      The new claim is that the server should give some time between
      triggering frame callbacks and repainting itself, for clients to draw
      and commit. This is somewhat intimate with the repaint scheduling
      algorithm a compositor uses, but hopefully the right intention.
      Another point of this update is to imply, that frame callbacks should
      not be used to count compositor repaint cycles nor monitor refresh
      cycles. It has never been guaranteed to work. Removing the mention of
      frame callback without an attach hopefully discourages such use.
      v2: Don't just remove a paragraph, but add useful information about the
      request's intent.
      v3: Specify the order of posting frame callbacks.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Cc: Axel Davy <axel.davy@ens.fr>
      Cc: Jason Ekstrand <jason@jlekstrand.net>
  11. 10 Mar, 2014 4 commits
  12. 08 Mar, 2014 1 commit
  13. 07 Mar, 2014 5 commits
  14. 18 Feb, 2014 5 commits
  15. 10 Feb, 2014 1 commit
  16. 08 Feb, 2014 2 commits
    • Kristian Høgsberg's avatar
      client: Queue display events on private queue and always dispatch · b9eebce0
      Kristian Høgsberg authored
      The wl_display events (error and delete_id) need to be handled even
      if the default queue doesn't get dispatched for a while.  For example,
      a busy EGL rendering loop hits wl_display.sync every eglSwapBuffers()
      and we need to process the delete_id events to maintain the object ID
      data structure.
      As it is, that doesn't happen, but with this change we special case
      wl_display events.  We put them on a custom, private queue and when
      dispatching events, we always dispatch display_queue events first.
      The wl_display proxy should still be the default_queue, so that objects
      created from wl_display requests get assigned to that.
    • Kristian Høgsberg's avatar
      client: Rename display->queue to default_queue · a9eb563f
      Kristian Høgsberg authored
      We'll add a new queue next, so rename the default queue first.
  17. 07 Feb, 2014 1 commit
  18. 06 Feb, 2014 2 commits
    • Jason Ekstrand's avatar
    • Neil Roberts's avatar
      Don't deref the sample pointer in the wl_container_of macro · a18e3441
      Neil Roberts authored
      The previous implementation of the wl_container_of macro was
      dereferencing the sample pointer in order to get an address of the
      member to calculate the offset. Ideally this shouldn't cause any
      problems because the dereference doesn't actually cause the address to
      be read from so it shouldn't matter if the pointer is uninitialised.
      However this is probably technically invalid and could cause undefined
      behavior. Clang appears to take advantage of this undefined behavior
      and doesn't bother doing the subtraction. It also gives a warning when
      it does this.
      The documentation for wl_container_of implies that it should only be
      given an initialised pointer and if that is done then there is no
      problem with clang. However this is quite easy to forget and doesn't
      cause any problems or warnings with gcc so it's quite easy to
      accidentally break clang.
      To fix the problem this changes the macro to use pointer -
      offsetof(__typeof__(sample), member) so that it doesn't need to deref
      the sample pointer. This does however require that the __typeof__
      operator is supported by the compiler. In practice we probably only
      care about gcc and clang and both of these happily support the
      The previous implementation was also using __typeof__ but it had a
      fallback path avoiding it when the operator isn't available. The
      fallback effectively has undefined behaviour and it is targetting
      unknown compilers so it is probably not a good idea to leave it in.
      Instead, this patch just removes it. If someone finds a compiler that
      doesn't have __typeof__ but does work with the old implementation then
      maybe they could add it back in as a special case.
      This patch removes the initialisation anywhere where the sample
      pointer was being unitialised before using wl_container_of. The
      documentation for the macro has also been updated to specify that this
      is OK.
  19. 31 Jan, 2014 3 commits