1. 09 Apr, 2021 9 commits
  2. 08 Apr, 2021 4 commits
  3. 07 Apr, 2021 2 commits
  4. 06 Apr, 2021 1 commit
  5. 05 Apr, 2021 1 commit
    • Aaron Plattner's avatar
      modesetting: Defer crtc gamma size upgrade to drmmode_setup_colormap · b75d0cca
      Aaron Plattner authored
      Rather than trying to create a gamma ramp array of the appropriate size in
      drmmode_crtc_init when the GAMMA_LUT property should be used, just flag the crtc
      as wanting to use the GAMMA_LUT property and then replace the gamma ramp later,
      right before calling xf86HandleColormaps. This avoids a problem during initial
      startup where xf86RandR12CreateObjects12 hard-codes a gamma ramp size of 256,
      causing xf86RandR12CrtcSetGamma to read past the end of the DIX layer's RandR
      gamma ramp array:
      
        PreInit
          drmmode_pre_init
            drmmode_crtc_init
              crtc->gamma_size = 1024
      
        ScreenInit
          xf86CrtcScreenInit
            xf86RandR12Init
              xf86RandR12Init12
                xf86RandR12CreateObjects12
                  RRCrtcCreate
                    randr_crtc->gammaSize = 0
                xf86RandR12InitGamma(pScrn, 256)
                  RRCrtcGammaSetSize
                    randr_crtc->gammaSize = 256
                xf86RandR12InitGamma
                  xf86RandR12CrtcInitGamma
                    RRCrtcGammaSet
                      xf86RandR12CrtcSetGamma
                        // crtc->gamma_size is 1024 here, while randr_crtc->gammaRed
                        // is a 256-element array.
                        memcpy(crtc->gamma_red, randr_crtc->gammaRed, crtc->gamma_size * sizeof(crtc->gamma_red[0]));
          drmmode_setup_colormap
            xf86HandleColormaps
              xf86RandR12InitGamma
                RRCrtcGammaSetSize
                  randr_crtc->gammaSize = 1024
      
      Fixes: 245b9db0 - modesetting: Use GAMMA_LUT when available
      Closes: #1126
      
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Robert Morell's avatarRobert Morell <rmorell@nvidia.com>
      b75d0cca
  6. 04 Apr, 2021 1 commit
  7. 30 Mar, 2021 1 commit
  8. 26 Mar, 2021 5 commits
  9. 25 Mar, 2021 1 commit
  10. 24 Mar, 2021 1 commit
  11. 15 Mar, 2021 1 commit
  12. 11 Mar, 2021 1 commit
    • Jan Beich's avatar
      meson: hide C API if Xorg is disabled (like autotools) · 376eaadd
      Jan Beich authored and Peter Hutterer's avatar Peter Hutterer committed
      
      
      When building only Xwayland using Meson some files are always installed.
      This causes package conflict if Xwayland is built separately from Xorg.
      
        include/xorg/compositeext.h
        include/xorg/damage.h
        include/xorg/damagestr.h
        include/xorg/dbestruct.h
        include/xorg/dri3.h
        include/xorg/fb.h
        include/xorg/fboverlay.h
        include/xorg/fbpict.h
        include/xorg/fbrop.h
        include/xorg/geext.h
        include/xorg/geint.h
        include/xorg/glyphstr.h
        include/xorg/mi.h
        include/xorg/micmap.h
        include/xorg/micoord.h
        include/xorg/migc.h
        include/xorg/miline.h
        include/xorg/mioverlay.h
        include/xorg/mipict.h
        include/xorg/mipointer.h
        include/xorg/mipointrst.h
        include/xorg/mistruct.h
        include/xorg/misync.h
        include/xorg/misyncfd.h
        include/xorg/misyncshm.h
        include/xorg/misyncstr.h
        include/xorg/mizerarc.h
        include/xorg/panoramiX.h
        include/xorg/panoramiXsrv.h
        include/xorg/picture.h
        include/xorg/picturestr.h
        include/xorg/present.h
        include/xorg/presentext.h
        include/xorg/randrstr.h
        include/xorg/rrtransform.h
        include/xorg/shadow.h
        include/xorg/shmint.h
        include/xorg/syncsdk.h
        include/xorg/vndserver.h
        include/xorg/wfbrename.h
        include/xorg/xace.h
        include/xorg/xacestr.h
        include/xorg/xorg-server.h
        include/xorg/xvdix.h
        include/xorg/xvmcext.h
        share/aclocal/xorg-server.m4
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      376eaadd
  13. 09 Mar, 2021 1 commit
  14. 08 Mar, 2021 1 commit
  15. 06 Mar, 2021 2 commits
  16. 05 Mar, 2021 2 commits
  17. 03 Mar, 2021 2 commits
    • Jacob Cherry's avatar
      xfree86: Fix autoconfig secondary GPU devices · a5367fac
      Jacob Cherry authored and Aaron Plattner's avatar Aaron Plattner committed
      The code path added by commit 69e4b8e6
      
       (xfree86: attempt to autoconfig
      gpu slave devices (v3)) assumes that it will only be run if the primary
      device on the screen is the first device in xf86configptr->conf_device_lst.
      While this is true most of the time, there are two specific cases where
      this assumption fails.
      
      First, if the first device in conf_device_lst is assigned to a different
      seat than the running X server, it will be skipped by the previous
      FIND_SUITABLE macro usage. Second, if the primary device was explicitly
      assigned to the screen but auto_gpu_device is still set and no secondary
      devices were explicitly listed, that device may not be the first device
      in conf_device_lst.
      
      When the first device in conf_device_lst is not the primary device
      assigned to the screen, two problems emerge. First, the first device in
      conf_device_lst will never be assigned to the screen as a secondary
      device. Second, the primary device is additionally assigned to the
      screen as a secondary device. The combination of these problems causes
      certain otherwise valid configurations to be invalid. For example, if a
      primary device is assigned to a screen and a secondary device is listed
      in the config but not explicitly assigned to the screen, then one order
      of the device sections results in a usable PRIME or Reverse PRIME setup
      and the other order does not.
      
      This commit removes the assumption that the primary device is the first
      device in conf_device_lst by starting the loop from the start of
      conf_device_lst and skipping the primary device when it is encountered.
      Signed-off-by: Jacob Cherry's avatarJacob Cherry <jcherry@nvidia.com>
      a5367fac
    • Olivier Fourdan's avatar
      xwayland: Delay cursor visibility update · 97ed0048
      Olivier Fourdan authored
      
      
      Xwayland won't emulate XWarpPointer requests if the cursor is visible,
      this is to avoid having the cursor jumping on screen and preventing
      random X11 clients from controlling the pointer in Wayland, while
      allowing games which use that mechanism with a hidden cursor to work in
      Xwayland.
      
      There are, however, games which tend to do it in the wrong order, i.e.
      show the cursor before moving the pointer, and because Xwayland will not
      allow an X11 client to move the pointer while the cursor is visible, the
      requests will fail.
      
      Add a workaround for such X11 clients, when the cursor is being shown,
      keep it invisible until the cursor is actually moved. This way, X11
      clients which show their cursor just before moving it would still have a
      chance to succeed.
      
      v2: Add a timeout to show the cursor for well behaved clients.
      v3: Some cleanup (Michel)
      v4: Do not cancel cursor delay when updating the cursor to avoid
          delaying cursor visibility indefinitely if the client keeps
          settings different cursors (Michel)
      Signed-off-by: Olivier Fourdan's avatarOlivier Fourdan <ofourdan@redhat.com>
      Tested-by: Jaap Buurman jaapbuurman@gmail.com
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Closes: xorg/xserver#734
      97ed0048
  18. 22 Feb, 2021 3 commits
  19. 21 Feb, 2021 1 commit