1. 13 Jan, 2022 1 commit
  2. 24 Dec, 2021 1 commit
  3. 20 Dec, 2021 2 commits
  4. 17 Dec, 2021 1 commit
  5. 16 Dec, 2021 1 commit
  6. 14 Dec, 2021 1 commit
    • Sam James's avatar
      hw/xfree86: fix sbus build for SPARC · 6c1a1fcc
      Sam James authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      Initially reported downstream in Gentoo. Manifests with errors like:
      ```
      gnu/bin/ld: hw/xfree86/common/libxorg_common.a(xf86fbBus.c.o): in function `xf86ClaimFbSlot':
      xf86fbBus.c:(.text+0x20): undefined reference to `sbusSlotClaimed'
      /usr/lib/gcc/sparc-unknown-linux-gnu/11.2.0/../../../../sparc-unknown-linux-gnu/bin/ld: xf86fbBus.c:(.text+0x2c): undefined reference to `sbusSlotClaimed'
      ```
      
      While we use the headers in meson.build, we don't reference xf86sbusBus.c
      which defines the missing symbols like sbusSlotClaimed.
      
      Bug: https://bugs.gentoo.org/828513
      
      
      Signed-off-by: Sam James's avatarSam James <sam@gentoo.org>
      6c1a1fcc
  7. 10 Dec, 2021 1 commit
  8. 07 Dec, 2021 2 commits
  9. 06 Dec, 2021 1 commit
  10. 05 Dec, 2021 1 commit
  11. 04 Dec, 2021 2 commits
  12. 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
      properly.
      
      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>
      6dd9709b
    • 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>
      c5d1fed9
  13. 01 Dec, 2021 2 commits
  14. 22 Nov, 2021 2 commits
  15. 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>
      35af1299
  16. 10 Nov, 2021 1 commit
  17. 06 Nov, 2021 1 commit
  18. 04 Nov, 2021 4 commits
  19. 03 Nov, 2021 1 commit
  20. 27 Oct, 2021 1 commit
  21. 25 Oct, 2021 3 commits
  22. 22 Oct, 2021 1 commit
  23. 20 Oct, 2021 1 commit
  24. 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
      successful.
      
      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>
      246ae00b
  25. 08 Oct, 2021 3 commits
    • 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
      b9218fad
    • 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>
      4b75e657
    • 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
      "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: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
      017ce263
  26. 07 Oct, 2021 1 commit
  27. 06 Oct, 2021 1 commit