From: Carsten Emde <C.Emde@osadl.org>
To: Thomas Reim <reimth@googlemail.com>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>,
DRI <dri-devel@lists.freedesktop.org>,
Thomas Gleixner <tglx@linutronix.de>,
Paul Menzel <paulepanter@users.sourceforge.net>
Subject: Re: [V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch
Date: Sun, 18 Mar 2012 21:22:46 +0100 [thread overview]
Message-ID: <4F664416.2040709@osadl.org> (raw)
In-Reply-To: <1332089572.6271.66.camel@Mark-Aurel.gas.de>
Dear Thomas,
> your proposal will not lead to a satisfying solution for those people
> that suffer from monitors and other HW devices that provide wrong
> EDIDs.
Oops, why not?
> Before fetching the display modes, all drm devices will try to detect
> the monitor. If EDID data is not correct (checksum), an error
> notification including an EDID dump will be stored in the logs.
> Depending on the driver (Intel, Radeon, ...) a wrong EDID during
> detection may prevent the further use of the connector until
> detection of a valid EDID.
Yes - until detection of a valid EDID. Specifying the "edid_firmware="
module parameter leads to the detection of a valid EDID and then
everything works - at least, if the specified EDID data is valid. This
works pretty well in more than 15 systems that I tested - admittedly
only Intel and Radeon but many different adapters, monitors and reasons
for misbehavior. Did you try the patch? If so, which graphics adapter
did you try? It is well possible that I overlooked a detail that is not
relevant in the adapters that I tested. Please let me know so I can fix it.
> Furthermore, all current graphic adapters provide at least three and
> even more connectors. Many people use two monitors in parallel.
This is a good point. I will provide a new version of the patch that
allows to alternatively prepend the connector name to the name of the
EDID firmware separated by a colon such as
edid_firmware=[<connector>:]<firmware>
> If I understand your patch correctly, it would load EDID defaults
> for all connectors and all monitors, despite of their EDID being
> correct or wrong.
For all connectors with a monitor connected to it, yes. It is impossible
to always decide whether a particular EDID data set is wrong or not. It
may, for example, have a correct CRC but still lie to the connector
about other things such as sync polarity.
> What about audio parameters for HDMI connectors?
Not yet considered.
> On the other hand, there are still KVM switches and monitors out that
> would work correctly. but provide an incorrect, not usuable EDID. If
> we focus the default EDID loading on the buggy EDIDs over a working
> (!) connector, I could imagine a benefit for all users.
Again, this is not possible. Only a human being sitting in front of a
monitor can decide whether a particular EDID data set works or not.
The upcoming version that allows to specify the connector name for a
given EDID firmware probably will solve this situation. If you specify
the EDID firmware for the connector only to which the broken monitor is
connected, the other connectors will not be affected.
Thanks,
-Carsten.
next prev parent reply other threads:[~2012-03-18 20:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-15 14:56 [V5 PATCH 0/4] Provide workarounds to use DRM/KMS with broken graphics hardware Carsten Emde
2012-03-15 14:56 ` [V5 PATCH 1/4] drivers-gpu-drm-allow-to-load-edid-firmware.patch Carsten Emde
2012-03-18 2:39 ` Valdis.Kletnieks
2012-03-18 2:39 ` Valdis.Kletnieks
2012-03-18 16:52 ` Thomas Reim
2012-03-18 20:22 ` Carsten Emde [this message]
2012-03-15 14:56 ` [V5 PATCH 2/4] drivers-gpu-drm-i915-panel-invert-brightness-via-parameter.patch Carsten Emde
2012-03-15 15:15 ` Chris Wilson
2012-03-15 15:15 ` Chris Wilson
2012-03-15 14:56 ` [V5 PATCH 3/4] drivers-gpu-drm-i915-panel-invert-brightness-via-quirk.patch Carsten Emde
2012-03-15 15:15 ` Chris Wilson
2012-03-15 15:15 ` Chris Wilson
2012-03-15 14:56 ` [V5 PATCH 4/4] drivers-gpu-drm-i915-panel-invert-brightness-acer-aspire-5734z.patch Carsten Emde
2012-03-15 15:16 ` Chris Wilson
2012-03-15 15:16 ` Chris Wilson
2012-03-18 19:00 ` [V5 PATCH 0/4] Provide workarounds to use DRM/KMS with broken graphics hardware Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F664416.2040709@osadl.org \
--to=c.emde@osadl.org \
--cc=Valdis.Kletnieks@vt.edu \
--cc=dri-devel@lists.freedesktop.org \
--cc=paulepanter@users.sourceforge.net \
--cc=reimth@googlemail.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.