1. 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>
      886b09c9
  2. 06 Jul, 2014 3 commits
  3. 19 Jun, 2014 1 commit
  4. 18 Jun, 2014 1 commit
  5. 03 Jun, 2014 1 commit
  6. 28 May, 2014 1 commit
  7. 19 May, 2014 1 commit
  8. 12 May, 2014 4 commits
    • Kristian Høgsberg's avatar
      scanner: Downgrade non-increasing version error to warning · 8511544e
      Kristian Høgsberg authored
      Commit 99a72777 introduced a new error
      for when the 'since' version decreases.  It also reset the version for
      messages without a version to 1.  Versioning semantics in the spec files
      was a little under-specified and we don't want to break projects caught in
      this grey zone.
      
      This commits replaces previous configure.ac as the 1.4.93 tag and the
      final 1.5 RC.
      8511544e
    • Kristian Høgsberg's avatar
      configure.ac: Bump version 1.4.93 · bad88517
      Kristian Høgsberg authored
      This is the last RC before 1.5.
      bad88517
    • Thierry Reding's avatar
      Do not distribute generated headers · 6b278785
      Thierry Reding authored
      
      
      The wayland-server-protocol.h and wayland-client-protocol.h headers are
      currently being shipped in tarballs created using make dist. This causes
      out-of-tree builds to fail since make will detect that the headers exist
      by looking at the source directory (via VPATH) and not regenerate them.
      But as opposed to ${top_builddir}/protocol, ${top_srcdir}/protocol is
      not part of the include path and therefore the shipped files can't be
      found during compilation.
      
      Two solutions exist to this problem: 1) add ${top_srcdir}/protocol to
      the include path to allow shipped files to be used if available or 2)
      don't ship these generated files in release tarballs. The latter seems
      the most appropriate. wayland-scanner is already a prerequisite in order
      to generate wayland-protocol.c, so it is either built as part of the
      package or provided externally. Generating all files from the protocol
      definition at build time also ensures that they don't get out of sync.
      
      Both of the generated headers are already listed in Makefile.am as
      nodist_*_SOURCES, but at the same time they appear in include_HEADERS,
      which will cause them to be added to the list of distributable files
      after all. To prevent that, split them off into nodist_include_HEADERS.
      
      Note that this problem will be hidden if a previous version of wayland
      has been installed, since these files will exist in /usr/include and be
      included from there. So this build error will only show for out-of-tree
      builds on systems that don't have wayland installed yet.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      6b278785
    • Boyan Ding's avatar
      doc: Remove obsolete doxygen tags · 3e007aef
      Boyan Ding authored
      3e007aef
  9. 09 May, 2014 7 commits
  10. 06 May, 2014 3 commits
  11. 01 May, 2014 1 commit
  12. 30 Apr, 2014 1 commit
  13. 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
      timer.
      
      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.
      3e962728
    • 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
      timerfd_settime).
      
      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
      callback.
      
      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.
      74df22be
    • Giulio Camuffo's avatar
      5535757a
  14. 21 Apr, 2014 1 commit
  15. 07 Apr, 2014 2 commits
  16. 03 Apr, 2014 2 commits
  17. 01 Apr, 2014 2 commits
  18. 26 Mar, 2014 1 commit
  19. 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.
      1bf13ae9
  20. 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>
      3adcf6f1
    • 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
      presented.
      
      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>
      2c319d34
  21. 10 Mar, 2014 1 commit