On Mon, Jul 10, 2017 at 1:47 PM, Gerd Hoffmann <kraxel@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
