1. 07 9月, 2009 1 次提交
    • Z
      drm/kms: try to find the std mode in DMT table · 559ee21d
      Zhao Yakui 提交于
      When we need to add the standard timing mode, we will firstly check whether it
      can be found in DMT table by comparing the hdisplay/vdisplay/vfresh_rate.
      If it can't be found, then we will use the cvt/gtf to add the required mode.
      If it can be found, it will be returned.
      
      At the same time the function of drm_mode_vrefresh is also fixed. It will
      return the result of actual refresh_rate plus 0.5.
      For example:
      When the calculated value is 84.9, then the fresh_rate is 85.
      When the calculated value is 70.02, then the fresh_rate is 70.
      Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      559ee21d
  2. 13 8月, 2009 1 次提交
  3. 09 8月, 2009 1 次提交
    • K
      drm: When adding probed modes, preserve duplicate mode types · 38d5487d
      Keith Packard 提交于
      The code which takes probed modes and adds them to a connector eliminates
      duplicate modes by comparing them using drm_mode_equal. That function
      doesn't consider the type bits, which means that any modes which differ only
      in the type field will be lost.
      
      One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
      If the mode with that bit is lost, then higher level code will not know
      which mode to select, causing a random mode to be used instead.
      
      This patch simply merges the two mode type bits together; that seems
      reasonable to me, but perhaps only a subset of the bits should be used? None
      of these can be user defined as they all come from looking at just the
      hardware.
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      38d5487d
  4. 04 8月, 2009 2 次提交
  5. 15 7月, 2009 2 次提交
  6. 12 6月, 2009 1 次提交
  7. 29 12月, 2008 1 次提交
    • D
      DRM: add mode setting support · f453ba04
      Dave Airlie 提交于
      Add mode setting support to the DRM layer.
      
      This is a fairly big chunk of work that allows DRM drivers to provide
      full output control and configuration capabilities to userspace.  It was
      motivated by several factors:
        - the fb layer's APIs aren't suited for anything but simple
          configurations
        - coordination between the fb layer, DRM layer, and various userspace
          drivers is poor to non-existent (radeonfb excepted)
        - user level mode setting drivers makes displaying panic & oops
          messages more difficult
        - suspend/resume of graphics state is possible in many more
          configurations with kernel level support
      
      This commit just adds the core DRM part of the mode setting APIs.
      Driver specific commits using these new structure and APIs will follow.
      
      Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
      Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.com>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NEric Anholt <eric@anholt.net>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      f453ba04