From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: VT switch broken with docking station DP Date: Thu, 5 Jan 2017 18:47:06 +0200 Message-ID: <20170105164706.GU31595@intel.com> References: <20170105155931.GT31595@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by gabe.freedesktop.org (Postfix) with ESMTPS id AEB166E8C5 for ; Thu, 5 Jan 2017 16:47:30 +0000 (UTC) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Takashi Iwai Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org T24gVGh1LCBKYW4gMDUsIDIwMTcgYXQgMDU6MTk6NThQTSArMDEwMCwgVGFrYXNoaSBJd2FpIHdy b3RlOgo+IE9uIFRodSwgMDUgSmFuIDIwMTcgMTY6NTk6MzEgKzAxMDAsCj4gVmlsbGUgU3lyasOk bMOkIHdyb3RlOgo+ID4gCj4gPiBPbiBUaHUsIEphbiAwNSwgMjAxNyBhdCAwNDozNzoyN1BNICsw MTAwLCBUYWthc2hpIEl3YWkgd3JvdGU6Cj4gPiA+IEhpLAo+ID4gPiAKPiA+ID4gcmVjZW50bHkg SSBub3RpY2VkIHRoYXQgVlQgY29uc29sZSBkb2Vzbid0IHdvcmsgYW55IGxvbmdlciB3aGVuIEkg ZG9jawo+ID4gPiBhIERlbGwgRTcyNzAgbGFwdG9wIHdpdGggYSBEUCBtb25pdG9yLiAgVGhlIGJ1 ZyBkZXRhaWwgaXMgbGlrZSB0aGlzOgo+ID4gPiAKPiA+ID4gQXQgZmlyc3QsIEkgYm9vdCB0aGUg bGFwdG9wIHdpdGhvdXQgZG9jay4gIEkgY2FuIHN3aXRjaCBiZXR3ZWVuIFggYW5kCj4gPiA+IFZU IHZpYSBjdHJsLWFsdC1GMSwgc28gZmFyLiAgVGhlbiBJIGRvY2sgaXQgdG8gYSBkb2NraW5nIHN0 YXRpb24KPiA+ID4gY29ubmVjdGVkIHdpdGggYSBEUCBtb25pdG9yLiAgTm93LCB3aGVuIEkgc3dp dGNoIHRvIFZULCBpdCBiZWhhdmVzIGFzCj4gPiA+IGlmIGZyb3plbiwgdGhlIFggZ3JhcGhpY3Mg c2NyZWVuIHJlbWFpbnMuICBCdXQgYWN0dWFsbHkgaXQncyBvbmx5Cj4gPiA+IGdyYXBoaWNzIGFu ZCB0aGUga2V5Ym9hcmQgaW5wdXQgaXMgcHJvY2Vzc2VkIGluIFZULiAgSSBjYW4gZ28gYmFjayB0 bwo+ID4gPiBYIHZpYSBhbHQtRjcgYWdhaW4uICBUaGUgc2l0dWF0aW9uIHJlbWFpbnMgdW50aWwg SSB1bmRvY2sgYW5kIEkga2lsbCBYCj4gPiA+IG9uY2UuCj4gPiA+IAo+ID4gPiBBZnRlciBsb29r aW5nIG1vcmUgZGVlcGx5IGF0IGRybSBkZWJ1ZyBsb2csIEkgZm91bmQgb3V0IHRoYXQgaXQncwo+ ID4gPiBjYXVzZWQgYnkgdGhlIGRybSBhdG9taWMgY2hlY2suICBFc3NlbnRpYWxseSwgaXQncyBi ZWNhdXNlIGVEUCBoYXMgdGhlCj4gPiA+IGxvd2VyIHJlc29sdXRpb24gKDEzNjZ4NzY4KSB0aGFu IERQICgxOTIweDEwODApLiAgU2luY2UgYm9vdGluZyB3aXRoCj4gPiA+IGVEUCwgdGhlIGZyYW1l IGJ1ZmZlciBzaXplIGlzIDEzNjZ4NzY4LiAgVGhlbiBpdCBoaXRzIHRoZSBmb2xsb3dpbmcKPiA+ ID4gY2hlY2sgaW4gZHJtX2F0b21pY19wbGFuZV9jaGVjaygpOgo+ID4gPiAKPiA+ID4gCWZiX3dp ZHRoID0gc3RhdGUtPmZiLT53aWR0aCA8PCAxNjsKPiA+ID4gCWZiX2hlaWdodCA9IHN0YXRlLT5m Yi0+aGVpZ2h0IDw8IDE2Owo+ID4gPiAKPiA+ID4gCS8qIE1ha2Ugc3VyZSBzb3VyY2UgY29vcmRp bmF0ZXMgYXJlIGluc2lkZSB0aGUgZmIuICovCj4gPiA+IAlpZiAoc3RhdGUtPnNyY193ID4gZmJf d2lkdGggfHwKPiA+ID4gCSAgICBzdGF0ZS0+c3JjX3ggPiBmYl93aWR0aCAtIHN0YXRlLT5zcmNf dyB8fAo+ID4gPiAJICAgIHN0YXRlLT5zcmNfaCA+IGZiX2hlaWdodCB8fAo+ID4gPiAJICAgIHN0 YXRlLT5zcmNfeSA+IGZiX2hlaWdodCAtIHN0YXRlLT5zcmNfaCkgewo+ID4gPiAJCURSTV9ERUJV R19BVE9NSUMoIkludmFsaWQgc291cmNlIGNvb3JkaW5hdGVzICIKPiA+ID4gCQkJCSAiJXUuJTA2 dXgldS4lMDZ1KyV1LiUwNnUrJXUuJTA2dVxuIiwKPiA+ID4gCQkJCSBzdGF0ZS0+c3JjX3cgPj4g MTYsICgoc3RhdGUtPnNyY193ICYgMHhmZmZmKSAqIDE1NjI1KSA+PiAxMCwKPiA+ID4gCQkJCSBz dGF0ZS0+c3JjX2ggPj4gMTYsICgoc3RhdGUtPnNyY19oICYgMHhmZmZmKSAqIDE1NjI1KSA+PiAx MCwKPiA+ID4gCQkJCSBzdGF0ZS0+c3JjX3ggPj4gMTYsICgoc3RhdGUtPnNyY194ICYgMHhmZmZm KSAqIDE1NjI1KSA+PiAxMCwKPiA+ID4gCQkJCSBzdGF0ZS0+c3JjX3kgPj4gMTYsICgoc3RhdGUt PnNyY195ICYgMHhmZmZmKSAqIDE1NjI1KSA+PiAxMCk7Cj4gPiA+IAkJcmV0dXJuIC1FTk9TUEM7 Cj4gPiA+IAl9Cj4gPiA+IAo+ID4gPiBBY3R1YWxseSBhZnRlciBjb21tZW50aW5nIG91dCAicmV0 dXJuIC1FTk9TUEMiLCBWVCBzd2l0Y2ggd29ya3MgZmluZS4KPiA+ID4gCj4gPiA+IEJ1dCB0aGUg Y29kZSBhYm92ZSBtYWRlIG1lIHdvbmRlciB3aGF0J3MgdGhlIHJlcXVpcmVtZW50IGhlcmUuICBJ SVJDLAo+ID4gPiB0aGUgVlQgYWx3YXlzIHdvcmtlZCBvbiBhIGRpc3BsYXkgd2l0aCBhIGhpZ2hl ciByZXNvbHV0aW9uIGV2ZW4gaWYgdGhlCj4gPiA+IGZyYW1lIGJ1ZmZlciBpcyBzbWFsbGVyLiAg T25seSBhIHBhcnQgb2YgZGlzcGxheSB3YXMgdXNlZCwgYnV0IGl0IHdhcwo+ID4gPiBPSywgZmFy IGJldHRlciB0aGFuIHRoZSBmcm96ZW4gZ3JhcGhpY3MgOikKPiA+ID4gCj4gPiA+IENhbiB3ZSBz aW1wbHkgZHJvcCB0aGlzIGNoZWNrLCBvciBtYXkgd2UgYWRkIGEgZmxhZyB0byBza2lwIGl0IGZv ciBWVAo+ID4gPiBzd2l0Y2hpbmc/ICBPciBhbnkgYmV0dGVyIGlkZWE/Cj4gPiAKPiA+IEZpbmQg b3V0IDJ3aHkgaXQgZGlkbid0IGFsbG9jYXRlIGEgYmlnIGVub3VnaCBmcmFtZWJ1ZmZlciB0byBi ZWdpbiB3aXRoLAo+ID4gb3IgYWx0ZXJuYXRpdmVseSB3aHkgaXQgdHJpZWQgdG8gc3BlY2lmeSBz b3VyY2UgY29vcmRpbmF0ZXMgZXhjZWVkaW5nCj4gPiB0aGUgZmIgZGltZW5zaW9ucy4KPiA+IAo+ ID4gVGhlcmUgaXMgY2xlYXJseSBhIGJ1ZyBzb21ld2hlcmUsIGp1c3Qgbm90IGhlcmUuCj4gCj4g SHJtLCBzbyB0aGF0J3MgbXkgbWlzdW5kZXJzdGFuZGluZy4gIFRoZSBwcm9ibGVtIGlzIHRoYXQg aXQgdHJpZXMgdG8KPiBhc3NpZ24gdG8gMTM2OHg3NjggcmVzb2x1dGlvbiBmb3IgRFAgd2hpbGUg dGhlIGZiIGlzIDEzNjZ4NzY4Li4uCj4gU291bmRzIGZhbWlsaWFyPwoKTm90IHJlYWxseS4gU291 bmRzIGxpa2UgdGhlcmUncyBhIGJ1ZyBpbiB0aGUgZmIgaGVscGVyIHNvbWV3aGVyZSB0aGF0IGl0 CnRyaWVzIHRvIGFkZCBuZXcgY29ubmVjdG9ycyB0byB0aGUgbWl4IHdpdGhvdXQgY2hlY2tpbmcg dGhhdCB0aGUgZmIgaXMKYmlnIGVub3VnaCBmb3Igd2hhdGV2ZXIgbW9kZXMgYXJlIHN1cHBvcnRl ZCBvbiBzYWlkIGNvbm5lY3RvcnMuCgpBcyBmYXIgYXMgdGhlIDEzNjYgdnMuIDEzNjggdGhpbmcg Z29lcywgd2UgaGF2ZSBxdWlya3MgaW4gdGhlIEVESUQKcGFyc2VyIHRvIGNvbnZlcnQgMTM2OCB0 byAxMzY2IHdpdGggdGhlIGFzc3VtcHRpb24gdGhhdCAxMzY2IGlzIHdoYXQKdGhleSByZWFsbHkg bWVhbnQuIFRoZSByZWFzb24gZm9yIHRoZSBxdWlyayBiZWluZyB0aGF0IEVESUQgY2FuJ3QKYWN0 dWFsbHkgc2F5IDEzNjYgc2luY2UgaXQncyBub3QgYSBtdWx0aXBsZSBvZiA4LiBJdCBtaWdodCBi ZQppbnRlcmVzdGluZyB0byBrbm93IHdoZXJlIHRoYXQgMTM2OCBtb2RlIGNhbWUgZnJvbSBhbmQg d2h5IHRoZSBxdWlyawpkaWRuJ3QgY29udmVydCBpdCB0byAxMzY2LiBCdXQgZXZlbiBmaXhpbmcg dGhhdCBwYXJ0IChhc3N1bWluZyB0aGVyZSdzCnNvbWV0aGluZyB0byBmaXgpIGRvZXNuJ3QgcmVh bGx5IGV4Y3VzZSB0aGUgZmFjdCB0aGF0IHRoZSBmYiBoZWxwZXIKcGlja2VkIGEgcmVzb2x1dGlv biBmb3IgdGhlIGNvbm5lY3RvciB0aGF0IGRvZXNuJ3QgZml0IGluIHRoZSBmYi4KCi0tIApWaWxs ZSBTeXJqw6Rsw6QKSW50ZWwgT1RDCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCmRyaS1kZXZlbCBtYWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVk ZXNrdG9wLm9yZwpodHRwczovL2xpc3RzLmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752661AbdAEQtD (ORCPT ); Thu, 5 Jan 2017 11:49:03 -0500 Received: from mga09.intel.com ([134.134.136.24]:32093 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762846AbdAEQro (ORCPT ); Thu, 5 Jan 2017 11:47:44 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,322,1477983600"; d="scan'208";a="1090334143" Date: Thu, 5 Jan 2017 18:47:06 +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: <20170105164706.GU31595@intel.com> References: <20170105155931.GT31595@intel.com> 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 05:19:58PM +0100, Takashi Iwai wrote: > 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? Not really. Sounds like there's a bug in the fb helper somewhere that it tries to add new connectors to the mix without checking that the fb is big enough for whatever modes are supported on said connectors. As far as the 1366 vs. 1368 thing goes, we have quirks in the EDID parser to convert 1368 to 1366 with the assumption that 1366 is what they really meant. The reason for the quirk being that EDID can't actually say 1366 since it's not a multiple of 8. It might be interesting to know where that 1368 mode came from and why the quirk didn't convert it to 1366. But even fixing that part (assuming there's something to fix) doesn't really excuse the fact that the fb helper picked a resolution for the connector that doesn't fit in the fb. -- Ville Syrjälä Intel OTC