1. 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:
      
      https://lists.freedesktop.org/archives/wayland-devel/2017-November/035664.html
      
      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
      at:
      
      https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html.
      
      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>
      1b6521e6
  2. 24 Aug, 2015 1 commit
  3. 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>
      fb7e1302
  4. 04 Apr, 2013 1 commit
  5. 14 Feb, 2013 1 commit
  6. 03 Dec, 2012 1 commit
  7. 26 Sep, 2012 1 commit
  8. 25 Sep, 2012 1 commit
    • David Herrmann's avatar
      man: add man-page infrastructure · 49dee9a8
      David Herrmann authored
      This adds a man-page infrastructure based on Docbook XML files. This
      allows us to integrate the man-pages into the publican books later. An
      example page for wl_display_connect() (with an alias
      wl_display_connect_to_fd()) is also added.
      
      Feel free to add more man-pages. Function calls are put in man3 and
      overview pages into man7. All pages (including aliases) have to be added
      to the Makefile.
      
      Docbook does generate aliases automatically from the additional names that
      were put in the XML file. However, a small SED script is needed to fixup
      the include-paths in the generated troff files. If someone knows how to
      avoid that (or even install them gzip'ped), please fix it up.
      Signed-off-by: default avatarDavid Herrmann <dh.herrmann@googlemail.com>
      49dee9a8