1. 09 May, 2014 7 commits
  2. 06 May, 2014 3 commits
  3. 01 May, 2014 1 commit
  4. 30 Apr, 2014 1 commit
  5. 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
  6. 21 Apr, 2014 1 commit
  7. 07 Apr, 2014 2 commits
  8. 03 Apr, 2014 2 commits
  9. 01 Apr, 2014 2 commits
  10. 26 Mar, 2014 1 commit
  11. 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.
  12. 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>
  13. 10 Mar, 2014 4 commits
  14. 08 Mar, 2014 1 commit
  15. 07 Mar, 2014 5 commits
  16. 18 Feb, 2014 4 commits