Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.
This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
drm_kms_helper.edid_firmware=edid/1280x1024.bin
It is also possible to restrict the usage of a specified EDID data set
to a particular connector. This is done by prepending the name of the
connector to the name of the EDID data set using the syntax
edid_firmware=[<connector>:]<edid>
such as, for example,
edid_firmware=DVI-I-1:edid/1920x1080.bin
in which case no other connector will be affected.
The built-in data sets are
Resolution Name
--------------------------------
1024x768 edid/1024x768.bin
1280x1024 edid/1280x1024.bin
1680x1050 edid/1680x1050.bin
1920x1080 edid/1920x1080.bin
They are ignored, if a file with the same name is available in the
/lib/firmware directory.
The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the
drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.
It is even possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.
Signed-off-by: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
to add the missing drm_mode_object_put for that mode.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This allows to avoid talking to a non-responding bus repeatedly until we
finally timeout after 15 attempts. We can do this by catching the -ENXIO
error, provided by i2c_algo_bit:bit_doAddress call.
Within the bit_doAddress we already try 3 times to get the edid data, so
if the routine tells us that bus is not responding, it is mostly pointless
to keep re-trying those attempts over and over again until we reach final
number of retries.
This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059
and improve overall edid detection timing by 10-30% in most cases, and by
a much larger margin in case of phantom outputs (up to 30x in one worst
case).
Timing results for i915-powered machines for 'time xrandr' command:
Machine 1: from 0.840s to 0.290s
Machine 2: from 0.315s to 0.280s
Machine 3: from +/- 4s to 0.184s
Timing results for HD5770 with 'time xrandr' command:
Machine 4: from 3.210s to 1.060s
Reviewed-by: Chris Wilson <chris@hchris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Sean Finney <seanius@seanius.net>
Tested-by: Soren Hansen <soren@linux2go.dk>
Tested-by: Hernando Torque <sirius@sonnenkinder.org>
Tested-by: Mike Lothian <mike@fireburn.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The current logic misunderstands the spec about CEA 18byte descriptors.
First, the spec doesn't state "detailed timing descriptors" but "18 byte
descriptors", so any data record could be stored, mixed timings and
other data, just as in the standard EDID.
Second, the lower four bit of byte 3 of the CEA record do not contain
the number of descriptors, but "the total number of DTDs defining native
formats in the whole EDID [...], starting with the first DTD in the DTD
list (which starts in the base EDID block)." A device can of course
support non-native formats.
As such the number can't be used to determine n, and the existing code
will filter non-timing 18byte descriptors anyway.
Signed-off-by: Christian Schmidt <schmidt@digadd.de>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
CEA datablocks are only defined from revision 3 onwards. Only check for
them if the revision says so.
Signed-of-by: Christian Schmidt <schmidt@digadd.de>
Tested-by: James Cloos <cloos@jhcloos.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Provides function drm_edid_header_is_valid() for EDID header check
and replaces EDID header check part of function drm_edid_block_valid()
by a call of drm_edid_header_is_valid().
This is a prerequisite to extend DDC probing, e. g. in function
radeon_ddc_probe() for Radeon devices, by a central EDID header check.
Tested for kernel 2.6.35, 2.6.38 and 3.0
Cc: <stable@kernel.org>
Signed-off-by: Thomas Reim <reimth@gmail.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Acked-by: Stephen Michaels <Stephen.Micheals@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-intel-next' of ssh://master.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6: (42 commits)
drm/i915: allow cache sharing policy control
drm/i915/hdmi: HDMI source product description infoframe support
drm/i915/hdmi: split infoframe setting from infoframe type code
drm: track CEA version number if present
drm/i915: Try enabling RC6 by default (again)
Revert "drm/i915/dp: Zero the DPCD data before connection probe"
drm/i915/dp: wait for previous AUX channel activity to clear
drm/i915: don't use uninitialized EDID bpc values when picking pipe bpp
drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
drm/i915: apply phase pointer override on SNB+ too
drm/i915: Add quirk to disable SSC on Sony Vaio Y2
drm/i915: provide more error output when mode sets fail
drm/i915: add GPU max frequency control file
i915: add Dell OptiPlex FX170 to intel_no_lvds
drm/i915: Ignore GPU wedged errors while pinning scanout buffers
drm/i915/hdmi: send AVI info frames on ILK+ as well
drm/i915: fix CB tuning check for ILK+
drm/i915: Flush other plane register writes
drm/i915: flush plane control changes on ILK+ as well
drm/i915: apply timing generator bug workaround on CPT and PPT
...
Drivers need to know the CEA version number in addition to other display
info (like whether the display is an HDMI sink) before enabling certain
features. So track the CEA version number in the display info
structure.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
Also disable the ascii dump and remove the literal printing of the
KERN_ERR macro in the log:
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
v2: Remove the trailing empty line as well.
Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some RS690 chipsets seem to end up with floating connectors, either
a DVI connector isn't actually populated, or an add-in HDMI card
is available but not installed. In this case we seem to get a NULL byte
response for each byte of the i2c transaction, so we detect this
case and if we see it we don't do anymore DDC transactions on this
connector.
I've tested this on my RS690 without the HDMI card installed and
it seems to work fine.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
this puts the header and followup at the same loglevel as the
hex dump code.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
EDID 1.4 digital displays report the color spaces they support in the
features block. Add support for grabbing this data and stuffing it into
the display_info struct for driver use.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
EDID 1.4 digital monitors report the bit depth supported in the input
field. Add support for parsing this out and storing the info in the
display_info structure for use by drivers.
[airlied: tweaked to fix inter-patch dependency]
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Usually EDID retrieval is fine. However, sometimes, especially when the
machine is loaded, it fails, but succeeds after a few retries.
Based on a patch by Michael Buesch.
Reported-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
... and fixup some methods to accept the constant argument.
Now that constant module arrays are loaded into read-only memory, using
const appropriately has some benefits beyond warning the programmer
about likely mistakes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
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: Sam Tygier <samtygier@yahoo.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
To help to determine if digital display port needs to enable
audio output or not. This one adds a helper to get monitor's
audio capability via EDID CEA extension block.
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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: Chris Wilson <chris@chris-wilson.co.uk>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (55 commits)
io-mapping: move asm include inside the config option
vgaarb: drop vga.h include
drm/radeon: Add probing of clocks from device-tree
drm/radeon: drop old and broken mesa warning
drm/radeon: Fix pci_map_page() error checking
drm: Remove count_lock for calling lastclose() after 58474713 (v2)
drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx
drm/radeon/kms: another r6xx/r7xx CS checker fix
DRM: Replace kmalloc/memset combos with kzalloc
drm: expand gamma_set
drm/edid: Split mode lists out to their own header for readability
drm/edid: Rewrite mode parse to use the generic detailed block walk
drm/edid: Add detailed block walk for VTB extensions
drm/edid: Add detailed block walk for CEA extensions
drm: Remove unused fields from drm_display_info
drm: Use ENOENT consistently for the error return for an unmatched handle.
drm/radeon/kms: mark 3D power states as performance
drm: Only set DPMS once on the CRTC not after every encoder.
drm/radeon/kms: add additional quirk for Acer rv620 laptop
drm: Propagate error code from fb_create()
...
Fix up trivial conflicts in drivers/gpu/drm/drm_edid.c
This brings us in line with the EDID spec recommendation for mode
priority sorting. We still don't extract all the modes we could from
VTB, but VTB is so rare in the wild that I'm not really concerned.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (204 commits)
agp: intel-agp: do not use PCI resources before pci_enable_device()
agp: efficeon-agp: do not use PCI resources before pci_enable_device()
drm: kill BKL from common code
drm/kms: Simplify setup of the initial I2C encoder config.
drm,io-mapping: Specify slot to use for atomic mappings
drm/radeon/kms: only expose underscan on avivo chips
drm/radeon: add new pci ids
drm: Cleanup after failing to create master->unique and dev->name
drm/radeon: tone down overchatty acpi debug messages.
drm/radeon/kms: enable underscan option for digital connectors
drm/radeon/kms: fix calculation of h/v scaling factors
drm/radeon/kms/igp: sideport is AMD only
drm/radeon/kms: handle the case of no active displays properly in the bandwidth code
drm: move ttm global code to core drm
drm/i915: Clear the Ironlake dithering flags when the pipe doesn't want it.
drm/radeon/kms: make sure HPD is set to NONE on analog-only connectors
drm/radeon/kms: make sure rio_mem is valid before unmapping it
drm/agp/i915: trim stolen space to 32M
drm/i915: Unset cursor if out-of-bounds upon mode change (v4)
drm/i915: Unreference object not handle on creation
...
We're adjusting horizontal timings only here, moving vsync was just a
slavish translation of a typo in the X server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Allow platform devices without PCI resources to be DRM devices.
[airlied: fixup warnings with dev pointers]
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Switches will try to update the topology address and not correctly fix
up the checksum, so just let it slide.
https://bugs.freedesktop.org/28229
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Spotted by Scott Bertilson.
Fixes fdo bug 28146.
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Reviewed-by: Mark Marshall <mark.marshall@csr.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Simple cloning rules compared to server:
(a) single crtc
(b) > 1 connector active
(c) check command line mode
(d) try and find 1024x768 DMT mode if no command line.
(e) fail to clone
Signed-off-by: Dave Airlie <airlied@redhat.com>
m == num_est3_modes is one past the end of the est3_modes[].
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Having hsync both start and end on pixel 1072 ain't gonna work very
well. Matches the X server's list.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-By: Michael Tokarev <mjt@tls.msk.ru>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
We don't use timing_level any more after: 9cf00977da "drm/edid: Unify
detailed block parsing between base and extension blocks".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm-edid-fixes:
drm/edid: When checking duplicate standard modes, walked the probed list
drm/edid: Fix sync polarity for secondary GTF curve
drm/modes: Fix interlaced mode names
drm/edid: Add secondary GTF curve support
drm/edid: Strengthen the algorithm for standard mode codes
drm/edid: Fix the HDTV hack.
drm/edid: Extend range-based mode addition for EDID 1.4
drm/edid: Add test for monitor reduced blanking support.
drm/edid: Fix preferred mode parse for EDID 1.4
drm/edid: Remove some silly comments
drm/edid: Remove arbitrary EDID extension limit
drm/edid: Add modes for Established Timings III section
drm/edid: Reshuffle mode list construction to closer match the spec
drm/edid: Remove a redundant check
drm/edid: Remove some misleading comments
drm/edid: Fix secondary block fetch.
* 'drm-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (29 commits)
drm/nouveau: bail out of auxch transaction if we repeatedly recieve defers
drm/nv50: implement gpio set/get routines
drm/nv50: parse/use some more de-magiced parts of gpio table entries
drm/nouveau: store raw gpio table entry in bios gpio structs
drm/nv40: Init some tiling-related PGRAPH state.
drm/nv50: Add NVA3 support in ctxprog/ctxvals generator.
drm/nv50: another dodgy DP hack
drm/nv50: punt hotplug irq handling out to workqueue
drm/nv50: preserve an unknown SOR_MODECTRL value for DP encoders
drm/nv50: Allow using the NVA3 new compute class.
drm/nv50: cleanup properly if PDISPLAY init fails
drm/nouveau: fixup the init failure paths some more
drm/nv50: fix instmem init on IGPs if stolen mem crosses 4GiB mark
drm/nv40: add LVDS table quirk for Dell Latitude D620
drm/nv40: rework lvds table parsing
drm/nouveau: detect vram amount once, and save the value
drm/nouveau: remove some unused members from drm_nouveau_private
drm/nouveau: Make use of TTM busy_placements.
drm/nv50: add more 0x100c80 flushy magic
drm/nv50: fix fbcon when framebuffer above 4GiB mark
...
Height in frame size, not field size, and trailed with an 'i'. Matches
the X server behaviour.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Before CVT-R, some monitors would advertise support for an alternative
GTF formula with lower blanking intervals. Correctly identify such
monitors, and use the alternative formula when generating modes for
them.
Note that we only do this for "standard" timing descriptors (tuples of
hsize in characters / aspect ratio / vertical refresh). Range-based
mode lists still only refer to the primary GTF curve. It would be
possible to do better for the latter case, but monitors are required to
support the primary curve over the entire advertised range, so all it
would win you is a lower pixel clock and therefore possibly better image
quality on analog links.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
If you have 1920x1200 in both detailed (probably RB) and standard
variants, you probably only want the RB version. But we have no way of
guessing that from standard mode parse. So, if a mode already exists
for a given w/h/r, skip adding it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Standard timings don't let you say 1366. Both 1360 and 1368 have been
seen in the wild. So invent a CVT timing for it. CVT will round 1366 up
to 1368; we'll then manually underscan it.
Split this into two parts, since we need to do something sneaky between
them in the future.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
1.4 adds better pixel clock precision, explicit reduced blanking
awareness, and extended sync ranges. It's almost like a real spec.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Matt Turner