summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/drm_edid.c
AgeCommit message (Collapse)AuthorFilesLines
2009-06-12drm: Eliminate magic I2C frobbing when reading EDIDKeith Packard1-73/+1
This code depends on the underlying I2C adapter using the bit-banging algo, which may not be the case. If specific encoders require this mechanism, they should build a custom I2C algo that implements this workaround, rather than having it in the general path. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-04drm: ignore EDID with really tiny modes.Adam Jackson1-0/+5
Some EDIDs lie and report tiny modes that aren't possible. Ignore these modes. Signed-off-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-04-03drm: fix EDID backward compat checkJesse Barnes1-4/+2
EDIDs should be backward compatible, so don't bail if we see a version of 3 (which is out there now) and print a message if we see something newer, but allow it to be parsed. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-04-03drm: fix typo in edid vendor parsing.Dave Airlie1-1/+1
Should be, edid_vendor[2] = (edid->mfg_id[1] & 0x1f) + '@'; Since vendor ID has only two bytes only, I am somewhat surprised why gcc doesn't complain this. Reported-by: Guo, Chaohong <chaohong.guo@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-03-29drm: detect hdmi monitor by hdmi identifier (v3)Ma Ling1-0/+62
Sometime we need to communicate with HDMI monitor by sending audio or video info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device. The patch intends to detect HDMI monitor by this rule. Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-03-29drm: read EDID extensions from monitorMa Ling1-28/+93
Usually drm read basic EDID, that is enough for us, but since igital display were introduced i.e. HDMI monitor, sometime we need to interact with monitor by EDID extension information, EDID extensions include audio/video data block, speaker allocation and vendor specific data blocks. This patch intends to read EDID extensions from digital monitor for users. Signed-off-by: Ma Ling <ling.ma@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-02-25drm: edid revision 0 is validKyle McMartin1-1/+1
edid->revision == 0 should be valid (at least, so the error message indicates. :) and wikipedia seems to indicate that EDID 1.0 existed. We can dump the entire check, since edid->revision is a u8, so it can't ever be less than 0. Marko reports in RH bz#476735 that his monitor claims to be EDID 1.0, and therefore hits the check and is stuck at 800x600 because of it. Reported-by: Marko Ristola <marko.ristola@kolumbus.fi> Signed-off-by: Kyle McMartin <kyle@redhat.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-02-25drm: Fix shifts of EDID vsync offset/width fields.Linus Torvalds1-2/+2
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-01-22drm: don't whine about not reading EDID dataJesse Barnes1-1/+1
Make this message a little quieter, since it's common and not necessarily indicative of a problem. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29drm: fix useless gcc unused variable warningDave Airlie1-1/+1
the calling function doesn't call this function unless one of the two states that sets the value is true. Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29DRM: add mode setting supportDave Airlie1-0/+732
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: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Eric Anholt <eric@anholt.net> Signed-off-by: Dave Airlie <airlied@redhat.com>