1. 09 Apr, 2018 1 commit
  2. 05 Apr, 2018 1 commit
  3. 02 Apr, 2018 2 commits
  4. 28 Mar, 2018 8 commits
  5. 27 Mar, 2018 1 commit
  6. 20 Mar, 2018 2 commits
  7. 19 Mar, 2018 7 commits
  8. 16 Mar, 2018 8 commits
  9. 15 Mar, 2018 2 commits
  10. 12 Mar, 2018 2 commits
  11. 09 Mar, 2018 3 commits
    • Daniel Stone's avatar
      compositor-wayland: Ignore pointer enter on destroyed surface · 3f839374
      Daniel Stone authored
      Due to race conditions, it is (vanishingly unlikely but) possible to
      receive a wl_pointer.enter event referring to a wl_surface we have just
      destroyed. If this happens, wl_surface will be NULL. Detect this, clear
      out our focus, and return.
      Other pointer and keyboard events are robust against destroyed surfaces.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
      [Pekka: remove call to input_set_cursor()]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
    • Pekka Paalanen's avatar
      input: never set keyboard focus without wl_resource · 72e183bd
      Pekka Paalanen authored
      Do not attempt to set keyboard focus to a surface that has no
      wl_resource. The destroy listener hangs off the wl_resource, so if that
      is not present, nothing will clean up the pointer when the
      weston_surface gets destroyed and it goes stale.
      As keyboard_focus_resource_destroyed() sets the focus to NULL, this
      patch should be enough to guarantee that the keyboard focus surface will
      always have a wl_resource.
      I have confirmed the added branch in weston_keyboard_set_focus() can be
      hit, but doing so is hard.
      My test case has weston/x11 with two outputs, and weston/wayland
      --sprawl running on top of that, then closing the parent compositor
      output windows one by one. Sometimes it hits, often it does not. Having
      the window closing animation enabled may help to hit it.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
    • Pekka Paalanen's avatar
      compositor-wayland: handle wl_keyboard.enter(NULL) · 8d6e14c9
      Pekka Paalanen authored
      Destroying an output (wl_surface) can race against the parent compositor
      sending wl_keyboard.enter. When this race is lost, wayland-backend
      receives wl_keyboard.enter with a NULL wl_surface for the surface it
      just destroyed.
      Handle this case by ignoring such enter events. Since it is
      theoretically possible to follow enter with key events, drop those too.
      The modifiers event is sent before enter, so we cannot drop that on the
      same condition.
      wl_keyboard.leave handler seems to already handle the NULL focus case,
      but there is a question if the notify_keyboard_focus_out() call should
      be avoided.
      This patch fixes a hard to reproduce crash. I was running weston/x11
      with two outputs, and weston/wayland --sprawl inside that, then closing
      the parent compositor windows one by one. Sometimes it would trigger
      this crash.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
  12. 06 Mar, 2018 1 commit
  13. 01 Mar, 2018 1 commit
    • Chris Wilson's avatar
      gl-renderer: Create a high priority context · b678befb
      Chris Wilson authored
      EGL_IMG_context_priority allows the client to request that their
      rendering be considered high priority. For ourselves, this is important
      as we are interactive and any delay in our rendering causes input-output
      jitter; a less than smooth user interactive. So if the driver supports
      setting the context priority, try and create our EGLContext as high
      priority. The driver may reject our request due to system restrictions,
      in which case it will fallback to normal priority, but if successful it
      will reschedule our rendering and all of its dependencies to execute
      earlier, especially important when the GPU is being hogged by background
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Acked-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  14. 27 Feb, 2018 1 commit
    • Daniel Stone's avatar
      compositor-drm: Remove no_addfb2 handling · 1de42525
      Daniel Stone authored
      If AddFB2 ever fails for any reason, we fall back to legacy AddFB, which
      doesn't support the same swathe of formats, or multi-planar formats, or
      This can happen with arbitrary client buffers, condemning us to the
      fallback forever more. Remove this, at the cost of an unnecessary ioctl
      for users on old kernels without AddFB2; unfortunately, we cannot detect
      the complete absence of the ioctl, as the return here is -EINVAL rather
      than -ENOTTY.
      A check for whether or not the format is valid has been replaced with an
      assert, as its callers either check that the format is non-zero, return
      a FourCC format code from GBM, or use a static FourCC format.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>