dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alexander Graf <agraf@suse.de>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: VT console blank ignored by DRM drivers on QEMU
Date: Mon, 10 Jul 2017 16:41:21 +0200	[thread overview]
Message-ID: <s5hmv8c2w32.wl-tiwai@suse.de> (raw)
In-Reply-To: <1499687277.23551.15.camel@redhat.com>

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 <tiwai@suse.de>
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 <daniel@ffwll.ch>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Alexander Graf <agraf@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 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)
-- 
2.13.2

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2017-07-10 14:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  8:53 VT console blank ignored by DRM drivers on QEMU Takashi Iwai
2017-07-10  9:27 ` Daniel Vetter
2017-07-10  9:37   ` Takashi Iwai
2017-07-10  9:49     ` Alexander Graf
2017-07-10 14:56     ` Daniel Vetter
2017-07-11 17:35       ` Daniel Vetter
2017-07-11 18:10         ` Takashi Iwai
2017-07-11 20:36           ` Daniel Vetter
2017-07-10 11:47   ` Gerd Hoffmann
2017-07-10 14:41     ` Takashi Iwai [this message]
2017-07-10 14:57       ` Daniel Vetter
2017-07-10 20:08       ` [PATCH] fbcon: Perform generic blank unconditionally kbuild test robot
2017-07-10 14:54     ` VT console blank ignored by DRM drivers on QEMU Daniel Vetter

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=s5hmv8c2w32.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=agraf@suse.de \
    --cc=b.zolnierkie@samsung.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox