1. 17 Nov, 2020 7 commits
  2. 12 Nov, 2020 1 commit
  3. 10 Nov, 2020 3 commits
  4. 09 Nov, 2020 4 commits
  5. 04 Nov, 2020 1 commit
    • Alex Goins's avatar
      glamor: Update pixmap's devKind when making it exportable · 7a7e55c5
      Alex Goins authored and Aaron Plattner's avatar Aaron Plattner committed
      When making a pixmap exportable, glamor will currently create a temporary
      exported pixmap backed by a GBM bo, with the devKind updated to the stride of
      the bo. However, when the backing of the exported pixmap is swapped into the
      original, the devKind of the original is not updated.
      Some GBM bos may get implicitly padded, in which case the devKind of the pixmap
      will not match the stride of the backing bo. For example, an 800x600 pixmap will
      have a devKind of 3200, but the bo's stride will be 3328. This can cause
      corruption with PRIME, when the sink uses the wrong stride to display the shared
      This commit changes glamor_make_pixmap_exportable() to update the devKind of the
      original pixmap after it swaps exported pixmap's backing into it, keeping
      everything consistent.
      Fixes issue #1018.
      Signed-off-by: Alex Goins's avatarAlex Goins <agoins@nvidia.com>
      Signed-off-by: Aaron Plattner's avatarAaron Plattner <aplattner@nvidia.com>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
  6. 30 Oct, 2020 1 commit
  7. 29 Oct, 2020 4 commits
  8. 30 Sep, 2020 1 commit
  9. 28 Sep, 2020 2 commits
  10. 26 Sep, 2020 1 commit
  11. 25 Sep, 2020 2 commits
    • Kishore409's avatar
      modesetting: keep going if a modeset fails on EnterVT · efb3abdd
      Kishore409 authored and Martin Roukala's avatar Martin Roukala committed
      There was a time when setting a mode on a CRTC would not depend on the
      associated connector's state. If a mode had been set successfully once,
      it would mean it would work later on.
      This changed with the introduction of new connectors type that now
      require a link training sequence (DP, HDMI 2.0), and that means that
      some events may have happened while the X server was not master that
      would then prevent the mode from successfully be restored to its
      previous state.
      This patch relaxes the requirement that all modes should be restored on
      EnterVT, or the entire X-Server would go down by allowing modesets to
      fail (with some warnings). If a modeset fails, the CRTC will be
      disabled, and a RandR event will be sent for the desktop environment to
      fix the situation as well as possible.
      Additional patches might be needed to make sure that the user would
      never be left with all screens black in some scenarios.
      v2 (Martin Peres):
       - whitespace fixes
       - remove the uevent handling (it is done in a previous patch)
       - improve the commit message
       - reduce the size of the patch by not changing lines needlessly
       - return FALSE if one modeset fails in ignore mode
       - add comments/todos to explain why we do things
       - disable the CRTCs that failed the modeset
      Signed-off-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Closes: #1010
    • Martin Roukala's avatar
      modesetting: check the kms state on EnterVT · 293cf660
      Martin Roukala authored
      Normally, we would receive a uevent coming from Linux's DRM subsystem,
      which would trigger the check for disappearing/appearing resources.
      However, this event is not received when X is not master (another VT
      is selected), and so the userspace / desktop environment would not be
      notified about the changes that happened while X wasn't master.
      To fix the issue, this patch forces a refresh on EnterVT by splitting
      the kms-checking code from the uevent handling into its own (exported)
      function called drmmode_update_kms_state. This function is then called
      from both the uevent-handling function, and on EnterVT right before
      restoring the modes.
      Signed-off-by: Martin Roukala's avatarMartin Peres <martin.peres@linux.intel.com>
      Reviewed-by: Daniel Vetter's avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
      Tested-by: Kishore409's avatarKishore Kadiyala <kishore.kadiyala@intel.com>
  12. 24 Sep, 2020 2 commits
  13. 22 Sep, 2020 3 commits
  14. 21 Sep, 2020 1 commit
  15. 15 Sep, 2020 3 commits
  16. 08 Sep, 2020 3 commits
  17. 07 Sep, 2020 1 commit