summaryrefslogtreecommitdiffstats
path: root/include
diff options
context:
space:
mode:
authorVille Syrjälä2015-12-04 14:13:01 +0100
committerDaniel Vetter2015-12-11 09:27:07 +0100
commitfc245f88039cc52859841bde9b81a7d3b7cd8b5a (patch)
treec08f197e0a09ba3fced1cb000f9418d262b04f91 /include
parentdrm: Flatten drm_mode_connector_list_update() a bit (diff)
downloadkernel-qcow2-linux-fc245f88039cc52859841bde9b81a7d3b7cd8b5a.tar.gz
kernel-qcow2-linux-fc245f88039cc52859841bde9b81a7d3b7cd8b5a.tar.xz
kernel-qcow2-linux-fc245f88039cc52859841bde9b81a7d3b7cd8b5a.zip
drm: Only merge mode type bits between new probed modes
Currently most drivers request that any mode appearing on both the old mode list and the new probed_modes list get their type bits ORed together if the modes are deemed to otherwise match each other. I don't know why anyone would want to merge in the mode type bits from any mode left over from a previous probe. For instance, you could never get rid of ther preferred bit if a matching non-preferred mode is returned by the new probe. So let's not merge anything from the stale old modes, and just replace them outright with matching new modes. If multiple matching modes are produced by the same probe, merging the type bits between them would seem like a sensible thing to do. For a bit of extra finesse if two modes are considered equal we can pick the actual timings from the one marked as preferrred. And if multiple preferred modes are produced by the same probe somehow, we can just favor the first one added to the probed_modes list. You may be asking yourself why we bother with the merging at all if nothing from the old list survives in practice. The only answer I have is "debug output". That is we want to print out a list of pruned modes, which is why we still want to look for duplicates with the old modes. There was a previous attempt to get rid of the mode type merging entirely, but it caused some kind of regression on Daniels's G33 machine. Apparently the sdvo transcoder on said machine started to die at around the same time and has since rotted away totally, so it may have been a red herring. So we don't have to worry about it anymore. The relevant commits are: commit 3fbd6439e463 ("drm: copy mode type in drm_mode_connector_list_update()") commit abce1ec9b08a ("Revert "drm: copy mode type in drm_mode_connector_list_update()"") It was then decided in commit b87577b7c768 ("drm: try harder to avoid regression when merging mode bits") that just qxl virtio are excluded from the merging, while everyone else does it. That is not changed, although now even qxl and virtio will be subject to the previously mentioned logic to choose which actual timings are picked for the new mode. v2: Fix typos in commit message, and clarify the details on the G33 regression from the previous attempt (Daniel) Cc: Marc-André Lureau <marcandre.lureau@redhat.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Adam Jackson <ajax@redhat.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449234781-22332-1-git-send-email-ville.syrjala@linux.intel.com
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions