+27
−7
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
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 3fbd6439 ("drm: copy mode type in drm_mode_connector_list_update()") commit abce1ec9 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"") It was then decided in commit b87577b7 ("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
CRA Git | Maintained and supported by SUSTech CRA and CCSE