I have tried this with both 0.6 and 0.8 versions of Spice on OpenSuse 11.4 Starting spice client with -f (on the host itself) almost always makes the screen black out. Programs are running behind but the screen is blacked out. Using Compiz as window manager. Most of the time (but not all), doing a Ctrl+Alt+F5 (to go into TTY5 mode) and Ctrl+Alt+F7 in succession displays the screen correctly. VNC full screen has no such problem so I am not sure this is a window manager problem. It is not a full screen window that is black (in which case, it should be possible to rotate to other desktops) but X itself seems stuck. It is the most problematic, it seems when the guest resolution is close to the host resolution I can have the guest resolution in a lower resolution (say 800x600) and running full screen seems to work reliably and I can then change the resolution of the guest to the host resolution with no problems to get the full display occupied. But if I restart the spice client with that resolution and full screen, the screen goes blank. There is no problem starting this in windowed mode at any resolution on the guest (including much higher resolution than the host display). Sometimes toggling to full screen from windowed mode works correctly at the host resolution but not always. Do let me know what additional information I can provide or try out to narrow the problem.
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.