dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: dri-devel@lists.freedesktop.org
Cc: Gerd Hoffmann <kraxel@redhat.com>, Alexander Graf <agraf@suse.de>
Subject: VT console blank ignored by DRM drivers on QEMU
Date: Mon, 10 Jul 2017 10:53:51 +0200	[thread overview]
Message-ID: <s5hpod84qqo.wl-tiwai@suse.de> (raw)

Hi,

we've casually found a weird behavior of DRM drivers on QEMU (cirrus,
bochs, virtio) via openQA: namely, VT console blank is ignored on such
drivers.  The whole screen is kept shown while the cursor blinking
stops.

I took a closer look, and it seems that drm_fb_helper_blank() just
calls drm_fb_helper_dpms(), by a naive assumption that every driver
properly implements DPMS handling.  Meanwhile bochs driver has a
code to ignore the whole DPMS hilariously.  Ditto for virtio.

(The cirrus is a bit different story; it has a DPMS implementation,
 but QEMU side seems ignoring it.)

In the fbcon side, there is a fallback to the explicit clear when the
fb_blank() returns an error, so we should be able to handle it if we
return an error properly.  But the dpms callback is a void function,
so the driver doesn't tell it for now.


I guess we have several options to address it.  An easy one would be
to provide an own fb_blank function for returning an error and use it
for the drivers for VM.  The driver can't use any longer
DRM_FB_HELPER_DEFAULT_OPS, thus it'll a bit ugly, though.

Another is to change dpms callback allowing to return an error.  But
it'd affect so many codes.

Yet another option would be to define some flag and let
drm_fb_helper_blank() returns an error.  But I also hesitate to do it
just for such a workaround.


Any suggestions?


thanks,

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

             reply	other threads:[~2017-07-10  8:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-10  8:53 Takashi Iwai [this message]
2017-07-10  9:27 ` VT console blank ignored by DRM drivers on QEMU 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
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=s5hpod84qqo.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=agraf@suse.de \
    --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