-spice port=3000,password=123456,addr=0,image-compression=auto_glz,zlib-glz-wan-compression=auto,streaming-video=all,agent-mouse=on,playback-compression=on,ipv4

-vga qxl -global qxl-vga.vram_size=33554432


This exists when using spice/qxl too

Hmm?  Screenshots look perfectly fine to me.  Text lines fill the left side of the screen only because they are much shorter than the screen width allows.

(In reply to Gerd Hoffmann from comment #3)
> Hmm?  Screenshots look perfectly fine to me.  Text lines fill the left side
> of the screen only because they are much shorter than the screen width
> allows.

Hi Gerd,

then why after pressing any key, the guest screen continue to update all area ?
when it stops rendering all area, the screen snapshot looked like guest hang,
then our autotest would treat guest die, which impacted our automated test. :-(

Ah, you mean screenshots 120-129.  Didn't notice them last time I looked at the issue.  I suspect it is something in drmfb.  Adding Dave.

There have been a bunch of drm updates to the kernel since.  Can you retest please?  Which vga cards are affected?  qxl?  cirrus?  std?

Created attachment 852980 [details]
logs

    -vga std  \
has different look, the screen is completely black after a while.

screen going completely black is the screen saver.  Tapping any key should wake it up and make it display the normal screen again.

Could be the screen saver doesn't work properly with drmfb.  That would also explain why it starts behaving normal again after tapping a key.  Is the idle time the same (for screen saver on stdvga and broken display on cirrus/qxl)?

The screen blanking can be configured with the setterm utility (-blank and -powersave options, see man page).  Not sure setterm is on the anaconda install image, but you could try turning off screen blanking in the kickstart %pre section and see if that helps.

Ok, so we have a solution for the screensaver-disturbs-autotest issue.

Still worth investigating why the screen blanking doesn't work correctly with qxldrmfb and cirrusdrmfb.  Screen should go completely blank like it does in text mode (when using qemu stdvga).  Not critical enough to justify fixing in 7.0 though.

(In reply to Gerd Hoffmann from comment #14)
> Ok, so we have a solution for the screensaver-disturbs-autotest issue.
> 
> Still worth investigating why the screen blanking doesn't work correctly
> with qxldrmfb and cirrusdrmfb.  Screen should go completely blank like it
> does in text mode (when using qemu stdvga).  Not critical enough to justify
> fixing in 7.0 though.

Moving to 7.4.

btw: seeing this on physical hardware (arm boards) too.  Seems to happen when console blanking doesn't put the monitor into powersave mode.  Or, to be correct, it probably happens all the time but with the monitor in powersave mode you don't notice b/c you can't see it ...

(In reply to Gerd Hoffmann from comment #16)
> (In reply to Gerd Hoffmann from comment #14)
> > Ok, so we have a solution for the screensaver-disturbs-autotest issue.
> > 
> > Still worth investigating why the screen blanking doesn't work correctly
> > with qxldrmfb and cirrusdrmfb.  Screen should go completely blank like it
> > does in text mode (when using qemu stdvga).  Not critical enough to justify
> > fixing in 7.0 though.
> 
> Moving to 7.4.
> 
> btw: seeing this on physical hardware (arm boards) too.  Seems to happen
> when console blanking doesn't put the monitor into powersave mode.  Or, to
> be correct, it probably happens all the time but with the monitor in
> powersave mode you don't notice b/c you can't see it ...

Yep, drmfb (drm_fb_helper_blank) just tries to puts the monitor into suspend mode.  Framebuffer content is not touched, so it remains visible in case putting the monitor at suspend doesn't work, either because there is no physical monitor in the first place (virtual hardware), or because dpms isn't working properly (probably the case on the arm board where I saw this too).

No easy way out.  Just clearing the framebuffer isn't going to work because we can't easily restore the content on unblank.  We could try do something special for virtual hardware instead of using the generic drm_fb helper function.  Not sure this is worth the trouble for this cosmetic thing.

For the original issue (autotest checking screen for updates) blanking should be turned off anyway, no matter whenever it works correctly or not ...

So, bottom line, I'm inclined to close this as wontfix.  Objections?

> So, bottom line, I'm inclined to close this as wontfix.  Objections?

Done now.