Bug 19203

Have you updated the xserver recently?  I could believe http://cgit.freedesktop.org/xorg/xserver/commit/?id=81fd17f5f49cdd2c10d0bf3b7ddeb8b5953886a5 "Only add default modes if EDID supports continuous-frequency" might have this effect.

As far as nouveau ddx changes go, the scaling code was last touched on Aug 16-17th in 8a364682fd67c10c153cb0778c914a4754e82ddd and  4cbbd44db614d250fdaaf648db2d70ec9bc2f6d9 if you want to try going back to a previous version (though admittedly there could be unintentional subsequent breakage)

I saw that commit, but thought my checkout was older than that. Today i checked. It is not. I checked my EDID and byte 0x18 reads 0A, and thus misses the gtf bit.

I'm not sure if GTF support equals "continuous frequency", but still i would like a solution for this problem. Is there any other way we can check if a screen supports more than just the preferred mode? 

Perhaps the commit is too restricting, I imagine it would fix the bugs if it didn't try to put screens in higher resolutions than the supported ones, but still left it possible to use lower resolutions.

danny

maybe something like this can be done for nouveau as well?

http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg36976.html


danny

Created attachment 21734 [details] [review]
hacky patch

here's a bodge that should fix the immediate problem. I'm tempted to wait and see what the intel guys ultimately come up with in bug 19247 before committing anything

It's a bit too dodgy. For some reason it messes up the edid completely, leading to random modes and eventually the server stops. I post the logs later.

d.

Created attachment 21806 [details]
Xorg log

This log file shows the errors after applying above patch. Haven:t really researcher what is happening.

d.

OK, patch does not work because xf86OutputSetEDID has already been called once, and the edid got applied to the output. Calling it again will not change the current edid, but seems to add another one. Doing;
        if (nv_connector->edid)
                nv_connector->edid->features.msc |= 0x1;
in edid_sink_connected instead (before the firstxf86OutputSetEDID) seems to work fine.

d.

problem is due to xf86OutputSetEDID freeing the previously set xf86MonPtr, which is also the one we're trying to set (again):

if (output->MonInfo != NULL)
  xfree(output->MonInfo);
output->MonInfo = edid_mon;

I'd really prefer to not drag the EDID alteration into the detect path, since at that stage there's no encoder type set.  What if you defeat the above NULL check by adding "output->MonInfo = NULL;" just before the call to xf86OutputSetEDID in munge_edid_for_scaler?

Created attachment 22643 [details]
hack in detect path

Created attachment 22644 [details]
vanilla, without hack

Created attachment 22645 [details]
hack with workaround that NULLs MonInfo

Last few comments logs for each situation.

The hack doesn't seem to work because a new entry seems to be created which has the msc bit set. But this entry is not for the current panel.

d.

Created attachment 22692 [details] [review]
New patch without multiple OutputSetEDID calls

Bizarre, I've no idea why the previous patch didn't work.  From the attached logs it even look like it did.  Here's a new patch taking a different and possibly better approach though.  If this one doesn't work, please make logs with `Option "ModeDebug" "on"' set in the xorg.conf.

30848dd378d05917c646a24df404846e6f9b2352