Enhancing EDID quirk functionality
arequipeno at gmail.com
Thu Apr 19 12:16:55 PDT 2012
I recently discovered that my nice 1900x1200 display is horribly
confused by the InfoFrame functionality that was added to the nouveau
driver in Linux 3.3. Additional testing has shown that it has the same
problem with the i915 driver and NVIDIA's proprietary driver.
NVIDIA's Windows 7 driver does not exhibit the problem, but it appears
that the problem was seen a few years ago on Windows Vista. See this
Red Hat Bugzilla for all the gory details:
Ben Skeggs suggested that the proper way to proceed is an EDID quirk
that will disable InfoFrames by causing drm_detect_hdmi_monitor() return
false. I'm thinking of EDID_QUIRK_DISABLE_HDMI as the symbolic name for
After looking through drm_edid.c and noticing that my display appears to
be reporting non-existent audio functionality, I believe that quirk
which disables HDMI audio functionality (by causing
drm_detect_monitor_audio() to return false) might also be useful.
Before I start turning things off, however, I think it's really
important to provide users with a way to override these quirks. (Who's
to say there isn't a variant of my display out there somewhere with
exactly the same EDID that actually does have speakers?) And wouldn't
it be extremely useful for users to be able to add EDID quirks on the
kernel command line -- for testing/workaround purposes?
I'm thinking of a syntax like:
This would be parsed into a separate quirks list (edid_user_quirk_list?)
which could add new quirks or override built-in quirks (by changing
Parsing the quirks will be a bit of a pain. I'm new to writing kernel
code, so pointers to any appropriate helper functions or examples of
parsing somewhat complex strings in-kernel would be appreciated.
The other prerequisite, IMO, is for the kernel to log the displays that
it detects, so that users know what the first two fields of a quirk
should be. (Currently, the easiest place to get this is the X log.) I
tried adding this logging to drm_get_edid(), but the results were overly
verbose; apparently that function gets called fairly frequently. Is
there a better place to log a newly detected display?
So my specific questions at this time are:
1. Any objections to the functionality or approach that I've outlined
2. How should I go about parsing a "quirk string"? (Pointers to helper
functions and/or examples of similar parsing requested.)
3. What is the best place at which to log newly detected displays?
Ian Pilcher arequipeno at gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
More information about the dri-devel