On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote:
On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote:
I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ...
The "correct" approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list.
The "correct" approach of switching the mux before we fetch the edid is actualy the one I fear will result in fragile code: Only run on few machines, and as you say with tons of funky interactions with the init sequence ordering. And I guess people will bitch&moan about the flickering this will cause ;-)
As long as it's only apple shipping multi-gpu machines with broken/non-existing vbt, I'll happily stomach the quirk list entries. They're bad, but imo the lesser evil.
Well in theory you can switch the ddc lines without switching the other lines, so we could do a mutex protected mux switch around edid retrival,
Of course someone would have to code it up first then we could see how ugly it would be.
Dave.
-Daniel
Daniel Vetter Mail: daniel@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/