Skip to content
Snippets Groups Projects
  1. Jul 09, 2013
    • Kristian Høgsberg's avatar
      Bump version to 1.1.91 · 3f3671e9
      Kristian Høgsberg authored
      1.1.91
      3f3671e9
    • Kristian Høgsberg's avatar
    • Kristian Høgsberg's avatar
      wayland-server: Don't close display fd in fatal error handler · 93d888ae
      Kristian Høgsberg authored
      We can't do that there, we have to make sure it stays a valid fd until
      the application calls wl_display_disconnect().  Otherwise the application
      may end up poll()ing on a stale or wrong fd in case another part of the
      application (or another thread) triggered a fatal error.
      93d888ae
    • Kristian Høgsberg's avatar
      wayland-server: Return 0 from read_events() in case of EAGAIN · becca5fc
      Kristian Høgsberg authored
      Getting no data from the socket is not an error condition.  This may
      happen in case of calling prepare_read() and then read_events() with
      no other pending readers and no data in the socket.  In general,
      read_events() may not queue up events in the given event queue.  From
      a given threads point of view it doesn't matter whether events were
      read and put in a different event queue or no events were read at all.
      becca5fc
    • Neil Roberts's avatar
      wayland-client: Treat EOF when reading the wayland socket as an error · 12cea955
      Neil Roberts authored
      If EOF is encountered while reading from the Wayland socket, make
      wl_display_read_events() return -1 so that it will be treated as an
      error. The documentation for this function states that it will set
      errno when there is an error so it additionally makes up an errno of
      EPIPE.
      
      If we don't do this then when the compositor quits the Wayland socket
      will be become ready for reading but wl_display_dispatch will do
      nothing which typically makes the application take up 100% CPU. In
      particular eglSwapBuffers will likely get stuck in an infinite busy
      loop because it repeatedly calls wl_display_dispatch_queue while it
      waits for the frame callback.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=703892
      12cea955
    • Kristian Høgsberg's avatar
      wayland-server: Add wl_global_create/destroy() · 4cffa0fd
      Kristian Høgsberg authored
      This patch introduces wl_global_create() and wl_global_destroy() as
      replacements for wl_display_add_global() and wl_display_remove_global().
      The add/remove_global API did not allow a compositor to indicate
      the implemented version of a global, it just took the version from
      the interface meta data.  The problem is that the meta data
      (which lives in libwayland-server.so) can get out of sync with a
      compositor implementation.  The compositor will then advertise a
      higher version of a global than what it actually implements.
      
      The new API lets a compositor pass in a version when it registers
      a global, which solves the problem.  The add/remove API is deprecated
      with this patch and will be removed.
      4cffa0fd
  2. Jul 03, 2013
  3. Jul 02, 2013
  4. Jun 28, 2013
    • Rob Bradford's avatar
      protocol: add no_keymap format to keymap formats · 2e075874
      Rob Bradford authored
      This format is used to specify that the key button events received are not in
      relation to any key map and that the codes should be interpreted directly.
      
      v2: Use zero for the no keymap enum value and enhance the documentation
      for the enum entry.
      2e075874
  5. Jun 21, 2013
  6. Jun 20, 2013
    • Faith Ekstrand's avatar
      Free non-legacy resources inside wl_resource_destroy · 96afa347
      Faith Ekstrand authored
      
      This commit makes wl_resource_destroy automatically free all non-legacy
      resource structures.  Since wl_resource is now an opaque structure it
      doesn't make sense for the clients to be freeing it.  This checks to make
      sure that it was added through wl_client_add_object or wl_client_new_object
      and not wl_client_add_resource before it frees it.  This way if it is a
      legacy resources embedded in a structure somewhere we don't have an invalid
      free.
      
      Signed-off-by: default avatarJason Ekstrand <jason@jlekstrand.net>
      96afa347
  7. Jun 18, 2013
  8. Jun 17, 2013
    • Kristian Høgsberg's avatar
      client: Add wl_display_prepare_read() API to relax thread model assumptions · 3c7e8bfb
      Kristian Høgsberg authored
      The current thread model assumes that the application or toolkit will have
      one thread that either polls the display fd and dispatches events or just
      dispatches in a loop.  Only this main thread will read from the fd while
      all other threads will block on a pthread condition and expect the main
      thread to deliver events to them.
      
      This turns out to be too restrictive.  We can't assume that there
      always will be a thread like that.  Qt QML threaded rendering will
      block the main thread on a condition that's signaled by a rendering
      thread after it finishes rendering.  This leads to a deadlock when the
      rendering threads blocks in eglSwapBuffers(), and the main thread is
      waiting on the condition.  Another problematic use case is with games
      that has a rendering thread for a splash screen while the main thread
      is busy loading game data or compiling shaders.  The main thread isn't
      responsive and ends up blocking eglSwapBuffers() in the rendering thread.
      
      We also can't assume that there will be only one thread polling on the
      file descriptor.  A valid use case is a thread receiving data from a
      custom wayland interface as well as a device fd or network socket.
      The thread may want to wait on either events from the wayland
      interface or data from the fd, in which case it needs to poll on both
      the wayland display fd and the device/network fd.
      
      The solution seems pretty straightforward: just let all threads read
      from the fd.  However, the main-thread restriction was introduced to
      avoid a race.  Simplified, main loops will do something like this:
      
      	wl_display_dispatch_pending(display);
      
      	/* Race here if other thread reads from fd and places events
      	 * in main eent queue.  We go to sleep in poll while sitting on
      	 * events that may stall the application if not dispatched. */
      
      	poll(fds, nfds, -1);
      
      	/* Race here if other thread reads and doesn't queue any
      	 * events for main queue. wl_display_dispatch() below will block
      	 * trying to read from the fd, while other fds in the mainloop
      	 * are ignored. */
      
      	wl_display_dispatch(display);
      
      The restriction that only the main thread can read from the fd avoids
      these races, but has the problems described above.
      
      This patch introduces new API to solve both problems.  We add
      
      	int wl_display_prepare_read(struct wl_display *display);
      
      and
      
      	int wl_display_read_events(struct wl_display *display);
      
      wl_display_prepare_read() registers the calling thread as a potential
      reader of events.  Once data is available on the fd, all reader
      threads must call wl_display_read_events(), at which point one of the
      threads will read from the fd and distribute the events to event
      queues.  When that is done, all threads return from
      wl_display_read_events().
      
      From the point of view of a single thread, this ensures that between
      calling wl_display_prepare_read() and wl_display_read_events(), no
      other thread will read from the fd and queue events in its event
      queue.  This avoids the race conditions described above, and we avoid
      relying on any one thread to be available to read events.
      3c7e8bfb
  9. Jun 14, 2013
  10. Jun 07, 2013
  11. Jun 05, 2013
  12. May 28, 2013
    • Alexander Larsson's avatar
      protocol: Modes are specified in HW pixels · b6930889
      Alexander Larsson authored
      Modes are mainly meant to be used in coordination with fullscreen in
      DRIVER mode, by e.g. games. For such games what they generally want
      is to match some hardware mode and resize their window for that. We
      don't really need to complicate this with the scaling. So, we
      keep the resolutions in HW pixels, and drop the SCALED flag (as it
      is now useless).
      
      This lets you just create e.g an 800x600 buffer of scale 1 and
      fullscreen that, ignoring the output scaling factor (although you can
      of course also respect it and create a 400x300 surface at scale 2).
      Conceptually the mode change is treated like a scaling which overrides
      the normal output scale.
      
      The only complexity is the FILL mode where it can happen that the user
      specifies a buffer of the same size as the screen, but the output has scale
      2 and the buffer scale 1. Just scanning out this buffer will work, but
      effectively this is a downscaling operation, as the "real" size of the surface
      in pels is twice the size of the output. We solve this by allowing FILL to
      downscale (but still not upscale).
      b6930889
    • Alexander Larsson's avatar
      protocol: Use signed int for scale values · e782dbec
      Alexander Larsson authored
      We usually use signed ints for things like this, to avoid
      issues C sign coersion.
      e782dbec
  13. May 22, 2013
    • Alexander Larsson's avatar
      protocol: Support scaled outputs and surfaces · d68c7d8a
      Alexander Larsson authored
      This adds the wl_surface.set_buffer_scale request, and a wl_output.scale
      event. These together lets us support automatic upscaling of "old"
      clients on very high resolution monitors, while allowing "new" clients
      to take advantage of this to render at the higher resolution when the
      surface is displayed on the scaled output.
      
      It is similar to set_buffer_transform in that the buffer is stored in
      a transformed pixels (in this case scaled). This means that if an output
      is scaled we can directly use the pre-scaled buffer with additional data,
      rather than having to scale it.
      
      Additionally this adds a "scaled" flag to the wl_output.mode flags
      so that clients know which resolutions are native and which are scaled.
      
      Also, in places where the documentation was previously not clear as to
      what coordinate system was used this was fleshed out.
      
      It also adds a scaling_factor event to wl_output that specifies the
      scaling of an output.
      
      This is meant to be used for outputs with a very high DPI to tell the
      client that this particular output has subpixel precision. Coordinates
      in other parts of the protocol, like input events, relative window
      positioning and output positioning are still in the compositor space
      rather than the scaled space. However, input has subpixel precision
      so you can still get input at full resolution.
      
      This setup means global properties like mouse acceleration/speed,
      pointer size, monitor geometry, etc can be specified in a "mostly
      similar" resolution even on a multimonitor setup where some monitors
      are low dpi and some are e.g. retina-class outputs.
      d68c7d8a
Loading