1. 07 Mar, 2016 2 commits
    • Peter Hutterer's avatar
      doc: link between client and server doc and to the wayland book · 973a70db
      Peter Hutterer authored
      And insert "client" or "server" into the PROJECT_NAME to know which one we
      have.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      973a70db
    • Peter Hutterer's avatar
      doc: generate doxygen html output from the scanner · 2b5310a3
      Peter Hutterer authored
      This switches the scanner to generate doxygen-compatible tags for the
      generated protocol headers, and hooks up the doxygen build to generate server
      and client-side API documentation. That documentation is now in
      Client/ and Server/, respectively.
      
      GENERATE_HTML is on by default and must be disabled for the xml/man targets to
      avoid messing up the new documentation. We disable all three three targets in
      the doxyfile (xml and man default to NO anyway) to make it obvious that they
      need to be set in the per-target instructions.
      
      Each protocol is a separate doxygen @page, with each interface a @subpage.
      Wayland only has one protocol, wayland-protocols will have these nested.
      Each protocol page has a list of interfaces and the copyright and description
      where available.
      All interfaces are grouped by doxygen @defgroup and @ingroups and appear in
      "Modules" in the generated output. Each interface subpage has the description
      and a link to the actual API doc.
      Function, struct and #defines are documented in doxygen style and associated
      with the matching interface.
      
      Note that pages and groups have fixed HTML file names and are directly
      linkable/bookmark-able.
      
      The @mainpage is a separate file that's included at build time. It doesn't
      contain much other than links to where the interesting bits are. It's a static
      file though that supports markdown, so we can extend it easily in the future.
      
      For doxygen we need the new options EXTRACT_ALL and OPTIMIZE_OUTPUT_FOR_C so
      it scans C code properly. EXTRACT_STATIC is needed since most of the protocol
      hooks are static.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      2b5310a3
  2. 02 Mar, 2016 1 commit
  3. 29 Feb, 2016 1 commit
  4. 26 Feb, 2016 2 commits
  5. 20 Feb, 2016 1 commit
  6. 19 Feb, 2016 1 commit
  7. 17 Feb, 2016 6 commits
  8. 16 Feb, 2016 1 commit
  9. 11 Feb, 2016 1 commit
  10. 09 Feb, 2016 1 commit
  11. 05 Feb, 2016 2 commits
  12. 04 Feb, 2016 1 commit
  13. 02 Feb, 2016 5 commits
  14. 01 Feb, 2016 1 commit
  15. 19 Jan, 2016 5 commits
  16. 16 Jan, 2016 9 commits
    • Jonas Ådahl's avatar
      tests: Test that one can fetch the protocol error after EPIPE · c6437817
      Jonas Ådahl authored
      If a client is terminated due to some reason, it should always be
      possible to retrieve protocol error associated with the termination.
      Test that, while either using the dispatch helpers
      (wl_display_dispatch(_queue)() or the prepare read API, it should be
      possible to retrieve the error after EPIPE.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      c6437817
    • Jonas Ådahl's avatar
      tests: Pass argument to client main · 046012a6
      Jonas Ådahl authored
      Change the API to pass an "void *" argument to the client main
      function, allowing the caller to call the same main function with
      different input.
      
      A helper (client_create_noarg) is added for when no argument is passed,
      and the existing test cases are changed to use this function instead.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      046012a6
    • Jonas Ådahl's avatar
      tests: Synchronize client termination in idle callback · 7efe8fbd
      Jonas Ådahl authored
      We currently wait for clients in the wl_client destroy signal, which is
      called before the client is destructed and the socket is closed. If test
      clients rely on being closed due to the socket being closed we'd dead
      lock. Avoid this by synchronizing in an idle task that is called after
      the client is fully destroyed.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      7efe8fbd
    • Jonas Ådahl's avatar
      client: Fully flush during blocking dispatch · 242617c3
      Jonas Ådahl authored
      wl_display_flush() may fail with EAGAIN which means that not all data
      waiting in the buffer has been flushed. We later block until there is
      data to read, which could mean that we block on input from the
      compositor without having sent out all data from the client. Avoid this
      by fully flushing the socket before starting to wait.
      
      This commit also changes the array length of the struct pollfd array
      from 2 to 1, as only one element was ever used.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      242617c3
    • Jonas Ådahl's avatar
      client: Use read preparation API in wl_display_dispatch_queue() · 689fff36
      Jonas Ådahl authored
      Instead of doing things that do the equivalent of using
      wl_display_prepare_read() and friends, just use the public API. The
      only semantical difference is that we will now unlock and lock the mutex
      more times compared to before.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      689fff36
    • Jonas Ådahl's avatar
      client: Don't make EPIPE fatal if triggered when flushing · c767f35b
      Jonas Ådahl authored
      If flushing hits EPIPE it should not make it a fatal error since it
      would make it impossible to process the rest of the data available in
      the buffer. Instead, let reading the socket make EPIPE fatal, letting
      the client have the possibility to process the last messages including
      any error causing the termination.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      c767f35b
    • Jonas Ådahl's avatar
      client: Remove misplaced documentation about main loop intergration · 0b44298a
      Jonas Ådahl authored
      There was documentation about how to integrate the display server file
      descriptor in the documentation about wl_display_dispatch_pending().
      This is not the right place to put it, and it also had incorrect usage
      of the API (calling wl_display_dispatch_queue() on input on an unrelated
      fd) as an example.
      Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      0b44298a
    • Jonas Ådahl's avatar
      client: Correct documentation regarding thread safeness · 0edeeb9c
      Jonas Ådahl authored
      The current documentation about wl_display_dispatch() states one may not
      mix wl_display_dispatch(_queue)() with wl_display_prepare_read() and
      friends, but this is a misconception about how
      wl_display_dispatch(_queue)() works. The fact is that the dispatch
      functions does the equivalent of what the preparation API does
      internally, and it is safe to use together.
      
      What is not safe is to dispatch using the wl_display_dispatch(_queue)()
      functions while being prepared to read using wl_display_read_events().
      
      This patch rewrites the documentation to correctly state when the
      various API's are thread safe and how they may not be used.
      
      https://bugs.freedesktop.org/show_bug.cgi?id=91767Signed-off-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      0edeeb9c
    • Carlos Garnacho's avatar
      protocol: Add DnD actions · da7b2489
      Carlos Garnacho authored
      These 2 requests have been added:
      
      - wl_data_source.set_actions: Notifies the compositor of the available
        actions on the data source.
      - wl_data_offer.set_actions: Notifies the compositor of the available
        actions on the destination side, plus the preferred action.
      
      Out of the data from these requests, the compositor can determine the action
      both parts agree on (and let the user play a role through eg. keyboard
      modifiers). The chosen option will be notified to both parties
      through the following two requests:
      
      - wl_data_source.action
      - wl_data_offer.action
      
      In addition, the destination side can peek the source side actions through
      wl_data_offer.source_actions.
      
      Compared to the XDND protocol, there's two notable changes:
      
      - XDND lets the source suggest an action, whereas wl_data_device lets
        the destination prefer a given action. The difference is subtle here,
        it comes off as convenience because it is the drag destination which
        receives the motion events (unlike in X) and can perform action updates.
      
        The drag destination seems also in a better position to update the
        preferred action based on things like the data being transferred, the
        place being dropped, and whether the drag is client-local.
      
      - That same source-side preferred action is used in XDND to convey the
        modifier-induced action to the drag destination, which would then ack
        it, or reply with another action that's accepted (or none), this makes
        the XdndPosition/XdndStatus messaging very verbose, and synchronous
        because the drag source always needs to know the latest status/action
        for every position+action sent.
      
        Here it's the compositor which takes care of modifiers and matching
        available/accepted actions, this allows for the signaling to happen
        only whenever the actions/modifiers change for real.
      
      Roughly based on previous work by Giulio Camuffo <giuliocamuffo@gmail.com>
      
      Changes since v10:
      - Narrow down the situations where wl_data_source/offer.accept requests
        are supposed to happen.
      
      Changes since v9:
      - Deferred the protocol errors to .finish after some IRC chat with Jonas,
        added further errors if actions API is used on selection sources/offers.
      
      Changes since v8:
      - Defined further the expected behavior on "ask", described the protocol
        errors that may happen. Fix more spaces vs tabs issues.
      
      Changes since v7:
      - Misc changes after updating the progress notification patch.
      
      Changes since v6:
      - Further explanations on wl_data_source/offer.set_actions, including a
        description of "ask" actions. Added protocol errors for unknown action
        values.
      
      Changes since v5:
      - Applied rewording suggestions from Jonas Ådahl. Dropped slot reservation
        scheme for actions. Fixed indentation and other minor formatting issues.
      
      Changes since v4:
      - Minor rewording.
      
      Changes since v3:
      - Splitted from DnD progress notification changes.
      - Further rationales in commit log.
      
      Changes since v2:
      - Renamed notify_actions to set_actions on both sides, seems more consistent
        with the rest of the protocol.
      - Spelled out better which events may be triggered on the compositor side
        by the requests, the circumstances in which events are emitted, and
        what are events useful for in clients.
      - Defined a minimal common ground wrt compositor-side action picking and
        keybindings.
      - Acknowledge the possibility of compositor/toolkit defined actions, even
        though none are used at the moment.
      Changes since v1:
      - Added wl_data_offer.source_actions to let know of the actions offered
        by a data source.
      - Renamed wl_data_source.finished to "drag_finished" for clarity
      - Improved wording as suggested by Bryce
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      Reviewed-by: default avatarMichael Catanzaro <mcatanzaro@igalia.com>
      Reviewed-by: default avatarMike Blumenkrantz <zmike@samsung.com>
      Reviewed-by: Jonas Ådahl's avatarJonas Ådahl <jadahl@gmail.com>
      Reviewed-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      da7b2489