1. 23 Sep, 2022 1 commit
    • Konstantin's avatar
      xwayland: fix glamor es black windows · 32c2d42c
      Konstantin authored
      
      
      On some drivers (mesa included), when we request GBM_FORMAT_XRGB8888,
      driver set surface storage format to GL_RGB8, which breaks gles2 rendering.
      If we force set gbm_format to GBM_FORMAT_ARGB8888, then rendering
      will happen and working. For correct colors, we need !924.
      
      Fixes #1288
      Fixes #1356
      
      Signed-off-by: Konstantin's avatarKonstantin <ria.freelander@gmail.com>
      32c2d42c
  2. 20 Sep, 2022 1 commit
  3. 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
         events...
      
      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
      a77d95af
  4. 12 Sep, 2022 1 commit
  5. 11 Sep, 2022 1 commit
  6. 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
      who->local.
      
      Signed-off-by: Peter Harris's avatarPeter Harris <pharris@opentext.com>
      2ab70ded
  7. 08 Sep, 2022 1 commit
  8. 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.
      399cf127
    • 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.
      
      v2:
      * Use local variables instead of starting their names with underscores
        (Peter Hutterer)
      421e066e
  9. 02 Sep, 2022 7 commits
  10. 31 Aug, 2022 1 commit
  11. 29 Aug, 2022 5 commits
  12. 19 Aug, 2022 1 commit
  13. 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.
      
      xorg/proto/xorgproto!54
      
      
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      2700bc60
  14. 09 Aug, 2022 1 commit
  15. 02 Aug, 2022 1 commit
  16. 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
      file.
      
      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>
      2efa6d65
  17. 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
      ddxProcessArgument().
      
      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
      ddxProcessArgument().
      
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Fixes: 7cdcdfea - xwayland: Add -force-xrandr-emulation switch
      24d7d93f
  18. 13 Jul, 2022 4 commits
  19. 12 Jul, 2022 2 commits
    • Peter Hutterer's avatar
      xkb: add request length validation for XkbSetGeometry · 6907b6ea
      Peter Hutterer authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      
      No validation of the various fields on that report were done, so a
      malicious client could send a short request that claims it had N
      sections, or rows, or keys, and the server would process the request for
      N sections, running out of bounds of the actual request data.
      
      Fix this by adding size checks to ensure our data is valid.
      
      ZDI-CAN 16062, CVE-2022-2319.
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      6907b6ea
    • Peter Hutterer's avatar
      xkb: swap XkbSetDeviceInfo and XkbSetDeviceInfoCheck · dd8caf39
      Peter Hutterer authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      XKB often uses a FooCheck and Foo function pair, the former is supposed
      to check all values in the request and error out on BadLength,
      BadValue, etc. The latter is then called once we're confident the values
      are good (they may still fail on an individual device, but that's a
      different topic).
      
      In the case of XkbSetDeviceInfo, those functions were incorrectly
      named, with XkbSetDeviceInfo ending up as the checker function and
      XkbSetDeviceInfoCheck as the setter function. As a result, the setter
      function was called before the checker function, accessing request
      data and modifying device state before we ensured that the data is
      valid.
      
      In particular, the setter function relied on values being already
      byte-swapped. This in turn could lead to potential OOB memory access.
      
      Fix this by correctly naming the functions and moving the length checks
      over to the checker function. These were added in 87c64fc5 to the
      wrong function, probably due to the incorrect naming.
      
      Fixes ZDI-CAN 16070, CVE-2022-2320.
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      
      Introduced in c06e27b2
      
      
      
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      dd8caf39
  20. 08 Jul, 2022 4 commits
  21. 04 Jul, 2022 1 commit
  22. 02 Jul, 2022 1 commit