1. 01 Dec, 2014 3 commits
  2. 28 Nov, 2014 4 commits
  3. 27 Nov, 2014 1 commit
  4. 26 Nov, 2014 1 commit
  5. 25 Nov, 2014 9 commits
  6. 24 Nov, 2014 1 commit
  7. 21 Nov, 2014 1 commit
  8. 19 Nov, 2014 2 commits
  9. 17 Nov, 2014 5 commits
  10. 12 Nov, 2014 2 commits
  11. 11 Nov, 2014 2 commits
  12. 10 Nov, 2014 2 commits
  13. 05 Nov, 2014 4 commits
  14. 04 Nov, 2014 3 commits
    • kabeer khan's avatar
      Protocol : Added destructor to wl_data_device interface · 0953e126
      kabeer khan authored
      [Pekka Paalanen: removed trailing whitespace, adjust bz link.]
      
      Bug: https://bugs.freedesktop.org/show_bug.cgi?id=81745
      
      Signed-off-by: default avatarkabeer khan <kabeer.khan@samsung.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      0953e126
    • Derek Foreman's avatar
      cosmetic: convert some function returns from int to bool · 322cd6dd
      Derek Foreman authored
      
      
      [Pekka Paalanen: change is_nullable_type() return value to bool.]
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      322cd6dd
    • Benjamin Herr's avatar
      connection: Leave fd open in wl_connection_destroy · 391820b0
      Benjamin Herr authored
      
      
      Calling close() on the same file descriptor that a previous call to
      close() already closed is wrong, and racy if another thread received
      that same file descriptor as a eg. new socket or actual file.
      
      There are two situations where wl_connection_destroy() would close its
      file descriptor and then another function up in the call chain would
      close the same file descriptor:
      
        * When wl_client_create() fails after calling wl_connection_create(),
          it will call wl_connection_destroy() before returning. However, its
          caller will always close the file descriptor if wl_client_create()
          fails.
      
        * wl_display_disconnect() unconditionally closes the display file
          descriptor and also calls wl_connection_destroy().
      
      So these two seem to expect wl_connection_destroy() to leave the file
      descriptor open. The other caller of wl_connection_destroy(),
      wl_client_destroy(), does however expect wl_connection_destroy() to
      close its file descriptor, alas.
      
      This patch changes wl_connection_destroy() to indulge this majority of
      two callers by simply not closing the file descriptor. For the benefit
      of wl_client_destroy(), wl_connection_destroy() then returns the
      unclosed file descriptor so that wl_client_destroy() can close it
      itself.
      
      Since wl_connection_destroy() is a private function called from few
      places, changing its semantics seemed like the more expedient way to
      address the double-close() problem than shuffling around the logic in
      wl_client_create() to somehow enable it to always avoid calling
      wl_connection_destroy().
      Signed-off-by: default avatarBenjamin Herr <ben@0x539.de>
      Reviewed-by: default avatarMarek Chalupa <mchqwerty@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      391820b0