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!