From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937148AbdAEP7l (ORCPT ); Thu, 5 Jan 2017 10:59:41 -0500 Received: from mga06.intel.com ([134.134.136.31]:4647 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932903AbdAEP7f (ORCPT ); Thu, 5 Jan 2017 10:59:35 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,322,1477983600"; d="scan'208";a="26584387" Date: Thu, 5 Jan 2017 17:59:31 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Takashi Iwai Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: VT switch broken with docking station DP Message-ID: <20170105155931.GT31595@intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 05, 2017 at 04:37:27PM +0100, Takashi Iwai wrote: > Hi, > > recently I noticed that VT console doesn't work any longer when I dock > a Dell E7270 laptop with a DP monitor. The bug detail is like this: > > At first, I boot the laptop without dock. I can switch between X and > VT via ctrl-alt-F1, so far. Then I dock it to a docking station > connected with a DP monitor. Now, when I switch to VT, it behaves as > if frozen, the X graphics screen remains. But actually it's only > graphics and the keyboard input is processed in VT. I can go back to > X via alt-F7 again. The situation remains until I undock and I kill X > once. > > After looking more deeply at drm debug log, I found out that it's > caused by the drm atomic check. Essentially, it's because eDP has the > lower resolution (1366x768) than DP (1920x1080). Since booting with > eDP, the frame buffer size is 1366x768. Then it hits the following > check in drm_atomic_plane_check(): > > fb_width = state->fb->width << 16; > fb_height = state->fb->height << 16; > > /* Make sure source coordinates are inside the fb. */ > if (state->src_w > fb_width || > state->src_x > fb_width - state->src_w || > state->src_h > fb_height || > state->src_y > fb_height - state->src_h) { > DRM_DEBUG_ATOMIC("Invalid source coordinates " > "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n", > state->src_w >> 16, ((state->src_w & 0xffff) * 15625) >> 10, > state->src_h >> 16, ((state->src_h & 0xffff) * 15625) >> 10, > state->src_x >> 16, ((state->src_x & 0xffff) * 15625) >> 10, > state->src_y >> 16, ((state->src_y & 0xffff) * 15625) >> 10); > return -ENOSPC; > } > > Actually after commenting out "return -ENOSPC", VT switch works fine. > > But the code above made me wonder what's the requirement here. IIRC, > the VT always worked on a display with a higher resolution even if the > frame buffer is smaller. Only a part of display was used, but it was > OK, far better than the frozen graphics :) > > Can we simply drop this check, or may we add a flag to skip it for VT > switching? Or any better idea? Find out why it didn't allocate a big enough framebuffer to begin with, or alternatively why it tried to specify source coordinates exceeding the fb dimensions. There is clearly a bug somewhere, just not here. -- Ville Syrjälä Intel OTC