Page 11 of 11 FirstFirst ... 91011
Results 101 to 108 of 108

Thread: 890GX/HD4290 dual display question

  1. #101
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,578

    Default

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

  2. #102
    Join Date
    Dec 2007
    Posts
    2,337

    Default

    Quote 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.

    Quote 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.).

  3. #103
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote 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++.

  4. #104
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    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

  5. #105
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    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;
    }

  6. #106
    Join Date
    Dec 2007
    Posts
    2,337

    Default

    Quote 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

  7. #107
    Join Date
    Oct 2009
    Posts
    2,081

    Default

    Quote 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

  8. #108
    Join Date
    Oct 2009
    Posts
    2,081

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •