On Fri, 2008-07-25 at 23:10 +0200, Soeren Sandmann wrote: > If EDID information can not be had without blinking, then flicker free > boot and login is incompatible with multi-screen support that keys off > EDID support. Which of these features should not be implemented, in > your opinion? Blinking is an issue for ridiculous hardware like Intel where you can't do I2C on a connector without turning on a pipe for it. And as a rather nasty side effect, you can plug more outputs into Intel kit than you have pipes: one VGA, two DVI on SDVO, all three with monitors connected but only two pipes. I don't think there's a way to do output probe in this configuration _without_ blinking. Nice one guys. Given the choice, I'd rather have the blinkies. But if we can avoid them by designing the API to avoid cases where the hardware is likely to blink... > If EDID information *can* be had without blinking, then > GetScreenResources is fine as is, and the randr and the drivers just > need to be fixed along the lines Dave suggested. GSR is only "fine" as is if your driver can actually track plug events. There exist some drivers and some hardware where that will never be true. And for those drivers, EDID fetch is a ~100ms stall in the server. That's not acceptable. However, for those drivers, I2C address probe is on the order of 1ms when it succeeds, 10ms to fail. Which isn't great, but is manageable. More to the point, the information _most_ users of GSR seem to want right now is "give me the screen geometry", and not "tell me everything you know about everything". I'm only trying to solve the former here. - ajax
Attachment:
signature.asc
Description: This is a digitally signed message part