diff options
author | Takashi Iwai <tiwai@suse.de> | 2017-01-09 14:56:14 (GMT) |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2017-02-01 07:33:02 (GMT) |
commit | f1dc9aaee02950e95cc045209d9bf07955bc16d8 (patch) | |
tree | e604fa0f304406befb7f5574cf1f3995eb0e0fb0 /drivers | |
parent | 2abb7f408f7cfb9af9218e74507f5f44af154302 (diff) | |
download | linux-f1dc9aaee02950e95cc045209d9bf07955bc16d8.tar.xz |
drm: Fix broken VT switch with video=1366x768 option
commit fdf35a6b22247746a7053fc764d04218a9306f82 upstream.
I noticed that the VT switch doesn't work any longer with a Dell
laptop with 1366x768 eDP when the machine is connected with a DP
monitor. It behaves as if VT were switched, but the graphics remain
frozen. Actually the keyboard works, so I could switch back to VT7
again.
I tried to track down the problem, and encountered a long story until
we reach to this error:
- The machine is booted with video=1366x768 option (the distro
installer seems to add it as default).
- Recently, drm_helper_probe_single_connector_modes() deals with
cmdline modes, and it tries to create a new mode when no
matching mode is found.
- The drm_mode_create_from_cmdline_mode() creates a mode based on
either CVT of GFT according to the given cmdline mode; in our case,
it's 1366x768.
- Since both CVT and GFT can't express the width 1366 due to
alignment, the resultant mode becomes 1368x768, slightly larger than
the given size.
- Later on, the atomic commit is performed, and in
drm_atomic_check_only(), the size of each plane is checked.
- The size check of 1366x768 fails due to the above, and eventually
the whole VT switch fails.
Back in the history, we've had a manual fix-up of 1368x768 in various
places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD
panel"), but they have been all in drm_edid.c at probing the modes
from EDID. For addressing the problem above, we need a similar hack
to the mode newly created from cmdline, manually adjusting the width
when the expected size is 1366 while we get 1368 instead.
Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.de
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/gpu/drm/drm_modes.c | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 53f07ac..e14366d 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1462,6 +1462,13 @@ drm_mode_create_from_cmdline_mode(struct drm_device *dev, return NULL; mode->type |= DRM_MODE_TYPE_USERDEF; + /* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */ + if (cmd->xres == 1366 && mode->hdisplay == 1368) { + mode->hdisplay = 1366; + mode->hsync_start--; + mode->hsync_end--; + drm_mode_set_name(mode); + } drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V); return mode; } |