On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie airlied@gmail.com wrote:
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,
Depends on the system. On non-Macs, some systems have a single mux, others have a separate mux for i2c and display as specified in the ATPX ACPI methods. Not sure how the Macs do it. I've started cleaning up the PX radeon code along with a bunch of other radeon ralated ACPI fixes: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches
Alex