Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 11月, 2011 1 次提交
  3. 22 9月, 2011 1 次提交
    • W
      drm: support routines for HDMI/DP ELD · 76adaa34
      由 Wu Fengguang 提交于 
      ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor.

This adds drm_edid_to_eld() for converting EDID to ELD. The converted
ELD will be saved in a new drm_connector.eld[128] data field. This is
necessary because the graphics driver will need to fixup some of the
data fields (eg. HDMI/DP connection type, AV sync delay) before writing
to the hardware ELD buffer. drm_av_sync_delay() will help the graphics
drivers dynamically compute the AV sync delay for fixing-up the ELD.

ELD selection policy: it's possible for one encoder to be associated
with multiple connectors (ie. monitors), in which case the first found
ELD will be returned by drm_select_eld(). This policy may not be
suitable for all users, but let's start it simple first.

The impact of ELD selection policy: assume there are two monitors, one
supports stereo playback and the other has 8-channel output; cloned
display mode is used, so that the two monitors are associated with the
same internal encoder. If only the stereo playback capability is reported,
the user won't be able to start 8-channel playback; if the 8-channel ELD
is reported, then user space applications may send 8-channel samples
down, however the user may actually be listening to the 2-channel
monitor and not connecting speakers to the 8-channel monitor.

According to James, many TVs will either refuse the display anything or
pop-up an OSD warning whenever they receive hdmi audio which they cannot
handle. Eventually we will require configurability and/or per-monitor
audio control even when the video is cloned.

CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
CC: James Cloos <cloos@jhcloos.com>
CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>
      76adaa34
  5. 04 8月, 2011 2 次提交
  7. 25 7月, 2011 1 次提交
  9. 16 6月, 2011 2 次提交
  11. 28 4月, 2011 2 次提交
  13. 01 4月, 2011 1 次提交
  15. 16 3月, 2011 1 次提交
  17. 23 2月, 2011 1 次提交
  19. 09 11月, 2010 1 次提交
    • S
      DRM: ignore invalid EDID extensions · 0ea75e23
      由 Sam Tygier 提交于 
      Currently an invalid EDID extension will cause the whole EDID to be considered invalid. Instead just drop the invalid extensions, and return the valid ones. The base block is modified to claim to have the number valid extensions, and the check sum is updated.

For my EIZO S2242W the base block is fine, but the extension block is all zeros. Without this patch I get no X and no VTs.
Signed-off-by: NSam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>
      0ea75e23
  21. 19 10月, 2010 1 次提交
  23. 18 9月, 2010 1 次提交
    • C
      drm/i915: use GMBUS to manage i2c links · f899fc64
      由 Chris Wilson 提交于 
      Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      f899fc64
  25. 10 8月, 2010 5 次提交
  27. 29 7月, 2010 1 次提交
  29. 20 7月, 2010 1 次提交
  31. 01 6月, 2010 1 次提交
  33. 26 5月, 2010 1 次提交
  35. 21 5月, 2010 1 次提交
  37. 18 5月, 2010 4 次提交
  39. 10 4月, 2010 1 次提交
  41. 07 4月, 2010 1 次提交
  43. 06 4月, 2010 9 次提交