Some month's ago I could switch from my laptops native resolution 1024x768 to 800x600 or 640x480. The gpu or panel would do the scaling. Recently this is no longer possible. The edid only contains the native 1024x768 resolution and the log no longer mentions checking the modes from the builtin modepool. The lower resolutions were quite useful for some games and videos. danny
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.