Commit graph

17 commits

Author SHA1 Message Date
Takashi Iwai
8353e6c632 drm/edid: Add packed attribute to new gtf2 and cvt structs
The new structs added in struct detailed_data_monitor_range must be
marked with packed attribute although the outer struct itself is
already marked as packed.  Otherwise these 7-bytes structs may be
aligned, and give the wrong position and size for the data.

Signed-off-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-23 17:41:17 +01:00
Adam Jackson
eeefa4bea1 drm/edid: Update range descriptor struct for EDID 1.4
Signed-off-by: Adam Jackson <ajax@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-04-20 12:57:37 +01:00
Carsten Emde
da0df92b57 drm: allow loading an EDID as firmware to override broken monitor
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>
2012-03-20 10:09:28 +00:00
Wu Fengguang
76adaa34db drm: support routines for HDMI/DP ELD
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>
2011-09-21 14:52:41 -07:00
Jesse Barnes
da05a5a71a drm: parse color format support for digital displays
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>
2011-04-28 14:44:56 +10:00
Jesse Barnes
3b11228b54 drm: add bit depth parsing
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>
2011-04-28 14:42:58 +10:00
Adam Jackson
4d76a22134 drm/edid: Add detailed block walk for CEA extensions
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-08-10 10:46:57 +10:00
Dan Carpenter
96525a2f74 drm_edid: There should be 6 Standard Timings
Smatch complained that we initialize 6 elements in add_detailed_modes()
but the timings[] array is declared with 5 elements.  Adam Jackson
verified that 6 is the correct number of timings.

On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote:
> > >                 struct std_timing timings[5];
> > >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> This decl is wrong, should be 6.  From the 1.4 spec:
>
> "Six additional Standard Timings may be listed as a display descriptor
> (tag #FAh)."
>
> The 1.3 spec is a little less explicit about it, but does show 6
> standard timing codes in the 0xFA detailed subblock, terminated by 0x0A
> in the 18th byte.  I don't have the docs for 1.2 or earlier, but we're
> paranoid enough about not adding broken timings that we should be fine.

This patch is basically a clean up, because timings[] is declared inside
a union and increasing the number of elements here doesn't change the
overall size of the union.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-05-18 15:56:14 +10:00
Adam Jackson
7466f4cc50 drm/edid: Remove arbitrary EDID extension limit
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-06 10:40:20 +10:00
Alex Deucher
3c537889e1 drm/radeon/kms: add support for hardcoded edids in rom (v2)
Some servers hardcode an edid in rom so that they will
work properly with KVMs.  This is a port of the relevant
code from the ddx.

[airlied: reworked to validate edid at boot stage - and
remove special quirk, if there is a valid EDID in the BIOS rom
we'll just try and use it.]

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-09 09:31:20 +10:00
Adam Jackson
9340d8cfea drm/edid: Decode 3-byte CVT codes from EDID 1.4
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-04 08:53:47 +10:00
Adam Jackson
2dbdc52c81 drm/edid: Add new detailed block types from EDID 1.4
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-12-04 08:53:40 +10:00
Michel Dänzer
e14cbee401 drm: Fix shifts which were miscalculated when converting from bitfields.
Looks like I managed to mess up most shifts when converting from bitfields. :(

The patch below works on my Thinkpad T500 (as well as on my PowerBook,
where the previous change worked as well, maybe out of luck...). I'd
appreciate more testing and eyes looking over it though.

Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Michael Pyne <mpyne@kde.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-06-24 16:11:04 +10:00
Michel Dänzer
0454beab0f drm: EDID endianness fixes.
Mostly replacing bitfields with explicit masks and shifts.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-19 09:11:13 +10:00
Pantelis Koukousoulas
260cf8a2cb drm: fix EDID parser problem with positive/negative hsync/vsync
Comparing the layouts of struct detail_pixel_timing with
x.org's struct detailed_timings and how those are handled,
it appears that the hsync_positive and vsync_positive
fields are backwards.

This patch fixes https://bugs.freedesktop.org/show_bug.cgi?id=20019
for me. It was tested on 2 monitors, LG FLATRON L225WS 22" and
a YAKUMO 17" for which more details are unknown.

Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-03-11 12:18:48 +10:00
Jesse Barnes
fe56cf45f9 drm: Fix ordering of bit fields in EDID structure leading huge vsync values.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-02-25 14:11:00 +10:00
Dave Airlie
f453ba0460 DRM: add mode setting support
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>
2008-12-29 17:47:23 +10:00