From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: Fix broken VT switch with video=1366x768 option
Date: Tue, 10 Jan 2017 13:28:36 +0200 [thread overview]
Message-ID: <20170110112836.GZ31595@intel.com> (raw)
In-Reply-To: <20170109145614.29454-1-tiwai@suse.de>
On Mon, Jan 09, 2017 at 03:56:14PM +0100, Takashi Iwai wrote:
> 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...")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Takashi Iwai <tiwai@suse.de>
> ---
> drivers/gpu/drm/drm_modes.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac6a35212501..e6b19bc9021a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -1460,6 +1460,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);
> + }
Maybe give fixup_mode_1366x768() a drm_ prefix and make in non-static to
avoid duplicating the code? And I guess move it to drm_modes.c?
Otherwise lgtm:
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
> return mode;
> }
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2017-01-10 11:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-09 14:56 [PATCH] drm: Fix broken VT switch with video=1366x768 option Takashi Iwai
2017-01-09 14:56 ` Takashi Iwai
2017-01-10 11:28 ` Ville Syrjälä [this message]
2017-01-10 11:36 ` Takashi Iwai
2017-01-10 12:41 ` Daniel Vetter
2017-01-10 12:41 ` Daniel Vetter
2017-01-10 12:45 ` Takashi Iwai
2017-01-10 12:45 ` Takashi Iwai
2017-01-11 17:05 ` Ville Syrjälä
2017-01-11 17:05 ` Ville Syrjälä
2017-01-11 18:46 ` Takashi Iwai
2017-01-11 18:46 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170110112836.GZ31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.