From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762840AbdAEQUI (ORCPT ); Thu, 5 Jan 2017 11:20:08 -0500 Received: from mx2.suse.de ([195.135.220.15]:54829 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751920AbdAEQUA (ORCPT ); Thu, 5 Jan 2017 11:20:00 -0500 Date: Thu, 05 Jan 2017 17:19:58 +0100 Message-ID: From: Takashi Iwai To: Ville =?UTF-8?B?U3lyasOkbMOk?= Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: VT switch broken with docking station DP In-Reply-To: <20170105155931.GT31595@intel.com> References: <20170105155931.GT31595@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 05 Jan 2017 16:59:31 +0100, Ville Syrjälä wrote: > > 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 2why 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. Hrm, so that's my misunderstanding. The problem is that it tries to assign to 1368x768 resolution for DP while the fb is 1366x768... Sounds familiar? Takashi