From patchwork Mon Jul 10 14:41:21 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Takashi Iwai X-Patchwork-Id: 9833127 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3076160363 for ; Mon, 10 Jul 2017 14:41:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 15F8D1FF26 for ; Mon, 10 Jul 2017 14:41:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 06EDE285AF; Mon, 10 Jul 2017 14:41:27 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 1262E2859E for ; Mon, 10 Jul 2017 14:41:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9B6806E155; Mon, 10 Jul 2017 14:41:24 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by gabe.freedesktop.org (Postfix) with ESMTPS id BB80B6E155 for ; Mon, 10 Jul 2017 14:41:23 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 553E8AB09; Mon, 10 Jul 2017 14:41:22 +0000 (UTC) Date: Mon, 10 Jul 2017 16:41:21 +0200 Message-ID: From: Takashi Iwai To: Gerd Hoffmann Subject: Re: VT console blank ignored by DRM drivers on QEMU In-Reply-To: <1499687277.23551.15.camel@redhat.com> References: <1499687277.23551.15.camel@redhat.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.2 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Cc: Alexander Graf , dri-devel , Bartlomiej Zolnierkiewicz X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP On Mon, 10 Jul 2017 13:47:57 +0200, Gerd Hoffmann wrote: > > Hi, > > > But aside from that, can't we just teach these drivers to properly do > > dpms? With the atomic framework dpms is implement as simply turning > > the screen off, any driver should be able to support that properly. > > Well, the virtual hardware simply has no dpms support, except maybe for > cirrus which mimics physical hardware. > > bochs could toggle the blank bit in vga register space. > > virtio and qxl could unmap the plane, but that might have unwanted > effects on the host side because qemu thinks the guest turned off the > display altogether. > > > For the fbcon issue, can we perhaps just unconditionally ask fbcon to > > clear the screen when blanking? It's not really perf critical, so > > doing that for everyone shouldn't hurt. > > Sounds good to me. > > I've seen this on real hardware too btw (arm board with non-working > dpms). So something like below? (Adding Bartlomiej to Cc, as it's fbcon stuff) Takashi -- 8< -- From: Takashi Iwai Subject: [PATCH] fbcon: Perform generic blank unconditionally Currently fbcon performs the manual clearance of console as a fallback only when fb_blank() returns an error. Unfortunately, all DRM fbcons running on QEMU don't return the error but only adjust the non-working DPMS, we end up just having the frozen screen upon blank call. Also Gerd suggested that a similar issue could have seen on the bare metal, too. As a simple workaround suggested by Daniel, let's call fbcon_generic_blank() unconditionally at fbcon_blank() so that it always clears the console. Suggested-by: Daniel Vetter Cc: Gerd Hoffmann Cc: Alexander Graf Signed-off-by: Takashi Iwai --- drivers/video/console/fbcon.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index 12ded23f1aaf..65169a5a1bca 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -2347,8 +2347,8 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch) ops->cursor_flash = (!blank); if (!(info->flags & FBINFO_MISC_USEREVENT)) - if (fb_blank(info, blank)) - fbcon_generic_blank(vc, info, blank); + fb_blank(info, blank); + fbcon_generic_blank(vc, info, blank); } if (!blank)