I will test tonight, but I am almost 100% certain that
radeon_dp_getsinktype(radeon_connector) == CONNECTOR_OBJECT_ID_DISPLAYPORT
Though obviously I must agree that failing to get an EDID would cause this behavior in the radeon driver, it comes nowhere near to explaining the behavior of fglrx.
To recap, fglrx detected that there WAS a connected monitor, and even claimed to ACTIVATE it with a failsafe mode (640x480), or a mode that I set manually (720p, 1080p were the options it offered)... and yet the monitor remained dead. I wish I had a scope -- then I'd be able to know what is REALLY going on.
I supposed that it is possible that fglrx is a liar, crazier things have been known to happen... especially where fglrx is concerned , but failing to get the correct sink type does explain everything, and even makes sense given the assumption that this board CAN successfully activate an actual DP monitor. DDC would only fail if the AUX pins aren't connected, and if that were the case, then this board couldn't possibly activate even an actual DP monitor unless the modes are set manually.
I guess the main question I have is this;
IF there is a REAL DP device connected, and getdpcd() fails, AND it also tries to ddc_probe().... is it possible for a ddc_probe to actually *damage* a DP device? (I.e., through out-of-spec voltage)... If (as I believe to be the case) it can NOT damage a DP device, and IF my assumption about the getsinktype() failing (due to OEM oversight) is correct, then the hack I proposed should work properly under the circumstances I've experienced withOUT interfering with anybody else.
radeon_dp_getsinktype(radeon_connector) == CONNECTOR_OBJECT_ID_DISPLAYPORT
Though obviously I must agree that failing to get an EDID would cause this behavior in the radeon driver, it comes nowhere near to explaining the behavior of fglrx.
To recap, fglrx detected that there WAS a connected monitor, and even claimed to ACTIVATE it with a failsafe mode (640x480), or a mode that I set manually (720p, 1080p were the options it offered)... and yet the monitor remained dead. I wish I had a scope -- then I'd be able to know what is REALLY going on.
I supposed that it is possible that fglrx is a liar, crazier things have been known to happen... especially where fglrx is concerned , but failing to get the correct sink type does explain everything, and even makes sense given the assumption that this board CAN successfully activate an actual DP monitor. DDC would only fail if the AUX pins aren't connected, and if that were the case, then this board couldn't possibly activate even an actual DP monitor unless the modes are set manually.
I guess the main question I have is this;
IF there is a REAL DP device connected, and getdpcd() fails, AND it also tries to ddc_probe().... is it possible for a ddc_probe to actually *damage* a DP device? (I.e., through out-of-spec voltage)... If (as I believe to be the case) it can NOT damage a DP device, and IF my assumption about the getsinktype() failing (due to OEM oversight) is correct, then the hack I proposed should work properly under the circumstances I've experienced withOUT interfering with anybody else.
Comment