Skip to content
Snippets Groups Projects
  1. Jan 02, 2022
  2. Jan 01, 2022
    • Adam Jackson's avatar
      glx/dri: Filter out fbconfigs that don't have a supported pixmap format · 001feb66
      Adam Jackson authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      For depth 30 in particular it's not uncommon for the DDX to not have
      a configured pixmap format. Since the client expects to back both
      GLXPixmaps and GLXPbuffers with X Pixmaps, trying to use an x2rgb10
      fbconfig would fail along various paths to CreatePixmap. Filter these
      fbconfigs out so the client can't ask for something that we know won't
      work.
      
      (cherry picked from commit f6c070a1)
      001feb66
  3. Dec 20, 2021
  4. Dec 19, 2021
  5. Dec 15, 2021
  6. Dec 10, 2021
  7. Dec 04, 2021
    • Povilas Kanapickas's avatar
      meson: Correctly set DDXOSVERRORF and DDXBEFORERESET on xwin · 7caf29ca
      Povilas Kanapickas authored
      
      This worked with autotools, but not meson build system.
      
      Signed-off-by: default avatarPovilas Kanapickas <povilas@radix.lt>
      (cherry picked from commit 04c93b98)
      7caf29ca
    • Jonathan Gray's avatar
      glamor: fix free of uninitialised pointers · 101791f8
      Jonathan Gray authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      Attempting to run fvwm on a x61/965gm with xserver 1.21.1 with the
      modesetting driver on OpenBSD/amd64 would cause the xserver to
      reliably crash.
      
      I tracked this down to the free() calls introduced in
      2906ee5e
      (d1ca47e1 in branch).
      
      clang also warns about this:
      glamor_program.c:296:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:290:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:288:9: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:277:13: warning: variable 'vs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:296:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:290:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:288:9: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      glamor_program.c:277:13: warning: variable 'fs_prog_string' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
      
      Signed-off-by: default avatarJonathan Gray <jsg@jsg.id.au>
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Fixes: 2906ee5e ("glamor: Fix leak in glamor_build_program()")
      (cherry picked from commit 5ac63197)
      101791f8
    • Peter Hutterer's avatar
      xkb: fix XkbSetMap check for the keytypes count · 2c6989f8
      Peter Hutterer authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      The previous if/else condition resulted in us always setting the key
      type count to the current number of key types. Split this up correctly.
      
      Regression introduced in de940e06
      
      Fixes #1249
      
      Signed-off-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      (cherry picked from commit be16bd85)
      2c6989f8
  8. Dec 03, 2021
  9. Nov 23, 2021
  10. Nov 06, 2021
  11. Oct 27, 2021
  12. Oct 21, 2021
    • Mario Kleiner's avatar
      Fix RandR leasing for more than 1 simultaneously active lease. · d4944ced
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      Due to a switched order of parameters in the xorg_list_add()
      call inside ProcRRCreateLease(), adding a new lease for RandR
      output leasing does not actually add the new RRLeasePtr lease
      record to the list of existing leases for a X-Screen, but instead
      replaces the existing list with a new list that has the new lease
      as the only element, and probably leaks a bit of memory.
      
      Therefore the server "forgets" all active leases for a screen,
      except for the last added lease. If multiple leases are created
      in a session, then destruction of all leases but the last one
      will fail in many cases, e.g., during server shutdown in
      RRCloseScreen(), or resource destruction, e.g., in
      RRCrtcDestroyResource().
      
      Most importantly, it fails if a client simply close(fd)'es the
      DRM master descriptor to release a lease, quits, gets killed or
      crashes. In this case the kernel will destroy the lease and shut
      down the display output, then send a lease event via udev to the
      ddx, which e.g., in the modesetting-ddx will trigger a call to
      drmmode_validate_leases().
      
      That function is supposed to detect the released lease and tell
      the server to terminate the lease on the server side as well,
      via xf86CrtcLeaseTerminated(), but this doesn't happen for all
      the leases the server has forgotten. The end result is a dead
      video output, as the server won't reinitialize the crtc's
      corresponding to the terminated but forgotten lease.
      
      This bug was observed when using the amdvlk AMD OSS Vulkan
      driver and trying to lease multiple VKDisplay's, and also
      under Mesa radv, as both Mesa Vulkan/WSI/Display and amdvlk
      terminate leases by simply close()ing the lease fd, not by
      sending explicit RandR protocol requests to free leases.
      
      Leasing worked, but ending a session with multiple active
      leases ended in a lot of unpleasant darkness.
      
      Fixing the wrong argument order to xorg_list_add() fixes the
      problem. Tested on single-X-Screen and dual-X-Screen setups,
      with one, two or three active leases.
      
      Please merge this for the upcoming server 21.1 branch.
      Merging into server 1.20 would also make a lot of sense.
      
      Fixes: e4e34476
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Keith Packard <keithp@keithp.com>
      (cherry picked from commit f467f85c)
      d4944ced
  13. Oct 14, 2021
  14. Oct 08, 2021
    • Alexander Richardson's avatar
      dix/privates.c: Avoid undefined behaviour after realloc() · 3fb94f3c
      Alexander Richardson authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      Adding the offset between the realloc result and the old allocation to
      update pointers into the new allocation is undefined behaviour: the
      old pointers are no longer valid after realloc() according to the C
      standard. While this works on almost all architectures and compilers,
      it causes  problems on architectures that track pointer bounds (e.g.
      CHERI or Arm's Morello): the DevPrivateKey pointers will still have the
      bounds of the previous allocation and therefore any dereference will
      result in a run-time trap.
      
      I found this due to a crash (dereferencing an invalid capability) while
      trying to run `XVnc` on a CHERI-RISC-V system. With this commit I can
      successfully connect to the XVnc instance running inside a QEMU with a
      VNC viewer on my host.
      
      This also changes the check whether the allocation was moved to use
      uintptr_t instead of a pointer since according to the C standard:
      "The value of a pointer becomes indeterminate when the object it
      points to (or just past) reaches the end of its lifetime." Casting to an
      integer type avoids this undefined behaviour.
      
      Signed-off-by: default avatarAlex Richardson <Alexander.Richardson@cl.cam.ac.uk>
      (cherry picked from commit f9f705bf)
      3fb94f3c
    • nerdopolis's avatar
      xf86: Accept devices with the 'simpledrm' driver. · b89fdd52
      nerdopolis authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      SimpleDRM 'devices' are a fallback device, and do not have a busid
      so they are getting skipped. This will allow simpledrm to work
      with the modesetting driver
      
      (cherry picked from commit b9218fad)
      b89fdd52
    • Mario Kleiner's avatar
      modesetting: Consider RandR primary output for selectioh of sync crtc. · fbc690cc
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      The "sync crtc" is the crtc used to drive the display timing of a
      drawable under DRI2 and DRI3/Present. If a drawable intersects
      multiple video outputs, then normally the crtc is chosen which has
      the largest intersection area with the drawable.
      
      If multiple outputs / crtc's have exacty the same intersection
      area then the crtc chosen was simply the first one with maximum
      intersection. Iow. the choice was random, depending on plugging
      order of displays.
      
      This adds the ability to choose a preferred output in such a tie
      situation. The RandR output marked as "primary output" is chosen
      on such a tie.
      
      This new behaviour and its implementation is consistent with other
      video ddx drivers. See amdgpu-ddx, ati-ddx and nouveau-ddx for
      reference. This commit is a straightforward port from amdgpu-ddx.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 4b75e657)
      fbc690cc
    • Mario Kleiner's avatar
      modesetting: Handle mixed VRR and non-VRR display setups better. · 22f4ff10
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      In a setup with both VRR capable and non-VRR capable displays,
      it was so far inconsistent if the driver would allow use of
      VRR support or not, as "is_connector_vrr_capable" was set to
      whatever the capabilities of the last added drm output were.
      Iow. the plugging order of monitors determined the outcome.
      
      Fix this: Now if at least one display is VRR capable, the driver
      will treat an X-Screen as capable for VRR, plugging order no
      longer matters.
      
      Tested with a dual-display setup with one VRR monitor and one
      non-VRR monitor. This is also beneficial with the new Option
      "AsyncFlipSecondaries".
      
      When we are at it, also add some so far missing description of
      the "VariableRefresh" driver option, copied from amdgpu-ddx.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 017ce263)
      22f4ff10
    • Mario Kleiner's avatar
      modesetting: Enable GAMMA_LUT for lut's with up to 4096 slots. · 0d0986bf
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      A lut size of 4096 slots has been verified to work correctly,
      as tested with amdgpu-kms. Intel Tigerlake Gen12 hw has a very
      large GAMMA_LUT size of 262145 slots, but also issues with its
      current GAMMA_LUT implementation, as of Linux 5.14.
      
      Therefore we keep GAMMA_LUT off for large lut's. This currently
      excludes Intel Icelake, Tigerlake and later.
      
      This can be overriden via the "UseGammaLUT" boolean xorg.conf option
      to force use of GAMMA_LUT on or off.
      
      See following link for the Tigerlake situation:
      https://gitlab.freedesktop.org/drm/intel/-/issues/3916#note_1085315
      
      
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 66e5a5bb)
      0d0986bf
    • Ray Strode's avatar
      xkb: Drop check for XkbSetMapResizeTypes · bc1327e6
      Ray Strode authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      Commit 446ff2d3 added checks to
      prevalidate the size of incoming SetMap requests.
      
      That commit checks for the XkbSetMapResizeTypes flag to be set before
      allowing key types data to be processed.
      
      key types data can be changed or even just sent wholesale unchanged
      without the number of key types changing, however. The check for
      XkbSetMapResizeTypes rejects those legitimate requests. In particular,
      XkbChangeMap never sets XkbSetMapResizeTypes and so always fails now
      any time XkbKeyTypesMask is in the changed mask.
      
      This commit drops the check for XkbSetMapResizeTypes in flags when
      prevalidating the request length.
      
      (cherry picked from commit 8b7f4d32)
      bc1327e6
    • Mario Kleiner's avatar
      Revert "modesetting: Only use GAMMA_LUT if its size is 1024" · b8753668
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      This reverts commit 617f591f.
      
      The problem described in that commit exists, but the two
      preceeding commits with improvements to the servers RandR
      code should avoid the mentioned problems while allowing the
      use of GAMMA_LUT's instead of legacy gamma lut.
      
      Use of legacy gamma lut's is not a good fix, because it will reduce
      color output precision of gpu's with more than 1024 GAMMA_LUT
      slots, e.g., AMD, ARM MALI and KOMEDA with 4096 slot luts,
      and some Mediathek parts with 512 slot luts. On KOMEDA, legacy
      lut's are completely unsupported by the kms driver, so gamma
      correction gets disabled.
      
      The situation is especially bad on Intel Icelake and later:
      Use of legacy gamma tables will cause the kms driver to switch
      to hardware legacy lut's with 256 slots, 8 bit wide, without
      interpolation. This way color output precision is restricted to
      8 bpc and any deep color / HDR output (10 bpc, fp16, fixed point 16)
      becomes impossible. The latest Intel gen gpu's would have worse
      color precision than parts which are more than 10 years old.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 545fa90c)
      b8753668
    • Mario Kleiner's avatar
      xfree86: Let xf86RandR12CrtcComputeGamma() deal with non-power-of-2 sizes. · 473a4866
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      The assumption in the upsampling code was that the crtc->gamma_size
      size of the crtc's gamma table is a power of two. This is true for
      almost all current driver + gpu combos at least on Linux, with typical
      sizes of 256, 512, 1024 or 4096 slots.
      
      However, Intel Gen-11 Icelake and later are outliers, as their gamma
      table has 2^18 + 1 slots, very big and not a power of two!
      
      Try to make upsampling behave at least reasonable: Replicate the
      last gamma value to fill up remaining crtc->gamma_red/green/blue
      slots, which would normally stay uninitialized. This is important,
      because while the intel display driver does not actually use all
      2^18+1 values passed as part of a GAMMA_LUT, it does need the
      very last slot, which would not get initialized by the old code.
      
      This should hopefully create reasonable behaviour with Icelake+
      but is untested on the actual Intel hw due to lack of suitable
      hw.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 7326e131)
      473a4866
    • Mario Kleiner's avatar
      xfree86: Avoid crash in xf86RandR12CrtcSetGamma() memcpy path. · b33f487a
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      If randrp->palette_size is zero, the memcpy() path can read past the
      end of the randr_crtc's gammaRed/Green/Blue tables if the hw crtc's
      gamma_size is greater than the randr_crtc's gammaSize.
      
      Avoid this by clamping the to-be-copied size to the smaller of both
      sizes.
      
      Note that during regular server startup, the memcpy() path is only
      taken initially twice, but then a suitable palette is created for
      use during a session. Therefore during an actual running X-Session,
      the xf86RandR12CrtcComputeGamma() will be used, which makes sure that
      data is properly up- or down-sampled for mismatching source and
      target crtc gamma sizes.
      
      This should avoid reading past randr_crtc gamma memory for gpu's
      with big crtc->gamma_size, e.g., AMD/MALI/KOMEDA 4096 slots, or
      Intel Icelake and later with 262145 slots.
      
      Tested against modesetting-ddx and amdgpu-ddx under screen color
      depth 24 (8 bpc) and 30 (10 bpc) to make sure that clamping happens
      properly.
      
      This is an alternative fix for the one attempted in commit
      617f591f.
      
      Signed-off-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      (cherry picked from commit 966f5674)
      b33f487a
    • Olivier Fourdan's avatar
      glamor: Fix leak in glamor_build_program() · d1ca47e1
      Olivier Fourdan authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      
      Fix the possible leak of `vs_prog_string` and `fs_prog_string` in case
      of failure, as reported by covscan.
      
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarPeter Hutterer <peter.hutterer@who-t.net>
      Reviewed-by: default avatarMichel Dänzer <mdaenzer@redhat.com>
      (cherry picked from commit 2906ee5e)
      d1ca47e1
  15. Sep 21, 2021
Loading