Bug 36189

Maybe it would be nice If you can specify your environment more - used components and their versions (spice-server, spice client, video driver, agent (?), hypervisor, guest...).
I am not able to hit that so far.

(In reply to comment #1)
> Maybe it would be nice If you can specify your environment more - used
> components and their versions (spice-server, spice client, video driver, agent
> (?), hypervisor, guest...).
> I am not able to hit that so far.

Sorry about the delay in responding as I was traveling.

Host and client OS (identical installations of OS but different hardware): OpenSuse 11.4 
Host with KVM 0.14

Guest OS: Windows XP SP3

spice-client-0.8.1
spice-server-0.8.1

qxl compiled from the latest stable in the repository

There is one positive check I want to do tomorrow - to eliminate Compiz as the Window Manager being the problem - and report.

> There is one positive check I want to do tomorrow - to eliminate Compiz as the
> Window Manager being the problem - and report.

There was a bug related to fullscreen mode in Compiz but should be fixed in versions you are using, but if you can eliminate Compiz and retest that will be nice. Thanks.

(In reply to comment #3)
> > There is one positive check I want to do tomorrow - to eliminate Compiz as the
> > Window Manager being the problem - and report.
> 
> There was a bug related to fullscreen mode in Compiz but should be fixed in
> versions you are using, but if you can eliminate Compiz and retest that will be
> nice. Thanks.

I can confirm that this problem is independent of Compiz.

It seems to be related to use of auto-conf (or rather not using it) for full-screen. If spice client has --full-screen=auto-conf, then there is no problem as long as vdagent is setup properly and starts correctly.

If either vdagent is not available OR vdagent is running fine and I start a spice client without the auto-conf option (e.g., just using -f option) and the guest resolution is different from the client screen resolution, I get a dark screen. There is no signal coming to the monitor since the monitor will go off to sleep if left like  that. Programs are running behind it and you can hear any audio sounds. If I click Ctrl+Alt+FN (N may vary for different distros or Xorg setup) to go to another X screen and come back, then the display appears and things work well after that. If the guest resolution and the client screen resolution are the same, then I have no problem with just the -f option.

It is like the "monitor didn't turn on" for the guest in the above scenario where the resolutions are different. With auto-conf on, whatever happens in that handshake, turns the monitor on (metaphorically speaking, of course not to be taken literally). If the resolutions match then, "the monitor is turned on".

I can reproduce this consistently now.

(In reply to comment #4)
> (In reply to comment #3)
> > > There is one positive check I want to do tomorrow - to eliminate Compiz as the
> > > Window Manager being the problem - and report.
> > 
> > There was a bug related to fullscreen mode in Compiz but should be fixed in
> > versions you are using, but if you can eliminate Compiz and retest that will be
> > nice. Thanks.
> 
> I can confirm that this problem is independent of Compiz.
> 
> It seems to be related to use of auto-conf (or rather not using it) for
> full-screen. If spice client has --full-screen=auto-conf, then there is no
> problem as long as vdagent is setup properly and starts correctly.
> 
> If either vdagent is not available OR vdagent is running fine and I start a
> spice client without the auto-conf option (e.g., just using -f option) and the
> guest resolution is different from the client screen resolution, I get a dark
> screen. There is no signal coming to the monitor since the monitor will go off
> to sleep if left like  that. Programs are running behind it and you can hear
> any audio sounds. If I click Ctrl+Alt+FN (N may vary for different distros or
> Xorg setup) to go to another X screen and come back, then the display appears
> and things work well after that. If the guest resolution and the client screen
> resolution are the same, then I have no problem with just the -f option.
> 
> It is like the "monitor didn't turn on" for the guest in the above scenario
> where the resolutions are different. With auto-conf on, whatever happens in
> that handshake, turns the monitor on (metaphorically speaking, of course not to
> be taken literally). If the resolutions match then, "the monitor is turned on".
> 
> I can reproduce this consistently now.

I am not able to reproduce that, anything in ~/.spicec/spicec.log or ~/.spice-vdagent/log ? Maybe you could attach your compiled qxl driver and I can retest with it on my set up.

Created attachment 46843 [details]
Local compiled qxl driver for Windows XP

Comment on attachment 46843 [details]
Local compiled qxl driver for Windows XP


> I am not able to reproduce that, anything in ~/.spicec/spicec.log or
> ~/.spice-vdagent/log ? Maybe you could attach your compiled qxl driver and I
> can retest with it on my set up.

I did the following tests to look at spicec.log

Windows XP SP3 guests without vdagent available (since the problem occurs with both vdagent and without, decided to simplify the test case)

Test 1:

Guest OS monitor resolution set to 1280x800 while host has 1920x1080.
Spicec started with -f switch on the host. Goes to blank screen. 

The spicec log is at

http://pastebin.com/c4Fgiter

Toggling X screens with Ctrl+ALT+Fn keys shows the display.

Test 2:

Start spicec again without the -f flag. The display comes up properly in a window.

The log is identical to the one above without the enter-full-screen line at the beginning and the last two lines are switched (the insecure keyboard channel warning comes up before the DisplayChannel log entry).

Test 3:

Set Guest OS monitor resolution to 1920x1080 the same as the host and started spicec with the -f flag

The full-screen display comes up correctly. Log is the same as test 1 with the last two lines switched as in test 2

Test 4:
While spicec is up in Test 3 in full screen, change Windows display setting to 1280x800. Screen goes blank.

If I do the X screen toggle, I can get the display back with Windows display setting waiting for confirmation of new resolution. If I just wait, the Guest screen goes back to original resolution while spicec is still blank (since the Windows display setting reverts back without confirmation). I can get the display with the XScreen toggle.

In the spicec log there is a create_sw_canvas line for each time a resolution change is made (the last line in the log pasted above) and nothing more.

I have attached the qxl driver I am using locally compiled here.

Finally I can reproduce that problem quite easily on F15, just like you described. Can anyone have a look at that? 
I downgraded qemu to different verions of 0.14 and downgraded spice components to 0.8.0 and 0.7.3 and It still occurs.

But I can see in client log repeated msg:

1307975593 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189902
1307975594 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189903
1307975683 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189940
1307975684 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189941
1307975684 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189942
1307975685 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189943
1307975686 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189944
1307975687 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189945
1307975687 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189946
1307975688 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189947
1307975689 INFO [8976:8976] MultyMonScreen::MultyMonScreen: platform_win: 155189948
.
.
.

Even I do not have any multimonitor, only one screen of my laptop.

Hmm I'm seeing a similar bug, but I'm not sure it's the same. Basically we have a bunch of different bugs with similar symptoms, which makes it difficult to figure out which one is which. Some are fixed in git master, some are not. I'm seeing something similar here by running spicec with no --fullscreen, but I switch to fullscreen once spicec runs windowed using shift+f11, and I get a black screen too, which I can only leave after playing with ctrl+alt+f1/f2/... Might be the same bug...

spicec is deprecated.

If you hit this bug, we highly recommended virt-viewer

http://virt-manager.org/download/
http://www.spice-space.org/download.html