1. 31 May, 2018 2 commits
  2. 13 Apr, 2018 1 commit
  3. 04 Apr, 2018 1 commit
  4. 03 Apr, 2018 3 commits
    • Chris Wilson's avatar
      sna: Reorder vblank/flip event handling to avoid TearFree recursion · 12db28ab
      Chris Wilson authored
      TearFree wants to grab the most recently used scanout for rendering the
      next frame into. If the flip event was still pending, we would then
      query the drm event buffer for any pending completions, but this would
      proceed to execute all the other events before the flip events as well.
      Since we they were out of sequence, we pushed them into a buffer to
      execute afterwards, however we forgot the side effects of the flip
      handlers, for example see commit af36a4ab ("sna: Defer submission
      of the next shadow frame until halfway through") and that there may have
      been events read from drm into a local buffer inside sna_mode_wakeup()
      that haven't been processed yet.
      
      Eliminate the need for calling sna_mode_wakeup() by ensuring that all
      flip events have been completed first before handing the vblank
      callbacks and potential drawing, ensuring the correct ordering.
      
      References: https://bugs.freedesktop.org/show_bug.cgi?id=105720
      
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      12db28ab
    • Chris Wilson's avatar
      sna: Skip shadow redisplay if flips still pending · ca6a57d5
      Chris Wilson authored
      We shouldn't even be attempting to redisplay if there are flips pending,
      so exit early and expect to be called again after the pending flips
      complete. Exiting early avoids having to call sna_mode_wakeup() in what
      used to be a potentially recursive manner (see commit af36a4ab
      
      
      "sna: Defer submission of the next shadow frame until halfway through").
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      ca6a57d5
    • Chris Wilson's avatar
      sna: Report the move_to_gpu failed if the allocation failed · 0a8a8529
      Chris Wilson authored
      
      
      Do not try and workaround the failure by forcing the wait-for-flip as we
      may be inside a vblank handler already. Just report the move failed and
      expect the caller to skip the draw, fairly standard practice for
      allocation failure handling (stale output rather than crash).
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      0a8a8529
  5. 01 Apr, 2018 1 commit
  6. 02 Mar, 2018 2 commits
    • dom.constant@free.fr's avatar
      sna: CustomEDID fix · aa36399c
      dom.constant@free.fr authored and Chris Wilson's avatar Chris Wilson committed
      
      
      For my HTPC setup, I'm using the option "CustomEDID".
      With this option, output attaching and destroying events leads to
      crashes.
      
      The following sequence leads to a crash:
      - In xorg.conf: Option "CustomEDID" "HDMI2:/etc/my_edid.bin"
      - Starting Xorg
      - Connect HDMI2
      - Disconnect HDMI2
      - Reconnect HDMI2
        -> Crash
      
      The crash happens in xf86OutputSetEDID
      (xorg/xserver/hw/xfree86/modes/xf86Crtc.c)
      at "free(output->MonInfo)". MonInfo is assigned with
      sna_output->fake_edid_mon
      which is allocated by intel driver in sna_output_load_fake_edid
      (src/sna/sna_display.c).
      
      Sequence details:
      - Starting Xorg
         -> fake_edid_mon is initialized
      
      - Connect HDMI2
         -> xf86OutputSetEDID is called:
             - MonInfo is NULL
             - MonInfo is assigned with fake_edid_mon pointer
             - MonInfo is read by Xorg
      
      - Disconnect HDMI2
      
      - Reconnect HDMI2
         -> xf86OutputSetEDID is called:
             - MonInfo is freed thus also fake_edid_mon
             - MonInfo is assigned with fake_edid_mon
             - MonInfo is read but it was freed -> CRASH
      
      The fix consists of a new instance of xf86MonPtr for each calls of
      xf86OutputSetEDID.
      is initialized with fake_edid_raw which render
      fake_edid_mon useless.
      With this proposal, the behaviour of an EDID override is similar to
      a "real" EDID.
      Signed-off-by: default avatarDominique Constant <dom.constant@free.fr>
      Reviewed-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      aa36399c
    • Ville Syrjälä's avatar
      sna: Add XV_COLORSPACE attribute support for sprite Xv adaptors · 9b4f4001
      Ville Syrjälä authored and Chris Wilson's avatar Chris Wilson committed
      
      
      Use the new "COLOR_ENCODING" plane property to implement the
      XV_COLORSPACE port attribute for sprite Xv adaptors.
      
      v2: assert(colorspace < ARRAY_SIZE) (Chris)
      
      Cc: Jyri Sarha <jsarha@ti.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: Ville Syrjälä's avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      9b4f4001
  7. 09 Nov, 2017 1 commit
  8. 12 Oct, 2017 3 commits
  9. 08 Oct, 2017 2 commits
  10. 30 Aug, 2017 1 commit
  11. 07 Jun, 2017 2 commits
  12. 18 Apr, 2017 1 commit
  13. 10 Apr, 2017 1 commit
  14. 25 Mar, 2017 2 commits
  15. 10 Mar, 2017 1 commit
  16. 16 Feb, 2017 1 commit
    • Chris Wilson's avatar
      sna: Check link-status after a hotplug event · 880917de
      Chris Wilson authored
      
      
      If the modeset fails, or the link subsequently fails, we need to perform
      the modeset again. To signal this the kernel sends us a hotplug uevent
      with a new link-status property set to bad. The kernel may have to take
      some corrective action which invalidates the current mode and so the
      following modeset may fail and we need to go and report to the client
      for them to choose the next course of action (reconfigure the displays).
      At the very least the kernel *requires* us to reapply the current mode.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      880917de
  17. 01 Feb, 2017 4 commits
  18. 05 Dec, 2016 2 commits
  19. 30 Nov, 2016 1 commit
  20. 18 Nov, 2016 1 commit
  21. 16 Nov, 2016 1 commit
  22. 15 Nov, 2016 2 commits
  23. 05 Nov, 2016 1 commit
  24. 24 Oct, 2016 2 commits
  25. 23 Oct, 2016 1 commit