1. 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>
  2. 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>
  3. 16 Nov, 2016 1 commit
  4. 05 Sep, 2016 1 commit
  5. 02 Jun, 2016 1 commit
  6. 03 May, 2016 2 commits
  7. 29 Apr, 2016 1 commit
  8. 20 Feb, 2016 1 commit
  9. 04 Nov, 2015 2 commits
  10. 24 Aug, 2015 1 commit
  11. 14 Aug, 2015 1 commit
    • Dima Ryazanov's avatar
      client: require WAYLAND_DISPLAY to be set · fb7e1302
      Dima Ryazanov authored
      Although defaulting to wayland-0 seems convenient, it has an undesirable
      side effect: clients may unintentionally connect to the wrong compositor.
      Generally, it's safer to fail instead. Here's a real example:
      In Fedora 22, Gtk+ prefers Wayland over X11, though the default session is still
      a normal X11 Gnome session. When you launch a Gtk+ app, it will try Wayland,
      fail, then try X11, and succesfully start up. That works fine.
      Now suppose you launch Weston while running the Gnome session. Suddenly, all
      of the Gtk+ apps launched from Gnome will show up inside Weston instead.
      That's unexpected. There's also no good way to prevent that from happening
      (other than perhaps setting WAYLAND_DISPLAY to an invalid value when launching
      an app).
      Not using wayland-0 as the default will solve that problem: an app launched
      from the X11 Gnome session will use the X11 backend regardless of whether
      there's a wayland compositor running at the same time.
      Everything else should work as before. The compositor already sets
      the WAYLAND_DISPLAY when starting the session, so the lack of the default value
      should not make a difference to the user.
      Signed-off-by: Dima Ryazanov's avatarDima Ryazanov <dima@gmail.com>
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
      Acked-by: default avatarGiulio Camuffo <giuliocamuffo@gmail.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniel@fooishbar.org>
      Acked-by: Jasper St. Pierre's avatarJasper St. Pierre <jstpierre@mecheye.net>
      Reviewed-by: default avatarRyo Munakata <ryomnktml@gmail.com>
      [Pekka: dropped the wayland-server.c hunk, adjusted summary]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  12. 22 Jun, 2015 1 commit
  13. 19 Mar, 2015 1 commit
    • Bryce Harrington's avatar
      Spelling fixes (cosmetic) · 439b0a38
      Bryce Harrington authored
      A few typos in comments and protocol docs, no code changes.
      ./src/wayland-util.h:281: recieved  ==> received
      ./src/wayland-client.c:115: occured  ==> occurred
      ./src/wayland-client.c:156: occured  ==> occurred
      ./tests/test-compositor.c:76: parallely  ==> parallelly
      ./tests/test-compositor.c:474: recieve  ==> receive
      ./protocol/wayland.xml:1767: layed  ==> laid
      ./protocol/wayland.xml:2112: dependant  ==> dependent
      ./doc/publican/sources/Client.xml:25: recieved  ==> received
      Signed-off-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      Reviewed-by: Bill Spitzak's avatarBill Spitzak <spitzak@gmail.com>
  14. 05 Feb, 2015 1 commit
  15. 31 Jan, 2015 1 commit
  16. 30 Jan, 2015 1 commit
    • Bill Spitzak's avatar
      doc: Intro text for doxygen output in it's own file · 6be2d9aa
      Bill Spitzak authored
      (This patch has been modified to apply atop current master)
      This makes it considerably easier to edit the text and make it different
      for each library.
      To address previous concerns with this patch, I wrote some more complete
      introductory text. This is based on my understanding of these libraries, which
      may not be correct, and is pretty rudimentary for libwayland-server!
      However this intro text demonstrates how to create links to the
      doxygen-generated text. It looks like you cannot link to methods easily as the
      link name contains a hash number, but links to objects and classes work.
      Reviewed-by: default avatarJon A. Cruz <jonc@osg.samsung.com>
      Tested-by: default avatarJon A. Cruz <jonc@osg.samsung.com>
  17. 29 Jan, 2015 3 commits
  18. 27 Jan, 2015 3 commits
  19. 24 Jan, 2015 3 commits
  20. 19 Dec, 2014 5 commits
  21. 18 Dec, 2014 3 commits
  22. 16 Dec, 2014 2 commits
  23. 05 Dec, 2014 2 commits
  24. 01 Dec, 2014 1 commit