1. 03 Mar, 2019 1 commit
    • Adam Simpkins's avatar
      xrandr: fix crash if some modes cannot be found · 9e5fa7c8
      Adam Simpkins authored
      When printing modes in "xrandr -q", check to see if we failed to look up
      mode information from a mode XID.  Previously the command would
      dereference null and crash if the mode information could not be found.
      
      When using an external HDMI monitor on a laptop with a Skylake Intel
      graphics chipset "xrandr -q" occasionally is unable to look up mode
      information for some of the modes.  It seems likely there is some other
      sort of library or driver issue causing these lookup failures, but this
      change to xrandr at least prevents it from segfaulting.
      Signed-off-by: Alan Coopersmith's avatarAlan Coopersmith <alan.coopersmith@oracle.com>
      9e5fa7c8
  2. 22 Nov, 2018 1 commit
  3. 17 Nov, 2018 1 commit
  4. 12 Sep, 2018 1 commit
    • Peter Hutterer's avatar
      init the name to 0 · a2134406
      Peter Hutterer authored
      There are a few conditions where coverity finds a use of an uninitialized
      field of the name_t struct. These are rather messy combinations of conditions,
      so let's go with the simple solution here and just init everything to 0.
      This may still have side-effects but at least they'll be more obvious than the
      previous "use whatever memory is leftover from breakfast".
      
      This patch also adds a missing init_name(), much for the same reason.
      Signed-off-by: Peter Hutterer's avatarPeter Hutterer <peter.hutterer@who-t.net>
      a2134406
  5. 24 Mar, 2018 1 commit
  6. 27 Feb, 2018 6 commits
  7. 02 Jun, 2017 1 commit
  8. 01 Jun, 2017 1 commit
  9. 29 May, 2017 1 commit
  10. 24 Mar, 2017 2 commits
  11. 26 Jan, 2017 3 commits
  12. 23 Feb, 2016 1 commit
  13. 20 Oct, 2015 1 commit
    • Chris Wilson's avatar
      Only use the current information when setting modes · d62030b5
      Chris Wilson authored
      Before we change the state (e.g. adding a mode or applying one to an
      output), we query the screen resources for the right identifiers. This
      should only use the current information rather than force a reprobe on
      all hardware - not only can that reprobe be very slow (e.g. EDID
      timeouts on the order of seconds), but it may perturb the setup that the
      user is trying to configure.
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      d62030b5
  14. 01 Jul, 2015 2 commits
    • Chris Wilson's avatar
      Mark all CRTC as currently unused for second picking CRTC pass · 3d03be78
      Chris Wilson authored
      We perform two passes over the CRTC in order to find the preferred CRTC
      for each enabled output. In the first pass, we try to preserve the
      existing output <-> CRTC relationships (to avoid unnecessary flicker).
      If that pass fails, we try again but with all outputs first disabled.
      However, the logic to preserve an active CRTC was not disabled along
      with the outputs - meaning that if one was active but its associated
      output was disabled by the user, then that CRTC would remain unavailable
      for other outputs. The result would be that we would try to assign more
      CRTC than available (i.e. if the user request 3 new HDMI outputs on a
      system with only 3 CRTC, and wished to switch off an active internal
      panel, we would report "cannot find CRTC" even though that configuration
      could be established.)
      Reported-and-tested-by: 's avatarNathan Schulte <nmschulte@gmail.com>
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      3d03be78
    • Chris Wilson's avatar
      Mark disabling an output as a change in its CRTC · 53ef3fc1
      Chris Wilson authored
      When an output is disabled via the cmdline, we can use that information
      to prevent assigning the current CRTC to the output and free it up for
      reuse by other outputs in the first pass of picking CRTC.
      Reported-and-tested-by: 's avatarNathan Schulte <nmschulte@gmail.com>
      Signed-off-by: Chris Wilson's avatarChris Wilson <chris@chris-wilson.co.uk>
      53ef3fc1
  15. 22 Apr, 2015 1 commit
  16. 31 Mar, 2015 2 commits
  17. 30 Mar, 2015 1 commit
  18. 08 Oct, 2014 2 commits
  19. 02 Aug, 2014 3 commits
  20. 25 Jun, 2014 2 commits
  21. 30 Apr, 2014 1 commit
    • Dominik Behr's avatar
      xrandr: use full range for gamma table generation · 792f05ea
      Dominik Behr authored
      Calculate gamma table using full [0,65536) range and do not make any
      assumptions about relation of gamma table size and significant bits.
      
      Gamma table size has nothing to do with number of significant bits in hardware.
      In particular we are dealing now with gamma table that has 17 entries and 8
      bit precision, there are other GPUs with 10 bit precision and less than 256
      entries using partial linear approximation. Deriving assumed gamma table
      significant bits from size of gamma table leads to incorrect calculations and
      loss of precision. Also XRandR specification never mentions that gamma tables
      need to be power of 2.
      Signed-off-by: Dominik Behr's avatarDominik Behr <dbehr@chromium.org>
      Reviewed-by: 's avatarStéphane Marchesin <marcheu@chromium.org>
      792f05ea
  22. 29 Mar, 2014 1 commit
  23. 27 Mar, 2014 2 commits
  24. 12 Mar, 2014 1 commit
  25. 20 Feb, 2014 1 commit