Announcement

Collapse
No announcement yet.

890GX/HD4290 dual display question

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    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.

    Comment


    • #82
      Based on what you've reported I don't see how a DP monitor could work. DP requires link training to bring up a link so there is no way to manually force a mode; both sides (monitor and card) have to negotiate the link. If the aux pins are not working you cannot get the dpcp or check the link status or get the DP EDID.

      I suspect in the fglrx case, it too sees the sink as CONNECTOR_OBJECT_ID_DISPLAYPORT. It may use that alone to determine connected state rather than also checking the dpcd. However, it also seems unable to get an EDID which is why it defaults to 640x480. If it tries to light up a DP screen without working aux pins, there's no way to get the dpcd and train the link so it won't work.

      Comment


      • #83
        Based on this discussion, is it right that in current radeon it's not possible to run a screen without edid?

        ie. faulty connectors, some KVM switches, old screens.

        If so, maybe add a force option?

        Comment


        • #84
          Originally posted by agd5f View Post
          Based on what you've reported I don't see how a DP monitor could work. DP requires link training to bring up a link so there is no way to manually force a mode; both sides (monitor and card) have to negotiate the link. If the aux pins are not working you cannot get the dpcp or check the link status or get the DP EDID.

          I suspect in the fglrx case, it too sees the sink as CONNECTOR_OBJECT_ID_DISPLAYPORT. It may use that alone to determine connected state rather than also checking the dpcd. However, it also seems unable to get an EDID which is why it defaults to 640x480. If it tries to light up a DP screen without working aux pins, there's no way to get the dpcd and train the link so it won't work.
          The thing is that I don't HAVE a DP screen to test with, just DVI, which is why it is just theories and guesses about what it is doing.

          As for fglrx detecting the sink type as DP and using that to determine connected state... I suspect that it would report sink type as DP even with nothing plugged in at all (will test this tonight).

          Just remember that DP and DVI use the AUX/DDC pins in a completely different way. In DP, the AUX channel pins are arranged in AUX channel + and -, and the clock signal is embedded in the data. In the case of DVI, the AUX+ is used as DDC clock, and AUX- is used as DDC data... so if the port is in DP mode, DDC will not work and you don't get EDID.

          In any case, I have confirmed beyond any doubt that it is detecting the sink as DP, however even ignoring this, I am still unable to probe ddc, so I am still without EDID.

          I suspect that the reason for this is that a DDC probe won't work unless the port is in TMDS mode, but the port is in DP mode every time that function is called.

          Is there any way to perform a DDC probe *AFTER* the display is already online?

          Comment


          • #85
            Originally posted by curaga View Post
            Based on this discussion, is it right that in current radeon it's not possible to run a screen without edid?

            ie. faulty connectors, some KVM switches, old screens.

            If so, maybe add a force option?
            This code that we're looking at here is specific to DisplayPort outputs. Other types of outputs may behave different.

            Comment


            • #86
              Originally posted by droidhacker View Post
              Is there any way to perform a DDC probe *AFTER* the display is already online?
              -- by that I mean just a simple query from the command line that can, for example, dump its data out on the console or something, i.e. to test DDC once the port is definitely in TMDS mode.

              Or is there any way to manually shove a mode or an EDID down the thing's throat without having to go the xrandr route (so that the initial mode is appropriate)?

              Comment


              • #87
                Originally posted by curaga View Post
                Based on this discussion, is it right that in current radeon it's not possible to run a screen without edid?

                ie. faulty connectors, some KVM switches, old screens.

                If so, maybe add a force option?
                You can already force most connectors (VGA, DVI, HDMI), but you can't force DP since it requires a transaction between the monitor and card to bring up the link. I suppose we could just assume non-DP if we can't communicate with the DP monitor.

                Comment


                • #88
                  Originally posted by agd5f View Post
                  I suppose we could just assume non-DP if we can't communicate with the DP monitor.
                  I think that would be a useful option.

                  Comment


                  • #89
                    Originally posted by droidhacker View Post
                    As for fglrx detecting the sink type as DP and using that to determine connected state... I suspect that it would report sink type as DP even with nothing plugged in at all (will test this tonight).
                    That's the problem. It should only report a DP sink type if a DP monitor is actually attached. Something in the connector is wired wrong. All of my DP cards report non-DP sink type by default (if nothing is connected or if a non-DP monitor is attached).

                    Originally posted by droidhacker View Post
                    Just remember that DP and DVI use the AUX/DDC pins in a completely different way. In DP, the AUX channel pins are arranged in AUX channel + and -, and the clock signal is embedded in the data. In the case of DVI, the AUX+ is used as DDC clock, and AUX- is used as DDC data... so if the port is in DP mode, DDC will not work and you don't get EDID.
                    Should be fixed with this patch:

                    However, in practice, this seems to have worked even when the pads were in DP mode.

                    Originally posted by droidhacker View Post
                    In any case, I have confirmed beyond any doubt that it is detecting the sink as DP, however even ignoring this, I am still unable to probe ddc, so I am still without EDID.
                    Try with the patch above.

                    Originally posted by droidhacker View Post
                    I suspect that the reason for this is that a DDC probe won't work unless the port is in TMDS mode, but the port is in DP mode every time that function is called.
                    Actually the pad mode, see above.

                    Originally posted by droidhacker View Post
                    Is there any way to perform a DDC probe *AFTER* the display is already online?
                    The i2c lines are exposed via sysfs so you can probe then with various sw tools.

                    Comment


                    • #90
                      Originally posted by agd5f View Post
                      That's the problem. It should only report a DP sink type if a DP monitor is actually attached. Something in the connector is wired wrong. All of my DP cards report non-DP sink type by default (if nothing is connected or if a non-DP monitor is attached).
                      There's no question that something is wired wrong

                      [/quote]Should be fixed with this patch:

                      However, in practice, this seems to have worked even when the pads were in DP mode.

                      Try with the patch above.

                      Actually the pad mode, see above.[/quote]
                      Wow. You definitely have an answer for everything.
                      I'll try that out tonight.

                      pad mode... I guess then that the overall state of the connector can be put into a weird mode where it is a hybrid of DVI and DP?

                      Now... the bios technically should post to the DP monitor, which means that there is some setup happening in vbios stage that, in the case where it is wired wrong, sets those pads in AUX mode. When they're set that way, presumably, they are STUCK that way until it is explicitly changed. So is it a possibility that when NOT explicitly setting the pads into DDC mode, the reason it typically still works is because the vbios already did it and/or it simply defaults that way when stuff isn't wired wrong?

                      The i2c lines are exposed via sysfs so you can probe then with various sw tools.
                      I just found something that does it... program called ddccontrol. On my computer here at work, which is a radeon with DVI and HDMI ports driving a pair of DVI monitors, it finds EDIDs for both monitors. Checked mine remotely, still only finds the one. So I'm crossing my fingers for it being in hybrid-confused mode.

                      Guess I'll see if your patch does the job.. otherwise I might just modify the for loop in radeon_add_common_modes and take out the first two if's. That should at least get me native resolution kms, which will at least make it functional for me.

                      ** In the event that your patch doesn't work on account of this thing just being too badly wired, it would be neat to be able to get some manual control over some of these settings without having to resort to one-off kernel hacks. I.e. radeon.forceDPDVI=1 and radeon.maxCommonMode=x,y would make some useful kernel arguments.

                      Comment

                      Working...
                      X