1. 05 Nov, 2022 1 commit
    • pkubaj's avatar
      Fix build on FreeBSD/powerpc* · 8c54d590
      pkubaj authored and Alan Coopersmith's avatar Alan Coopersmith committed
      Current error:
      ld: error: undefined symbol: xf86EnableIO
      >>> referenced by xf86Configure.c
      >>>               libxorg_common.a.p/xf86Configure.c.o:(DoConfigure) in archive hw/xfree86/common/libxorg_common.a
      >>> referenced by xf86Events.c
      >>>               libxorg_common.a.p/xf86Events.c.o:(xf86VTEnter) in archive hw/xfree86/common/libxorg_common.a
      >>> referenced by xf86Init.c
      >>>               libxorg_common.a.p/xf86Init.c.o:(InitOutput) in archive hw/xfree86/common/libxorg_common.a
      >>> referenced 1 more times
  2. 28 Oct, 2022 5 commits
  3. 19 Oct, 2022 3 commits
  4. 18 Oct, 2022 1 commit
  5. 28 Sep, 2022 1 commit
  6. 20 Sep, 2022 1 commit
  7. 13 Sep, 2022 1 commit
    • Olivier Fourdan's avatar
      xwayland: Prevent Xserver grabs with rootless · a77d95af
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Because of the design of most Wayland compositors, where the compositor
      is both a Wayland server and an X11 window manager, any X11 client
      issuing a server grab (i.e. XGrabServer()) can possibly hang the whole
      desktop when Xwayland is running rootless.
      This can happen with e.g. ImageMagick's import command with mutter.
      1. "import" is launched and issues an XServerGrab(),
      2. Xwayland restricts access to that "import" X11 client alone,
      3. mutter continues to process events until it needs to sync with
         Xwayland (there's variability in time before the hang occurs),
      4. When mutter does an XSync() (explicitly or implicitly through some
         other Xlib call), it will stop waiting for Xwayland to reply,
      5. Xwayland waits for the XServerGrab() to be released by import,
      6. "import" waits for a user input to release the XServerGrab(),
      7. mutter is stuck waiting on Xwayland and does not process input
      To prevent this, re-route the GrabServer/UngrabServer requests and
      pretend the grab works but actually does nothing at all for all clients
      but the X11 window manager (which can still issue X11 server grabs, at
      its own risks).
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Closes: https://bugzilla.redhat.com/1914021
  8. 12 Sep, 2022 1 commit
  9. 11 Sep, 2022 1 commit
  10. 09 Sep, 2022 1 commit
    • Peter Harris's avatar
      os: Restore buffer when writing to network · 2ab70ded
      Peter Harris authored and Alan Coopersmith's avatar Alan Coopersmith committed
      The commit 9bf46610
       "os: Immediately
      queue initial WriteToClient" effectively disables buffering (of all
      writes, not just the "initial" write), since the OS's network buffers
      will usually be large enough to hold whatever replies we have sent.
      This does improve performance when drawing over a Unix socket (I measure
      approximtely 10%, not the ~5x mentioned in that commit message, probably
      due to the large changes in this area since that commit), but it
      decreases performance when drawing over a network due to the additional
      TCP packets. This decrease is small (~10%) in most cases, but if the two
      machines have mismatched Nagle / tcp_delay settings it can cause
      XGetWindowAttributes to take 200ms (because it's composed of two
      requests, the 2nd of which might wait for the ack which is delayed).
      Avoid network slowdowns by making the immediate flush conditional on
      Signed-off-by: Peter Harris's avatarPeter Harris <pharris@opentext.com>
  11. 08 Sep, 2022 1 commit
  12. 07 Sep, 2022 2 commits
    • coypoop's avatar
      Simplify auto device configuration for choosing wsfb, fbdev · 399cf127
      coypoop authored and Alan Coopersmith's avatar Alan Coopersmith committed
      I wanted to simplify the logic, and thought this is a good opportunity
      to eliminate local diffs.
      I don't want to list OSes without wsfb, because I understand that is a
      netbsd/openbsd driver, and always have it as a fallback for us.
      Additionally, I understand "fbdev" is linux-specific, so have the logic
      match this intent.
    • Michel Dänzer's avatar
      ci: Check that all expected piglit results are there · 421e066e
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      Without these, the build jobs would spuriously pass if some of the
      expected piglit tests didn't run at all.
      * Use local variables instead of starting their names with underscores
        (Peter Hutterer)
  13. 02 Sep, 2022 7 commits
  14. 31 Aug, 2022 1 commit
  15. 29 Aug, 2022 5 commits
  16. 19 Aug, 2022 1 commit
  17. 11 Aug, 2022 1 commit
    • Peter Hutterer's avatar
      xwayland: add support for the XWAYLAND extension · 2700bc60
      Peter Hutterer authored
      This extension exists to serve one purpose: reliably identifying
      Xwayland. Previous attempts at doing so included querying root window
      properties, output names or input device names. All these attempts are
      somewhat unreliable. Instead, let's use an extension - where that
      extension is present we have an Xwayland server.
      Clients should never need to do anything but check whether the extension
      exists through XQueryExtension or search through XListExtensions.
      This extension provides a single QueryVersion request only, and
      that is only to provide future compatibility if we ever need anything
      other than "this extension exists" functionality.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  18. 09 Aug, 2022 1 commit
  19. 02 Aug, 2022 1 commit
  20. 27 Jul, 2022 1 commit
    • Olivier Fourdan's avatar
      dix: Fix overzealous caching of ResourceClientBits() · 2efa6d65
      Olivier Fourdan authored
      Commit c7311654 cached the value of ResourceClientBits(), but that value
      depends on the `MaxClients` value set either from the command line or
      from the configuration file.
      For the latter, a call to ResourceClientBits() is issued before the
      configuration file is read, meaning that the cached value is from the
      default, not from the maximum number of clients set in the configuration
      That obviously causes all sort of issues, including memory corruption
      and crashes of the Xserver when reaching the default limit value.
      To avoid that issue, also keep the LimitClient value, and recompute the
      ilog2() value if that changes, as on startup when the value is set from
      the the xorg.conf ServerFlags section.
      v2: Drop the `cache == 0` test
          Rename cache vars
      Fixes: c7311654 - dix: cache ResourceClientBits() value
      Closes: xorg/xserver#1310
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
  21. 26 Jul, 2022 1 commit
    • Olivier Fourdan's avatar
      xwayland: Fix "-force-xrandr-emulation" · 24d7d93f
      Olivier Fourdan authored
      Commit 7cdcdfea
       introduced a new command line option
      "-force-xrandr-emulation", however it is missing from the
      As a result, trying to use that command option would result in a error:
      (EE) Unrecognized option: -force-xrandr-emulation
      Make sure "-force-xrandr-emulation" is accounted for in Xwayland's
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Fixes: 7cdcdfea - xwayland: Add -force-xrandr-emulation switch
  22. 13 Jul, 2022 2 commits