1. 20 Sep, 2022 1 commit
  2. 07 Sep, 2022 1 commit
    • 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.
  3. 26 Jun, 2022 3 commits
  4. 05 Apr, 2022 1 commit
  5. 02 Apr, 2022 2 commits
  6. 31 Mar, 2022 3 commits
  7. 16 Feb, 2022 1 commit
  8. 29 Jan, 2022 1 commit
  9. 20 Dec, 2021 2 commits
  10. 16 Dec, 2021 1 commit
  11. 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>
  12. 10 Dec, 2021 1 commit
  13. 07 Dec, 2021 1 commit
  14. 06 Dec, 2021 1 commit
  15. 05 Dec, 2021 1 commit
  16. 22 Nov, 2021 2 commits
  17. 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>
  18. 10 Nov, 2021 1 commit
  19. 06 Nov, 2021 1 commit
  20. 04 Nov, 2021 1 commit
  21. 03 Nov, 2021 1 commit
  22. 27 Oct, 2021 1 commit
  23. 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
    • 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>
  24. 07 Oct, 2021 1 commit
  25. 27 Sep, 2021 3 commits
    • Mario Kleiner's avatar
      Revert "modesetting: Only use GAMMA_LUT if its size is 1024" · 545fa90c
      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: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
    • Mario Kleiner's avatar
      xfree86: Let xf86RandR12CrtcComputeGamma() deal with non-power-of-2 sizes. · 7326e131
      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
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
    • Mario Kleiner's avatar
      xfree86: Avoid crash in xf86RandR12CrtcSetGamma() memcpy path. · 966f5674
      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
      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
      This is an alternative fix for the one attempted in commit
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>
  26. 15 Sep, 2021 1 commit
    • Patrik Jakobsson's avatar
      modesetting: Fix dirty updates for sw rotation · db9e9d45
      Patrik Jakobsson authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      Rotation is broken for all drm drivers not providing hardware rotation
      support. Drivers that give direct access to vram and not needing dirty
      updates still work but only by accident. The problem is caused by
      modesetting not sending the correct fb_id to drmModeDirtyFB() and
      passing the damage rects in the rotated state and not as the crtc
      expects them. This patch takes care of both problems.
      Signed-off-by: Patrik Jakobsson's avatarPatrik Jakobsson <pjakobsson@suse.de>
  27. 10 Sep, 2021 2 commits
    • Aaron Plattner's avatar
      xfree86: NUL-terminate strings in hwEnableIO · 72c5d153
      Aaron Plattner authored
      The Linux version of xf86EnableIO calls a helper function called hwEnableIO().
      Except on Alpha, this function reads /proc/ioports looking for the 'keyboard'
      and 'timer' ports, extracts the port ranges, and enables access to them. It does
      this by reading 4 bytes from the string for the start port number and 4 bytes
      for the last port number, passing those to atoi(). However, it doesn't add a
      fifth byte for a NUL terminator, so some implementations of atoi() read past the
      end of this string, triggering an AddressSanitizer error:
        ==1383==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff71fd5b74 at pc 0x7fe1be0de3e0 bp 0x7fff71fd5ae0 sp 0x7fff71fd5288
        READ of size 5 at 0x7fff71fd5b74 thread T0
            #0 0x7fe1be0de3df in __interceptor_atoi /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520
            #1 0x564971adcc45 in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:138
            #2 0x564971adce87 in xf86EnableIO ../hw/xfree86/os-support/linux/lnx_video.c:174
            #3 0x5649719f6a30 in InitOutput ../hw/xfree86/common/xf86Init.c:439
            #4 0x564971585924 in dix_main ../dix/main.c:190
            #5 0x564971b6246e in main ../dix/stubmain.c:34
            #6 0x7fe1bdab6b24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
            #7 0x564971490e9d in _start (/home/aaron/git/x/xserver/build.asan/hw/xfree86/Xorg+0xb2e9d)
        Address 0x7fff71fd5b74 is located in stack of thread T0 at offset 100 in frame
            #0 0x564971adc96a in hwEnableIO ../hw/xfree86/os-support/linux/lnx_video.c:118
          This frame has 3 object(s):
            [32, 40) 'n' (line 120)
            [64, 72) 'buf' (line 122)
            [96, 100) 'target' (line 122) <== Memory access at offset 100 overflows this variable
        HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
              (longjmp and C++ exceptions *are* supported)
        SUMMARY: AddressSanitizer: stack-buffer-overflow /build/gcc/src/gcc/libsanitizer/asan/asan_interceptors.cpp:520 in __interceptor_atoi
        Shadow bytes around the buggy address:
          0x10006e3f2b10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          0x10006e3f2b20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          0x10006e3f2b30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          0x10006e3f2b40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          0x10006e3f2b50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        =>0x10006e3f2b60: 00 00 f1 f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2[04]f3
          0x10006e3f2b70: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          0x10006e3f2b80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
          0x10006e3f2b90: f1 f1 f8 f2 00 f2 f2 f2 f8 f3 f3 f3 00 00 00 00
          0x10006e3f2ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
          0x10006e3f2bb0: f1 f1 00 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
        Shadow byte legend (one shadow byte represents 8 application bytes):
          Addressable:           00
          Partially addressable: 01 02 03 04 05 06 07
          Heap left redzone:       fa
          Freed heap region:       fd
          Stack left redzone:      f1
          Stack mid redzone:       f2
          Stack right redzone:     f3
          Stack after return:      f5
          Stack use after scope:   f8
          Global redzone:          f9
          Global init order:       f6
          Poisoned by user:        f7
          Container overflow:      fc
          Array cookie:            ac
          Intra object redzone:    bb
          ASan internal:           fe
          Left alloca redzone:     ca
          Right alloca redzone:    cb
          Shadow gap:              cc
      Fix this by NUL-terminating the string.
      Fixes: #1193 (comment 1053306)
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
    • Aaron Plattner's avatar
      modesetting: Only use GAMMA_LUT if its size is 1024 · 617f591f
      Aaron Plattner authored
      GAMMA_LUT sizes other than 1024 cause a crash during startup if the memcpy()
      calls in xf86RandR12CrtcSetGamma() read past the end of the legacy X11 /
      XVidMode gamma ramp.
      This is a problem on Intel ICL / GEN11 platforms because they report a GAMMA_LUT
      size of 262145. Since it's not clear that the modesetting driver will generate a
      proper gamma ramp at that size even if xf86RandR12CrtcSetGamma() is fixed, just
      disable use of GAMMA_LUT for sizes other than 1024 for now. This will cause the
      modesetting driver to disable the CTM property and fall back to the legacy gamma
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Fixes: #1193
      Tested-by: Mark Herbert
  28. 09 Sep, 2021 1 commit
    • Mario Kleiner's avatar
      modesetting: Add option for non-vsynced flips for "secondary" outputs. · 68f01c0f
      Mario Kleiner authored and Povilas Kanapickas's avatar Povilas Kanapickas committed
      Whenever an unredirected fullscreen window uses pageflipping for a
      DRI3/Present PresentPixmap() operation and the X-Screen has more than
      one active output, multiple crtc's need to execute pageflips. Only
      after the last flip has completed can the PresentPixmap operation
      as a whole complete.
      If a sync_flip is requested for the present, then the current
      implementation will synchronize each pageflip to the vblank of
      its associated crtc. This provides tear-free image presentation
      across all outputs, but introduces a different artifact, if not
      all outputs run at the same refresh rate with perfect synchrony:
      The slowest output throttles the presentation rate, and present
      completion is delayed to flip completion of the "latest" output
      to complete. This means degraded performance, e.g., a dual-display
      setup with a 144 Hz monitor and a 60 Hz monitor will always be
      throttled to at most 60 fps. It also means non-constant present
      rate if refresh cycles drift against each other, creating complex
      "beat patterns", tremors, stutters and periodic slowdowns - quite
      Such a scenario will be especially annoying if one uses multiple
      outputs in "mirror mode" aka "clone mode". One output will usually
      be the "production output" with the highest quality and fastest
      display attached, whereas a secondary mirror output just has a
      cheaper display for monitoring attached. Users care about perfect
      and perfectly timed tear-free presentation on the "production output",
      but cares less about quality on the secondary "mirror output". They
      are willing to trade quality on secondary outputs away in exchange
      for better presentation timing on the "production output".
      One example use case for such production + monitoring displays are
      neuroscience / medical science applications where one high quality
      display device is used to present visual animations to test subjects
      or patients in a fMRI scanner room (production display), whereas
      an operator monitors the same visual animations from a control room
      on a lower quality display. Presentation timing needs to be perfect,
      and animations high-speed and tear-free for the production display,
      whereas quality and timing don't matter for the monitoring display.
      This commit gives users the option to choose such a trade-off as
      It adds a new boolean option "AsyncFlipSecondaries" to the device section
      of xorg.conf. If this option is specified as true, then DRI3 pageflip
      behaviour changes as follows:
      1. The "reference crtc" for a windows PresentPixmap operation does a
         vblank synced flip, or a DRM_MODE_PAGE_FLIP_ASYNC non-synchronized
         flip, as requested by the caller, just as in the past. Typically
         flips will be requested to be vblank synchronized for tear-free
         presentation. The "reference crtc" is the one chosen by the caller
         to drive presentation timing (as specified by PresentPixmap()'s
         "target_msc", "divisor", "remainder" parameters and implemented by
         vblank events) and to deliver Present completion timestamps (msc
         and ust) extracted from its pageflip completion event.
      2. All other crtc's, which also page-flip in a multi-display configuration,
         will try to flip with DRM_MODE_PAGE_FLIP_ASYNC, ie. immediately and
         not synchronized to vblank. This allows the PresentPixmap operation
         to complete with little delay compared to a single-display present,
         especially if the different crtc's run at different video refresh
         rates or their refresh cycles are not perfectly synchronized, but
         drift against each other. The downside is potential tearing artifacts
         on all outputs apart from the one of the "reference crtc".
      Successfully tested on a AMD gpu with single-display, dual-display and
      triple-display setups, and with single-X-Screen as well as dual-X-Screen
      "ZaphodHeads" configurations.
      Please consider merging this commit for the upcoming server 1.21 branch.
      Signed-off-by: Mario Kleiner's avatarMario Kleiner <mario.kleiner.de@gmail.com>