]>
Commit | Line | Data |
---|---|---|
377e81b2 GKH |
1 | From fdf35a6b22247746a7053fc764d04218a9306f82 Mon Sep 17 00:00:00 2001 |
2 | From: Takashi Iwai <tiwai@suse.de> | |
3 | Date: Mon, 9 Jan 2017 15:56:14 +0100 | |
4 | Subject: drm: Fix broken VT switch with video=1366x768 option | |
5 | MIME-Version: 1.0 | |
6 | Content-Type: text/plain; charset=UTF-8 | |
7 | Content-Transfer-Encoding: 8bit | |
8 | ||
9 | From: Takashi Iwai <tiwai@suse.de> | |
10 | ||
11 | commit fdf35a6b22247746a7053fc764d04218a9306f82 upstream. | |
12 | ||
13 | I noticed that the VT switch doesn't work any longer with a Dell | |
14 | laptop with 1366x768 eDP when the machine is connected with a DP | |
15 | monitor. It behaves as if VT were switched, but the graphics remain | |
16 | frozen. Actually the keyboard works, so I could switch back to VT7 | |
17 | again. | |
18 | ||
19 | I tried to track down the problem, and encountered a long story until | |
20 | we reach to this error: | |
21 | ||
22 | - The machine is booted with video=1366x768 option (the distro | |
23 | installer seems to add it as default). | |
24 | - Recently, drm_helper_probe_single_connector_modes() deals with | |
25 | cmdline modes, and it tries to create a new mode when no | |
26 | matching mode is found. | |
27 | - The drm_mode_create_from_cmdline_mode() creates a mode based on | |
28 | either CVT of GFT according to the given cmdline mode; in our case, | |
29 | it's 1366x768. | |
30 | - Since both CVT and GFT can't express the width 1366 due to | |
31 | alignment, the resultant mode becomes 1368x768, slightly larger than | |
32 | the given size. | |
33 | - Later on, the atomic commit is performed, and in | |
34 | drm_atomic_check_only(), the size of each plane is checked. | |
35 | - The size check of 1366x768 fails due to the above, and eventually | |
36 | the whole VT switch fails. | |
37 | ||
38 | Back in the history, we've had a manual fix-up of 1368x768 in various | |
39 | places via c09dedb7a50e ("drm/edid: Add a workaround for 1366x768 HD | |
40 | panel"), but they have been all in drm_edid.c at probing the modes | |
41 | from EDID. For addressing the problem above, we need a similar hack | |
42 | to the mode newly created from cmdline, manually adjusting the width | |
43 | when the expected size is 1366 while we get 1368 instead. | |
44 | ||
45 | Fixes: eaf99c749d43 ("drm: Perform cmdline mode parsing during...") | |
46 | Signed-off-by: Takashi Iwai <tiwai@suse.de> | |
47 | Link: http://patchwork.freedesktop.org/patch/msgid/20170109145614.29454-1-tiwai@suse.de | |
48 | Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> | |
49 | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> | |
50 | Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> | |
51 | ||
52 | --- | |
53 | drivers/gpu/drm/drm_modes.c | 7 +++++++ | |
54 | 1 file changed, 7 insertions(+) | |
55 | ||
56 | --- a/drivers/gpu/drm/drm_modes.c | |
57 | +++ b/drivers/gpu/drm/drm_modes.c | |
58 | @@ -1401,6 +1401,13 @@ drm_mode_create_from_cmdline_mode(struct | |
59 | return NULL; | |
60 | ||
61 | mode->type |= DRM_MODE_TYPE_USERDEF; | |
62 | + /* fix up 1368x768: GFT/CVT can't express 1366 width due to alignment */ | |
63 | + if (cmd->xres == 1366 && mode->hdisplay == 1368) { | |
64 | + mode->hdisplay = 1366; | |
65 | + mode->hsync_start--; | |
66 | + mode->hsync_end--; | |
67 | + drm_mode_set_name(mode); | |
68 | + } | |
69 | drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V); | |
70 | return mode; | |
71 | } |