On Mon, Jul 10, 2017 at 10:53 AM, Takashi Iwai <tiwai@xxxxxxx> wrote: > 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. DPMS should be an error anyway, we want that to be able to properly thread the acquire_ctx EDEADLK backoff stuff through that we need for atomic. That would be the best long-term plan I think. 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. 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. -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
