1. 14 Aug, 2020 1 commit
  2. 16 Jun, 2020 1 commit
    • Simon Ser's avatar
      protocol: disambiguate key codes in wl_keyboard.key · 1dfd2169
      Simon Ser authored
      
      
      Explain that wl_keyboard.key yields platform-specific key codes.
      Some compositors use Linux key codes (defined in the
      linux/input-event-codes.h header file, e.g. KEY_ESC), however
      clients should not assume that this is always the case. The only
      reliable way for clients to interpret key codes is to feed them
      into a keyboard mapping.
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      1dfd2169
  3. 12 Jun, 2020 2 commits
  4. 05 Jun, 2020 1 commit
  5. 29 Apr, 2020 1 commit
  6. 05 Mar, 2020 1 commit
  7. 21 Jan, 2020 1 commit
  8. 03 Jan, 2020 1 commit
  9. 10 Sep, 2019 1 commit
  10. 06 Sep, 2019 2 commits
  11. 17 Aug, 2019 1 commit
    • Drew DeVault's avatar
      Improve description of wl_surface · 17e49ba8
      Drew DeVault authored and Simon Ser's avatar Simon Ser committed
      The original text makes some assumptions about surfaces which may not be
      true and fails to capture some details which are important to the
      essential traits of a wl_surface.
      17e49ba8
  12. 09 Jul, 2019 1 commit
    • Scott Anderson's avatar
      wayland.xml: Make releases for multiple 'wl_surface.attach' undefined · a2817833
      Scott Anderson authored and Simon Ser's avatar Simon Ser committed
      
      
      Fixes #46
      
      The way wl_buffer is specified makes this situation inherently racy,
      meaning there is no way this can be done unambiguously. Current real
      compositor implementations already have differing behaviour for this, so
      any client relying on it was already broken, if any such client exists.
      
      This specifically only singles out wl_buffer.release as being undefined;
      every other aspect of it should still be valid. This is so existing and
      correct uses of multiple attaches are still valid, where a
      "static"/immutable wl_buffer is being used (i.e. they don't care about
      the release event).
      Signed-off-by: Scott Anderson's avatarScott Anderson <scott.anderson@collabora.com>
      a2817833
  13. 05 Jul, 2019 1 commit
  14. 27 Apr, 2019 1 commit
  15. 19 Apr, 2019 1 commit
  16. 20 Feb, 2019 1 commit
  17. 29 Jan, 2019 1 commit
    • Christopher James Halse Rogers's avatar
      proto, server: Add internal server error message. (v2) · d3251402
      Christopher James Halse Rogers authored and Pekka Paalanen's avatar Pekka Paalanen committed
      
      
      Many languages such as C++ or Rust have an unwinding error-reporting
      mechanism. Code in these languages can (and must!) wrap request handling
      callbacks in unwind guards to avoid undefined behaviour.
      
      As a consequence such code will detect internal server errors, but have
      no way to communicate such failures to the client.
      
      This adds a WL_DISPLAY_ERROR_IMPLEMENTATION error to wl_display so that
      such code can notify (and disconnect) clients which hit internal bugs.
      While servers can currently abuse other wl_display errors for the same
      effect, adding an explicit error code allows clients to tell the
      difference between errors which are their fault and errors which are the
      server's fault. This is particularly interesting for automated bug
      reporting.
      
      v2: Rename error from "internal" to "implementation", in sympathy with
          X11's BadImplementation error.
          Add more justification in the commit message.
      Signed-off-by: Christopher James Halse Rogers's avatarChristopher James Halse Rogers <christopher.halse.rogers@canonical.com>
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.com>
      d3251402
  18. 30 Nov, 2018 2 commits
  19. 24 Jul, 2018 1 commit
  20. 05 Dec, 2017 1 commit
    • Pekka Paalanen's avatar
      protocol: make get_subsurface double-buffered · de24f4dd
      Pekka Paalanen authored and Daniel Stone's avatar Daniel Stone committed
      The existing specification was not explicitly clear on when
      wl_subcompositor.get_subsurface request actually adds the sub-surface to
      the parent in the compositor's scenegraph. The implicit assumption was
      that this happens immediately, but it was not written anywhere.
      
      If it happens immediately, the client doing things in a wrong order may
      cause a glitch on screen. Particularly, if the wl_surface B that is
      going to be a sub-surface for wl_surface A (the parent) already has a
      buffer committed, and the parent surface is mapped, then get_subsurface
      will (may?) cause wl_surface B to become mapped immediately. That leaves
      no time to set up the sub-surface z-order or position before mapping,
      hence there can be a visible glitch.
      
      The way to avoid that, given that the parent surface is mapped, is to
      not commit a buffer to wl_surface B until all the sub-surface setup is
      done.
      
      However, doing the sub-surface setup always requires a wl_surface.commit
      on the parent surface...
      de24f4dd
  21. 04 Dec, 2017 1 commit
  22. 02 Oct, 2017 1 commit
  23. 24 Jan, 2017 1 commit
  24. 21 Nov, 2016 2 commits
  25. 16 Nov, 2016 1 commit
  26. 10 Nov, 2016 3 commits
  27. 13 Sep, 2016 1 commit
  28. 12 Aug, 2016 7 commits