1. 20 Mar, 2018 1 commit
  2. 19 Mar, 2018 7 commits
  3. 16 Mar, 2018 8 commits
  4. 15 Mar, 2018 2 commits
  5. 12 Mar, 2018 2 commits
  6. 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>
  7. 06 Mar, 2018 1 commit
  8. 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>
  9. 27 Feb, 2018 3 commits
  10. 26 Feb, 2018 1 commit
  11. 21 Feb, 2018 1 commit
    • Jason Gerecke's avatar
      compositor-rdp: Correct mouse scrolling direction · 9fc2e461
      Jason Gerecke authored
      The direction of scrolling in the RDP compositor appears to be inverted.
      When using Weston directly in X, sending X11 button 4 cuases window
      contents to scroll up and button 4 to be reported to xwayland clients.
      Conversely, when using Weston through RDP (xfreerdp client), sending
      X11 button 4 causes window contents to scroll down and button 5 to be
      reported to xwayland clients. The xfreerdp client does not seem to be
      the cause of this since scrolling works correctly when connecting to
      a Windows host.
      Signed-off-by: Jason Gerecke's avatarJason Gerecke <jason.gerecke@wacom.com>
      Reviewed-by: default avatarDavid Fort <contact@hardening-consulting.com>
  12. 20 Feb, 2018 7 commits
  13. 16 Feb, 2018 1 commit
  14. 15 Feb, 2018 2 commits