VT console blank ignored by DRM drivers on QEMU

Daniel Vetter daniel at ffwll.ch
Mon Jul 10 14:54:55 UTC 2017


On Mon, Jul 10, 2017 at 1:47 PM, Gerd Hoffmann <kraxel at redhat.com> 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.

dpms off = turn screen off, except keep some of the resources reserved
to be able to guarantee that you can switch it on again. There is no
difference in behaviour, and I think it'd be the right thing for
virtual screens too. Well there's the mild problem of you can't wiggle
the mouse anymore to wake it up I guess, but from a drm api pov
there's really not supposed to be a difference in behaviour.

>> 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).

Atomic drivers _all_ have working dpms, because atomic simply remaps
that to "everything off". DPMS is purely a legacy thing to keep
existing userspace happy. And it's useful for suspend/resume, to keep
resources reserved and guarantee we can resume.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch


More information about the dri-devel mailing list