1. 10 May, 2012 3 commits
  2. 09 May, 2012 1 commit
  3. 08 May, 2012 1 commit
  4. 03 May, 2012 1 commit
  5. 02 May, 2012 1 commit
  6. 01 May, 2012 1 commit
  7. 20 Apr, 2012 1 commit
  8. 19 Apr, 2012 1 commit
  9. 12 Apr, 2012 1 commit
    • Kristian Høgsberg's avatar
      Switch protocol to using serial numbers for ordering events and requests · 5535f155
      Kristian Høgsberg authored
      The wayland protocol, as X, uses timestamps to match up certain
      requests with input events.  The problem is that sometimes we need to
      send out an event that doesn't have a corresponding timestamped input
      event.  For example, the pointer focus surface goes away and new
      surface needs to receive a pointer enter event.  These events are
      normally timestamped with the evdev event timestamp, but in this case,
      we don't have a evdev timestamp.  So we have to go to gettimeofday (or
      clock_gettime()) and then we don't know if it's coming from the same
      time source etc.
      However for all these cases we don't need a real time timestamp, we
      just need a serial number that encodes the order of events inside the
      server.  So we introduce a serial number mechanism that we can use to
      order events.  We still need real-time timestamps for actual input
      device events (motion, buttons, keys, touch), to be able to reason
      about double-click speed and movement speed so events that correspond to user input carry both a serial number and a timestamp.
      The serial number also give us a mechanism to key together events that
      are "logically the same" such as a unicode event and a keycode event,
      or a motion event and a relative event from a raw device.
  10. 03 Apr, 2012 1 commit
    • Kristian Høgsberg's avatar
      shm: Allocate shm buffers through new wl_shm_pool interface · aa777e5b
      Kristian Høgsberg authored
      There's a big cost to setting up and tearing down a mmap and faulting in
      the pages to back it.  For cases where we're continuously reallocating
      shm wl_buffers (resizing a surface, typically) it is a big performance
      improvement to be able to reuse a mmap area.  This change makes the shm
      buffer allocation a two step process: first allocate a wl_shm_pool, then
      allocate a buffer from the pool.  The wl_shm_pool encapsulate the shared
      memory pool, and lets clients allocate wl_buffers backed by chunks of that
      memory.  Buffers are allocated at an offset into the pool, so it's possible
      to create multiple buffers from one pool, for example for icons or cursor
  11. 30 Mar, 2012 1 commit
  12. 26 Mar, 2012 1 commit
  13. 22 Mar, 2012 1 commit
  14. 29 Feb, 2012 1 commit
  15. 23 Feb, 2012 3 commits
  16. 16 Feb, 2012 4 commits
    • Pekka Paalanen's avatar
      protocol: remove absolute coordinates from pointer · 5536031b
      Pekka Paalanen authored
      Remove the absolute coordinate fields from the pointer motion and
      pointer_focus events. Clients are not supposed to see any global
      Fix wayland-server code accordingly. wayland-client code is unaffected.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
    • Ander Conselvan de Oliveira's avatar
      data_device: get rid of attach request · 7243062f
      Ander Conselvan de Oliveira authored
      In the effort to make everything a regular surface, remove
      data_device.attach request. To maintan the functionality, add
      an icon surface parameter to data_device.start_drag.
      Signed-off-by: Kristian H. Kristensen's avatarKristian Høgsberg <krh@bitplanet.net>
      Signed-off-by: Ander Conselvan de Oliveira's avatarAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
    • Juan Zhao's avatar
      Add fullscreen protocol · b3981136
      Juan Zhao authored
      Map the surface as a fullscreen surface. On the output the
      surface is assigned to. The client can use different fulllscreen
      method to fix the size mismatch issue: default, scale, driver
      and fill.
      Hints to indicate compositor how to deal with this fullscreen surface.
      "default" means the client has no preference on fullscreen
                behavior, policies are determined by compositor.
      "scale"   means the client prefers scaling by the compositor.
                Scaling would always preserve surface's aspect ratio.
                And the surface is centered.
      "driver"  means the client wants to switch video mode to the
                smallest mode that can fit the client buffer. If the
                sizes do not match, black borders are added. And the
                framerate parameter is used for "driver" method,
                to indicate the preferred framerate. framerate=0 means
                that the app does not care about framerate
      "fill"    means the client wants to add blackborders to the
                surface. This would be preferring 1:1 pixel mapping
                in the monitor native video mode. The surface is
    • Juan Zhao's avatar
      Add maximized protocol · 2eddfce1
      Juan Zhao authored
      A request from the client to ask the compositor to maximize the surface.
      The compositor will reply with a configure event telling
      the expected new surface size.  The operation is completed on the
      next buffer attach to this surface.
      A maximized client will fill the fullscreen of the output it is bound
      to, except the panel area. This is the main difference between
      a maximized shell surface and a fullscreen shell surface.
  17. 09 Feb, 2012 1 commit
  18. 19 Jan, 2012 2 commits
  19. 18 Jan, 2012 1 commit
    • Jesse Barnes's avatar
      scanner: Support documentation elements · 5cd04713
      Jesse Barnes authored
      On Wed, 18 Jan 2012 12:29:37 -0800
      "Kristensen, Kristian H" <kristian.h.kristensen@intel.com> wrote:
      > Yeah, that looks good.  I was thinking of a separate <description> tag
      > to avoid stuffing too much into an attribute.
      How does this look?  It adds a summary attribute to atomic elements,
      and a <description> tag with a summary for others.  Spits out enum
      documentation like this:
       * wl_display_error - global error values
       * @WL_DISPLAY_ERROR_INVALID_OBJECT: server couldn't find object
       * @WL_DISPLAY_ERROR_INVALID_METHOD: method doesn't exist on the specified interface
       * @WL_DISPLAY_ERROR_NO_MEMORY: server is out of memory
       * These errors are global and can be emitted in response to any server request.
      enum wl_display_error {
      and structure documentation like this:
       * wl_display - core global object
       * @bind: bind an object to the display
       * @sync: (none)
       * The core global object. This is a special singleton object. It is used for
       * internal wayland protocol features.
      struct wl_display_interface {
      	void (*bind)(struct wl_client *client,
      		     struct wl_resource *resource,
      		     uint32_t name,
      		     const char *interface,
      		     uint32_t version,
      		     uint32_t id);
      	void (*sync)(struct wl_client *client,
      		     struct wl_resource *resource,
      		     uint32_t callback);
  20. 11 Jan, 2012 1 commit
  21. 06 Jan, 2012 1 commit
  22. 21 Dec, 2011 1 commit
  23. 19 Dec, 2011 1 commit
  24. 29 Nov, 2011 1 commit
    • Pekka Paalanen's avatar
      protocol: introduce wl_shell_surface · 42eed323
      Pekka Paalanen authored
      Requests like 'move' and 'set_toplevel' are really methods of a surface,
      not methods of a global shell object. Move all these methods to a new
      interface, wl_shell_surface.
      The global object wl_shell will contain only 'get_shell_surface'
      request, which creates and associates a wl_shell_surface object to a
      given wl_surface object.
      This will also give the shell plugin (if you look at the demo
      compositor) means to store per-surface private data in a natural way.
      Due to a limitation in delete_id event handling on client side, the
      client must destroy its wl_shell_surface object before destroying the
      wl_surface object. Otherwise it may just leak an id.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <ppaalanen@gmail.com>
  25. 23 Nov, 2011 1 commit
    • Kristian Høgsberg's avatar
      New drag and drop / selection protocol · eae3bcb4
      Kristian Høgsberg authored
      This commit brings a big change to the DND and copy/paste interfaces.
      Most importantly the functionality is now independent of wl_shell.
      The wl_shell interface is intended for desktop style UI interaction and
      an optional and experimental interface.
      The new interface also allows receiving the DND data multiple times or
      multiple times during the drag, and the mechanism for offering and receiving
      data is now shared between DND and selections.
  26. 17 Nov, 2011 1 commit
    • Kristian Høgsberg's avatar
      Add display event to acknowledge ID deletion · 3a1e6df3
      Kristian Høgsberg authored
      We need to make sure the client doesn't reuse an object ID until the
      server has seen the destroy request.  When a client destroys an ID
      the server will now respond with the display.delete_id event, which lets
      the client block reuse until it receives the event.
  27. 24 Oct, 2011 2 commits
  28. 31 Aug, 2011 1 commit
    • Kristian Høgsberg's avatar
      Remove the wl_visual interface · c640571c
      Kristian Høgsberg authored
      The visual interface was meant to be a generic mechanism for
      specifying the content of a buffer.  It goes back to before we had the
      buffer factory interfaces (like wl_drm and wl_shm) and we wanted to
      keep it open-ended enough that yuv, png or even svg buffer or so would
      be possible.
      Now that we have the buffer abstraction, we can add different buffer
      types by introducing new interfaces that create buffers.  It only
      makes sense to leave it to those interfaces to specify the contents of
      the buffers.
      For wl_shm, this means that we now just specify the pixel format using
      an enum.  For EGL buffers, the exact pixel formats are controlled by
      the implementation (part of wl_drm and similar), and from the client
      point of view, everything is controlled using EGLConfigs.
  29. 27 Aug, 2011 3 commits