Announcement

Collapse
No announcement yet.

890GX/HD4290 dual display question

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

  • Or maybe 'D'? I'd at least think DisplayPort was a digital output.

    Comment


    • Originally posted by droidhacker View Post
      I feel special


      That would be the goodness
      You think that the "e" option (output forced to ON) would take care of the "connected" state?

      If it would, could be fixed to, or an additional option added to, then that, along with setting a sensible default sink_type would bring this broken board into a manual-but-usable state... i.e.
      video=DisplayPort-0:1920x1200@60e
      Yeah, I think that should do it.

      Originally posted by droidhacker View Post
      Is it *possible* that DP does NOT require the AUX channel to operate? One line in the 780 document you linked to somewhat implies that it may not be required... in section 1.2.12 on page 1-8, it says "Supports the Auxilary Channel (AUX CH)", which is presented as a FEATURE. If it was a hard requirement, why would it be presented as a feature?
      AUX is required for DP since you need AUX to communicate with the monitor (get the EDID, DPCD, train the link, etc.).

      Comment


      • Originally posted by agd5f View Post
        Yeah, I think that should do it.
        About this patch:
        http://lists.freedesktop.org/archive...st/003139.html

        Wouldn't it be better to do this:

        Code:
        diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c
        index 20c353c..31a09cd 100644
        --- a/drivers/gpu/drm/radeon/radeon_connectors.c
        +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
        @@ -977,24 +977,25 @@ static enum drm_connector_status radeon_dp_detect(struct drm_connector *connecto
         	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
         	enum drm_connector_status ret = connector_status_disconnected;
         	struct radeon_connector_atom_dig *radeon_dig_connector = radeon_connector->con_priv;
        -	u8 sink_type;
         
         	if (radeon_connector->edid) {
         		kfree(radeon_connector->edid);
         		radeon_connector->edid = NULL;
         	}
         
        -	sink_type = radeon_dp_getsinktype(radeon_connector);
        -	if ((sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) ||
        -	    (sink_type == CONNECTOR_OBJECT_ID_eDP)) {
        -		if (radeon_dp_getdpcd(radeon_connector)) {
        -			radeon_dig_connector->dp_sink_type = sink_type;
        +	if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
        +		/* eDP is always DP */
        +		radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DISPLAYPORT;
        +		if (radeon_dp_getdpcd(radeon_connector))
         			ret = connector_status_connected;
        -		}
         	} else {
        -		if (radeon_ddc_probe(radeon_connector)) {
        -			radeon_dig_connector->dp_sink_type = sink_type;
        -			ret = connector_status_connected;
        +		radeon_dig_connector->dp_sink_type = radeon_dp_getsinktype(radeon_connector);
        +		if (radeon_dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) {
        +			if (radeon_dp_getdpcd(radeon_connector))
        +				ret = connector_status_connected;
        +			else {
        +				radeon_dig_connector->dp_sink_type = CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_D;
        +				if (radeon_ddc_probe(radeon_connector))
        +					ret = connector_status_connected;
        +			}
        +		} else {
        +			if (radeon_ddc_probe(radeon_connector))
        +				ret = connector_status_connected;
         		}
         	}
        It wouldn't break anything since we already know that the DP CAN'T work, but would leave it in a state where it would work with certain boards that are wired wrong by at least setting a sensible default state.

        I know it is a workaround for one special case defect, but I wonder how many people are suffering with this (or similar) defects and are resigned to it being broken?

        I also note that there are quite a number of workarounds elsewhere that deal with specific board defects, i.e. in radeon_atombios.c function radeon_atom_apply_quirks(), so it wouldn't even be unprecedented to add a workaround for a specific defect.

        In this case though, the workaround would compensate for a class of defects that *could* be present on ANY DP board where the OEM didn't properly plan for supporting DP++.

        Comment


        • I'm fairly certain that I found some nastys in drivers/gpu/drm/drm_modes.c

          In the function drm_cvt_mode(), when parameter "reduced" is set to TRUE, the hsync_start and hsync_end values calculated are... wrong, and the vsync_start and vsync_end values aren't calculated at all.

          This is when compared to the values calculated by the "cvt" command, i.e.
          cvt -r 1920 1200
          # 1920x1200 59.95 Hz (CVT 2.30MA-R) hsync: 74.04 kHz; pclk: 154.00 MHz
          Modeline "1920x1200R" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync

          The values generated by drm_cvt_mode(dev,1920,1200,60,true,false,false) are:
          154.00 1920 32 32 2080 1200 0 0 1235 +hsync -vsync

          Comment


          • For anyone interested, for now (might look at the cvt algo later), I've jigged in my mode like this;

            Code:
            static int radeon_dp_get_modes(struct drm_connector *connector)
            {
            	struct radeon_connector *radeon_connector = to_radeon_connector(connector);
            	int ret;
            	struct drm_display_mode *mode = NULL;
            	struct drm_device *dev = radeon_connector->base.dev;
            
            	ret = radeon_ddc_get_modes(radeon_connector);
            	//mode = drm_cvt_mode(dev, 1920, 1200, 60, true, false, false);
            	if (mode = drm_mode_create(dev)){
            		mode->hdisplay=1920;
            		mode->vdisplay=1200;
            		mode->vtotal=1235;
            		mode->htotal=2080;
            		mode->hsync_end=2000;
            		mode->hsync_start=1968;
            		mode->vsync_start=1203;
            		mode->vsync_end=1209;
            		mode->clock=154000;
            		drm_mode_set_name(mode);
            		mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC);
            	}
            
            	drm_mode_probed_add(connector, mode);
            	return ret;
            }

            Comment


            • Originally posted by droidhacker View Post
              I'm fairly certain that I found some nastys in drivers/gpu/drm/drm_modes.c

              In the function drm_cvt_mode(), when parameter "reduced" is set to TRUE, the hsync_start and hsync_end values calculated are... wrong, and the vsync_start and vsync_end values aren't calculated at all.

              This is when compared to the values calculated by the "cvt" command, i.e.
              cvt -r 1920 1200
              # 1920x1200 59.95 Hz (CVT 2.30MA-R) hsync: 74.04 kHz; pclk: 154.00 MHz
              Modeline "1920x1200R" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync -vsync

              The values generated by drm_cvt_mode(dev,1920,1200,60,true,false,false) are:
              154.00 1920 32 32 2080 1200 0 0 1235 +hsync -vsync
              That should be fixed. Please file a bug at http://bugzilla.kernel.org or https://bugs.freedesktop.org

              Comment


              • Originally posted by agd5f View Post
                That should be fixed. Please file a bug at http://bugzilla.kernel.org or https://bugs.freedesktop.org
                https://bugzilla.kernel.org/show_bug.cgi?id=16651

                Comment


                • Well, that bug's been squashed.
                  http://lists.freedesktop.org/archive...st/003223.html

                  Comment

                  Working...
                  X