Enhancing EDID quirk functionality

[Ian Pilcher <arequipeno@gmail.com>]

Greetings all!

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:

  https://bugzilla.redhat.com/show_bug.cgi?id=806091

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
this quirk.

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:

  drm.edid_quirk=ACR:44358:0x01,ACR:2423:0x20

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
edid_get_quirks()).

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
    above?

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?

Thanks!

-- 
========================================================================
Ian Pilcher                                         arequipeno@gmail.com
"If you're going to shift my paradigm ... at least buy me dinner first."
========================================================================