Enhancing EDID quirk functionality

[Ian Pilcher]

On 05/03/2012 02:42 PM, Adam Jackson wrote:
> This looks good, thank you for taking it on.

It was either that or give up on my big display, so ... you're welcome.

> I'd like to see documentation for the bit values of the quirks as well.
> And, ideally, this would also have some runtime API for manipulating the
> quirk list, so that way you can test new quirks without needing a reboot
> cycle.

I agree that the bit values should be documented.  I'm not sure where
that documentation should go, however, since I can't find any
documentation of the existing drm module parameters.  Tell me where it
should go, and I'll happily write the doc.

I also agree that it would be nice to be able to manipulate the quirk
list at runtime, and I did think about trying to enable that.  I held
off for a couple of reasons:

1) I'm a total noob at kernel code, so things like in-kernel locking,
   sysfs, memory management, etc., that would be required for a more
   dynamic API are all new to me.

   That said, I'm more that willing to give it a go, if I can get some
   guidance on those (and similar) topics.

2) I'm not sure how a runtime API should work.  The simplest possibility
   is to just take a string, parse it, and overwrite the old extra
   quirk list with the new list.  The downside to this is that all of
   the existing extra quirks need to be repeated to change a single
   quirk.

> To close the loop all the way on that I'd also want to be able to scrape
> the quirk list back out from that API, but that's not completely clean
> right now.

Sound like a couple of sysfs files to me, one for the built-in quirks
and one for the extra quirks -- maybe one quirk per line?  See my
comments about the sysfs API above.

> We're being a little cavalier with the quirk list as it
> stands because we don't differentiate among phy layers, and I can easily
> imagine a monitor that needs a quirk on DVI but where the same quirk on
> the same monitors' VGA would break it.  I don't think this has caused
> problems yet, but.

Now you're above my pay grade.  What little I've read discovered about
the way DisplayPort, HDMI, VGA, and DVI play together makes me think
this is a nightmare best deferred, hopefully forever.

> InfoFrames are not valid for non-HDMI sinks, so yes, I'd call that a bug.

That's pretty much what I figured.

> Where the EDID for DP-1 appears to be truncated: the "extension" field
> (second byte from the end) is 1 as you'd expect for an HDMI monitor, but
> there's no extension block.  How big of a file do you get from
> /sys/class/drm/*/edid for that port?

The EDID data in sysfs is 256 bytes, which I believe means that it does
include the extension block.

I just tried connecting an HDMI TV to my laptop, and I saw the same
behavior -- 256-byte edid file in sysfs, but "xrandr --verbose" only
shows 128 bytes.  When I attach the same TV to my workstation with Intel
"HD 2000" graphics, "xrandr --verbose" shows all 256 bytes of EDID data.

So it appears that the full data is being read by both systems, but the
behavior of xrandr (or presumably whatever API xrandr uses to get the
EDID data that it displays) differs between the two drivers.  Fun.

Thanks!

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