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@xxxxxxxxx "If you're going to shift my paradigm ... at least buy me dinner first." ======================================================================== _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
