1. 21 May, 2019 3 commits
    • Carlos Garnacho's avatar
      xwayland: Handle the case of windows being realized before redirection · 9dbcdcf8
      Carlos Garnacho authored
      If Xwayland gets to realize a window meant for composition before the
      compositor redirected windows (i.e. redirect mode is not RedirectDrawManual
      yet), the window would stay "invisible" as we wouldn't create a
      wl_surface/wl_shell_surface for it at any later point.
      
      This scenario may happen if the wayland compositor sets up a X11 socket
      upfront, but waits to raise Xwayland until there are X11 clients. In this
      case the first data on the socket is the client's, the compositor can hardly
      beat that in order to redirect subwindows before the client realizes a
      Window.
      
      In order to jump across this hurdle, allow the late creation of a matching
      (shell) surface for the WindowPtr on SetWindowPixmapProc, so it is ensured
      to be created after the compositor set up redirection.
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      9dbcdcf8
    • Carlos Garnacho's avatar
      xwayland: Refactor surface creation into a separate function · 9b6eb333
      Carlos Garnacho authored
      This is just called from xwl_window_realize() ATM, but will be useful in
      future commits.
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      9b6eb333
    • Carlos Garnacho's avatar
      xwayland: Separate DamagePtr into separate window data · ec47ee88
      Carlos Garnacho authored
      This will be dissociated in future commits to handle the cases
      where windows are being realized before there is a compositor
      handling redirection.
      
      In that case, we still want the DamagePtr to be registered upfront
      on RealizeWindowProc before a corresponding xwl_window might be
      created. Most notably, it cannot be lazily created on
      SetWindowPixmapProc as damage accounting gets broken.
      Signed-off-by: Carlos Garnacho's avatarCarlos Garnacho <carlosg@gnome.org>
      ec47ee88
  2. 20 May, 2019 1 commit
    • Olivier Fourdan's avatar
      xwayland: Avoid a crash on pointer enter with a grab · 0a074463
      Olivier Fourdan authored
      On pointer enter notification, Xwayland checks for an existing pointer
      warp with a `NULL` sprite.
      
      In turn, `xwl_pointer_warp_emulator_maybe_lock()` checks for an existing
      grab and the destination window using `XYToWindow()` which does not
      check for the actual sprite not being `NULL`.
      
      So, in some cases, when the pointer enters the surface and there is an
      existing X11 grab which is not an ownerEvents grab, Xwayland would crash
      trying to dereference the `NULL` sprite pointer:
      
        #0  __GI_raise ()
        #1  __GI_abort () at abort.c:79
        #2  OsAbort () at utils.c:1351
        #3  AbortServer () at log.c:879
        #4  FatalError () at log.c:1017
        #5  OsSigHandler () at osinit.c:156
        #6  OsSigHandler () at osinit.c:110
        #7  <signal handler called>
        #8  XYToWindow (pSprite=0x0, x=0, y=0) at events.c:2880
        #9  xwl_pointer_warp_emulator_maybe_lock () at xwayland-input.c:2673
        #10 pointer_handle_enter () at xwayland-input.c:434
      
      Avoid the crash by simply checking for the sprite being not `NULL` in
      `xwl_pointer_warp_emulator_maybe_lock()`
      Signed-off-by: 's avatarOlivier Fourdan <ofourdan@redhat.com>
      Bugzilla: https://bugzilla.redhat.com/1708119
      0a074463
  3. 18 May, 2019 5 commits
  4. 17 May, 2019 4 commits
  5. 14 May, 2019 1 commit
    • Adam Jackson's avatar
      glx: Fix potential crashes in glXWait{GL,X} · 2aec5c3c
      Adam Jackson authored
      glxc->drawPriv will be NULL if the context is direct, or if it is
      current but without a bound drawable. Mesa's libGL won't normally emit
      protocol for direct contexts for these calls, but a malign client could
      still crash the server.
      2aec5c3c
  6. 12 May, 2019 1 commit
  7. 07 May, 2019 1 commit
    • Topi Miettinen's avatar
      os: add support for systemd notification · bb46e785
      Topi Miettinen authored
      It can take some time for Xorg to start. If Xorg runs as a systemd
      service and other services are based on it, they have no way to
      determine when Xorg is really ready to accept requests. Let's use
      sd_notify() provided by libsystemd to signal systemd for readiness.
      If Xorg has not been started as a systemd service, this won't do
      anything.
      Signed-off-by: Topi Miettinen's avatarTopi Miettinen <toiwoton@gmail.com>
      bb46e785
  8. 02 May, 2019 8 commits
  9. 01 May, 2019 5 commits
  10. 30 Apr, 2019 9 commits
  11. 29 Apr, 2019 1 commit
  12. 28 Apr, 2019 1 commit