1. 06 Dec, 2021 1 commit
  2. 05 Dec, 2021 1 commit
  3. 04 Dec, 2021 2 commits
  4. 03 Dec, 2021 3 commits
    • Povilas Kanapickas's avatar
      meson: Correctly set DDXOSVERRORF and DDXBEFORERESET on xwin · 04c93b98
      Povilas Kanapickas authored
      This worked with autotools, but not meson build system.
      Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
    • Jonathan Gray's avatar
      glamor: fix free of uninitialised pointers · 5ac63197
      Jonathan Gray authored
      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
      (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 whe...
    • Peter Hutterer's avatar
      xkb: fix XkbSetMap check for the keytypes count · be16bd85
      Peter Hutterer authored
      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: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
  5. 02 Dec, 2021 2 commits
    • Olivier Fourdan's avatar
      xwayland/eglstream: Prefer EGLstream if available · 6dd9709b
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Currently, when given the choice, Xwayland will pick the GBM backend
      over the EGLstream backend if both are available, unless the command
      line option “-eglstream” is specified.
      The NVIDIA proprietary driver had no support for GBM until driver series
      495, but starting with the driver series 495, both can be used.
      But there are other requirements with the rest of the stack, typically
      Mesa, egl-wayland, libglvnd as documented in the NVIDIA driver.
      So if the NVIDIA driver series 495 gets installed, Xwayland will pick
      the GBM backend even if EGLstream is available and may fail to render
      To avoid that issue, prefer EGLstream if EGLstream and all the Wayland
      interfaces are available, and fallback to GBM automatically unless
      “-eglstream” was specified.
      With this, the compositor, given the choice, can decide which actual
      backend Xwayland would use by advertising (or not) the Wayland
      "wl_eglstream_controller" interface.
      This change has no impact on compositors which do not have support for
      EGLstream in the first place.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Acked-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
    • Olivier Fourdan's avatar
      xwayland/glamor: Log backend selected for debug · c5d1fed9
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Add (verbose) statements to trace the actual backend used with glamor.
      That can be useful for debugging.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
  6. 01 Dec, 2021 2 commits
  7. 22 Nov, 2021 2 commits
  8. 16 Nov, 2021 1 commit
    • Povilas Kanapickas's avatar
      Revert "hw/xfree86: Propagate physical dimensions from DRM connector" · 35af1299
      Povilas Kanapickas authored
      Quite a lot of applications currently expect the screen DPI exposed by
      the X server to be 96 even when the real display DPI is different.
      Additionally, currently Xwayland completely ignores any hardware
      information and sets the DPI to 96. Accordingly the new behavior, even
      if it fixes a bug, should not be enabled automatically to all users.
      A better solution would be to make the default DPI stay as is and enable
      the correct behavior with a command line option (maybe -dpi auto, or
      similar). For now let's just revert the bug fix.
      This reverts commit 05b3c681
      Signed-off-by: Povilas Kanapickas's avatarPovilas Kanapickas <povilas@radix.lt>
  9. 10 Nov, 2021 1 commit
  10. 08 Nov, 2021 1 commit
  11. 06 Nov, 2021 3 commits
  12. 04 Nov, 2021 6 commits
  13. 03 Nov, 2021 1 commit
  14. 27 Oct, 2021 1 commit
  15. 25 Oct, 2021 3 commits
  16. 22 Oct, 2021 1 commit
  17. 21 Oct, 2021 1 commit
  18. 20 Oct, 2021 1 commit
  19. 19 Oct, 2021 1 commit
    • Mario Kleiner's avatar
      Fix RandR leasing for more than 1 simultaneously active lease. · f467f85c
      Mario Kleiner authored
      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
      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
      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: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: Keith Packard <keithp@keithp.com>
  20. 14 Oct, 2021 1 commit
  21. 12 Oct, 2021 1 commit
    • Olivier Fourdan's avatar
      xwayland: Notify of root size change with XRandR emulation · 246ae00b
      Olivier Fourdan authored and Olivier Fourdan's avatar Olivier Fourdan committed
      Some clients (typically Java, but maybe others) rely on ConfigureNotify
      or RRScreenChangeNotify events to tell that the XRandR request is
      When emulated XRandR is used in Xwayland, compute the emulated root size
      and send the expected ConfigureNotify and RRScreenChangeNotify events
      with the emulated size of the root window to the asking X11 client.
      Note that the root window size does not actually change, as XRandR
      emulation is achieved by scaling the client window using viewports in
      Wayland, so this event is sort of misleading.
      Also, because Xwayland is using viewports, emulating XRandR does not
      reconfigure the outputs location, meaning that the actual size of the
      root window which encompasses all the outputs together may not change
      in a multi-monitor setup. To work around this limitation, when using an
      emulated mode, we report the size of that emulated mode alone as the
      root size for the configure notify event.
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: default avatarHans de Goede <hdegoede@redhat.com>
  22. 08 Oct, 2021 4 commits
    • Alexander Richardson's avatar
      dix/privates.c: Avoid undefined behaviour after realloc() · f9f705bf
      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: Alexander Richardson's avatarAlex Richardson <Alexander.Richardson@cl.cam.ac.uk>
    • nerdopolis's avatar
      xf86: Accept devices with the 'simpledrm' driver. · b9218fad
      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
    • Mario Kleiner's avatar
      modesetting: Consider RandR primary output for selectioh of sync crtc. · 4b75e657
      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: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
    • Mario Kleiner's avatar
      modesetting: Handle mixed VRR and non-VRR display setups better. · 017ce263
      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
      When we are at it, also add some so far missing description of
      the "VariableRefresh" driver option, copied from amdgpu-ddx.
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>