1. 01 Dec, 2020 2 commits
    • Kishore409's avatar
      modesetting: keep going if a modeset fails on EnterVT · 54f9af1c
      Kishore409 authored
      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 Peres'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
      (cherry picked from commit efb3abdd)
      54f9af1c
    • Martin Peres's avatar
      modesetting: check the kms state on EnterVT · bd0f5372
      Martin Peres 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 Peres'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>
      (cherry picked from commit 293cf660)
      bd0f5372
  2. 09 Nov, 2020 3 commits
  3. 04 Nov, 2020 1 commit
    • Alex Goins's avatar
      glamor: Update pixmap's devKind when making it exportable · b3ae038c
      Alex Goins authored
      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
      pixmap.
      
      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>
      (cherry picked from commit 7a7e55c5)
      b3ae038c
  4. 02 Nov, 2020 1 commit
  5. 08 Oct, 2020 4 commits
  6. 01 Oct, 2020 2 commits
  7. 30 Sep, 2020 6 commits
  8. 25 Sep, 2020 1 commit
  9. 08 Sep, 2020 3 commits
  10. 25 Aug, 2020 5 commits
  11. 18 Aug, 2020 12 commits
    • Huacai Chen's avatar
      linux: Fix platform device probe for DT-based PCI · 249a12c5
      Huacai Chen authored
      On a DT-base PCI platform, the sysfs path of vga device is like this:
      /sys/devices/platform/bus@10000000/1a000000.pci/pci0000:00/0000:00:11.0/0000:04:00.0.
      
      Then the ID_PATH from udev is platform-1a000000.pci-pci-0000:04:00.0 and
      the BusID will be pci-0000:04:00.0, which causes Xorg start fail. This
      is because config_udev_odev_setup_attribs() use strstr() to search the
      first "pci-" in ID_PATH. To fix this, we implement a strrstr() function
      and use it to search the last "pci-" in ID_PATH, which can get a correct
      BusID.
      
      (backported from commit 9fbd3e43)
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      249a12c5
    • Adam Jackson's avatar
      linux: Fix platform device PCI detection for complex bus topologies · 5c96eb5f
      Adam Jackson authored
      Suppose you're in a Hyper-V guest and are trying to use PCI passthrough.
      The ID_PATH that udev will construct for that looks something like
      "acpi-VMBUS:00-pci-b8c8:00:00.0", and obviously looking for "pci-" in
      the first four characters of that is going to not work.
      
      Instead, strstr. I suppose it's possible you could have _multiple_ PCI
      buses in the path, in which case you'd want strrstr, if that were a
      thing.
      
      (backported from commit 9acff309)
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      5c96eb5f
    • Adam Jackson's avatar
      linux: Make platform device probe less fragile · 74b7427c
      Adam Jackson authored
      At the point where xf86BusProbe runs we haven't yet taken our own VT,
      which means we can't perform drm "master" operations on the device. This
      is tragic, because we need master to fish the bus id string out of the
      kernel, which we can only do after drmSetInterfaceVersion, which for
      some reason stores that string on the device not the file handle and
      thus needs master access.
      
      Fortunately we know the format of the busid string, and it happens to
      almost be the same as the ID_PATH variable from udev. Use that instead
      and stop calling drmSetInterfaceVersion.
      
      (backported from commit 0816e8fc)
      Reviewed-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      Signed-off-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      74b7427c
    • Matthieu Herrb's avatar
      fix for ZDI-11426 · 4979ac8f
      Matthieu Herrb authored
      Avoid leaking un-initalized memory to clients by zeroing the
      whole pixmap on initial allocation.
      
      This vulnerability was discovered by:
      Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
      Signed-off-by: Matthieu Herrb's avatarMatthieu Herrb <matthieu@herrb.eu>
      Reviewed-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      (cherry picked from commit a6b2cbe9)
      4979ac8f
    • Aaron Ma's avatar
      xfree86: add drm modes on non-GTF panels · 2720b871
      Aaron Ma authored
      EDID1.4 replaced GTF Bit with Continuous or Non-Continuous Frequency Display.
      
      Check the "Display Range Limits Descriptor" for GTF support.
      If panel doesn't support GTF, then add gtf modes.
      
      Otherwise X will only show the modes in "Detailed Timing Descriptor".
      
      V2: Coding style changes.
      V3: Coding style changes, remove unused variate.
      V4: remove unused variate.
      
      BugLink: drm/intel#313Signed-off-by: default avatarAaron Ma <aaron.ma@canonical.com>
      Reviewed-by: Adam Jackson's avatarAdam Jackson <ajax@redhat.com>
      (cherry picked from commit 6a79a737)
      2720b871
    • Roman Gilg's avatar
      present: Check valid region in window mode flips · 7da8e7ba
      Roman Gilg authored
      For Pixmap flips to have well defined outcomes the window must be contained by
      the valid region if such region was specified.
      
      The valid region is inserted as an argument to the check in window mode.
      Setting this argument is missing in screen mode as well but we ignore it for now
      and only add it to window mode.
      
      It seems there are none or only very few clients actually making use of valid
      regions at the moment. For simplicity we therefore just check if a valid region
      was set by the client and in this case do never flip, independently of the
      window being contained by the region or not.
      Signed-off-by: Roman Gilg's avatarRoman Gilg <subdiff@gmail.com>
      (cherry picked from commit 591916ea)
      7da8e7ba
    • Michel Dänzer's avatar
      xwayland: Handle NULL xwl_seat in xwl_seat_can_emulate_pointer_warp · 4a65b661
      Michel Dänzer authored
      This can happen e.g. with weston's headless backend.
      Reviewed-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      (cherry picked from commit e33453f9)
      4a65b661
    • Michel Dänzer's avatar
      xwayland: Propagate damage x1/y1 coordinates in xwl_present_flip · 10cabe0b
      Michel Dänzer authored
      This couldn't have worked correctly for non-0 x1/y1.
      
      Noticed by inspection.
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      (cherry picked from commits 9141196d)
      (cherry picked fixup from commit 85a6fd11)
      10cabe0b
    • Alan Coopersmith's avatar
      doc: Update URLs in Xserver-DTrace.xml · 3b51978b
      Alan Coopersmith authored
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      (cherry picked from commit 0006aecb)
      3b51978b
    • Olivier Fourdan's avatar
      xwayland: Use a fixed DPI value for core protocol · 6cbd6a09
      Olivier Fourdan authored
      The way Xwayland works (like all Wayland clients), it first queries the
      Wayland registry, set up all relevant protocols and then initializes its
      own structures.
      
      That means Xwayland will get the Wayland outputs from the Wayland
      compositor, compute the physical size of the combined outputs and set
      the corresponding Xwayland screen properties accordingly.
      
      Then it creates the X11 screen using fbScreenInit() but does so by using
      a default DPI value of 96. That value is used to set the physical size
      of the X11 screen, hence overriding the value computed from the actual
      physical size provided by the Wayland compositor.
      
      As a result, the DPI computed by tools such as xdpyinfo will always be
      96 regardless of the actual screen size and resolution.
      
      However, if the Wayland outputs get reconfigured, or new outputs added,
      or existing outputs removed, Xwayland will recompute and update the
      physical size of the screen, leading to an unexpected change of DPI.
      
      To avoid that discrepancy, use a fixed size DPI (defaults to 96, and can
      be set using the standard command lime option "-dpi") and compute a
      physical screen size to match that DPI setting.
      
      Note that only affects legacy core protocols, X11 clients can still get
      the actual physical output size as reported by the Wayland compositor
      using the RandR protocol, which also allows for the size to be 0 if the
      size is unknown or meaningless.
      Signed-off-by: default avatarOlivier Fourdan <ofourdan@redhat.com>
      Reviewed-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Closes: #731
      (cherry picked from commit b0413b6e)
      6cbd6a09
    • Simon Ser's avatar
      xwayland: only use linux-dmabuf if format/modifier was advertised · d4e8c462
      Simon Ser authored
      Previously, linux-dmabuf was used unconditionally if the buffer had a
      modifier. However creating a linux-dmabuf buffer with a format/modifier
      which hasn't been advertised will fail.
      
      Change xwl_glamor_gbm_get_wl_buffer_for_pixmap to use linux-dmabuf when
      the format/modifier has been advertised only.
      Signed-off-by: Simon Ser's avatarSimon Ser <contact@emersion.fr>
      Closes: #1035Tested-by: default avatarEmmanuel Gil Peyrot <linkmauve@linkmauve.fr>
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      (cherry picked from commit c0e13cbf)
      d4e8c462
    • Martin Weber's avatar
      hw/xfree86: Avoid cursor use after free · c726ceac
      Martin Weber authored
      During a VT-Switch a raw pointer to the shared cursor object
      is saved which is then freed (in case of low refcount) by a call to
      xf86CursorSetCursor with argument pCurs = NullCursor.
      This leads to a dangling pointer which can follow in a use after free.
      
      This fix ensures that there is a shared handle saved for the VT-Switch cycle.
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      (cherry picked from commit 7ae221ad)
      c726ceac