1. 27 Dec, 2017 5 commits
  2. 18 Dec, 2017 1 commit
    • Pekka Paalanen's avatar
      doc: start documenting Xwayland · 14761780
      Pekka Paalanen authored
      This is a rough intro to what Xwayland is and does, with just one
      implementation detail so far (Window identification).
      I paid no attention to formatting details, those can be polished in
      follow-ups. I just want the prose out.
      I also just quickly whacked up the diagram, would be happy to see
      someone replace it with a nicer one. I just didn't have time to learn
      dot for now.
      - typo fix
      - rephrase "talking to hardware" as "driving the displays"
      - mention circular dependency in intro
      - add section to explain rootless and rootful modes
      - remove paragraph about Xwayland protocol usage
      - move TBD part to the end under a new section header
      - use "advantage" and "disadvantage" instead of "pro" and "con"
      - slight rewording on rootful mode and rootless mode paragraphs
      - removed the paragraph about the lack of shell and special Wayland
        protocol extensions
      - removed the commented out list of ideas to write
      - typo fixes pointed out by Yong
      Cc: Olivier Fourdan <ofourdan@redhat.com>
      Cc: Jonas Ådahl <jadahl@gmail.com>
      Cc: Daniel Stone <daniel@fooishbar.org>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
  3. 11 Dec, 2017 1 commit
    • Matthew Hoosier's avatar
      client: Allow absolute paths in WAYLAND_DISPLAY · 1b6521e6
      Matthew Hoosier authored
      In order to support system compositor instances, it is necessary to
      allow clients' wl_display_connect() to find the compositor's listening
      socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see
      the discussion beginning here:
      This change adjusts the client-side connection logic so that, if
      WAYLAND_DISPLAY is formatted as an absolute pathname, the socket
      connection attempt is made to just $WAYLAND_DISPLAY rather than
      usual user-private location $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.
      This change is based on Davide Bettio's submission of the same concept
      v4 changes:
      * Improved internal comments and some boundary-condition
        error checks in test case.
      * Refer to compositor as "Wayland server" rather than "Wayland
        display" in wl_display_connect() doxygen comments.
      * Remove redundant descriptions of parameter-interpretation
        mechanics from wl_display_connect() manpage. Reworked things
        to make it clear that 'name' and $WAYLAND_DISLAY are each
        capable of encoding absolute server socket paths.
      * Remove callout to reference implementation behavior in protocol
        documented. In its place there is now a simple statement that
        implementations can optionally support absolute socket paths.
      v3 changes:
      * Added test case.
      * Clarified documentation to note that 'name' parameter to wl_display_connect()
        can also be an absolute path.
      v2 changes:
      * Added backward incompatibility note to wl_display_connect() manpage.
      * Rephased wl_display_connect() manpage changes to precisely match actual
        changed behavior.
      * Added mention of new absolute path behavior in wl_display_connect()
        doxygen comments.
      * Mentioned new absolute path interpretation of WAYLAND_DISPLAY in
        protocol documentation.
      Signed-off-by: Matt Hoosier's avatarMatt Hoosier <matt.hoosier@gmail.com>
      Acked-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  4. 05 Dec, 2017 1 commit
    • Pekka Paalanen's avatar
      protocol: make get_subsurface double-buffered · de24f4dd
      Pekka Paalanen authored
      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
      However, doing the sub-surface setup always requires a wl_surface.commit
      on the parent surface unless the defaults happen to be correct.
      To make setting up a subsurface slightly easier by removing one
      possibility for a glitch, this patch amends the specification to require
      a wl_surface.commit on the parent surface for get_subsurface to
      complete. The sub-surface cannot become mapped before a parent commit.
      This change may break existing clients that relied on the glitchy
      sequence to not need a parent surface commit to map the sub-surface.
      However, presumably all uses would at least issue a
      wl_subsurface.set_position, which requires a parent surface commit to
      apply. That would guarantee that there is a parent surface commit after
      get_subsurface, and so reduces the chances of breaking anything.
      In other cases, this change may simply remove a possibility for the
      This patch also adds a note about changing wl_surface.commit behaviour
      on wl_subcompositor.get_subsurface. (That could be a separate patch.)
      The behaviour of wl_subsurface.destroy remains as specified, even though
      it is now slightly asymmetrical to get_subsurface. This is emphasized by
      adding the word "immediately". The effects of destruction were already
      explicitly documented, as is the way to achieve synchronized unmapping,
      so changing destruction behaviour would likely be more disruptive, and
      also open up more corner cases (what would happen between destroy and
      Bug: https://phabricator.freedesktop.org/T7358Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: default avatarDerek Foreman <derekf@osg.samsung.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: default avatarMartin Gräßlin <mgraesslin@kde.org>
  5. 04 Dec, 2017 8 commits
  6. 01 Dec, 2017 2 commits
  7. 29 Nov, 2017 1 commit
  8. 13 Oct, 2017 1 commit
  9. 02 Oct, 2017 1 commit
  10. 18 Sep, 2017 1 commit
  11. 25 Aug, 2017 1 commit
  12. 18 Aug, 2017 3 commits
  13. 08 Aug, 2017 2 commits
  14. 01 Aug, 2017 1 commit
  15. 27 Jul, 2017 1 commit
    • Owen Taylor's avatar
      Switch graphviz files to use HTML-style labels · 042e7ead
      Owen Taylor authored
      With recent versions of graphviz, generation of the diagrams in the documentation
      fails with:
       /usr/bin/dot -Tpng -oxml/x-architecture.png dot/x-architecture.gv
       Warning: flat edge between adjacent nodes one of which has a record shape - replace records with HTML-like labels
         Edge xserver -> comp
       Error: getsplinepoints: no spline points available for edge (xserver,comp)
       Error: lost xserver comp edge
       Error: lost xserver comp edge
       Error: lost comp xserver edge
       Error: lost comp xserver edge
      http://www.graphviz.org/content/i-havent-been-able-render-these-files-graphviz-226 indicates
      that the error message basically means that the authors of graphviz consider record-style
      labels to be deprecated and are no longer fixing errors with them. This patch changes
      the labels to be in the HTML style, which seems to require duplicating style between all
      the nodes, but it's not like these files are often edited.
      The result is not exactly the same but is quite similar.
      Reviewed-by: default avatarArmin Krezović <krezovic.armin@gmail.com>
      Tested-by: default avatarArmin Krezović <krezovic.armin@gmail.com>
  16. 25 Jul, 2017 1 commit
  17. 12 Jul, 2017 1 commit
  18. 07 Apr, 2017 1 commit
  19. 17 Mar, 2017 1 commit
  20. 16 Mar, 2017 1 commit
  21. 14 Mar, 2017 1 commit
  22. 28 Feb, 2017 1 commit
  23. 23 Feb, 2017 1 commit
  24. 21 Feb, 2017 2 commits