I'm running Gentoo Linux under VMware Player 4.0.2 build-591240 on Windows XP. Guest is running: kernel 3.2.5 (provides vmwgfx 2.3.0.0) mesa-8.0 (build with gallium and xatracker enabled) xf86-video-vmware from today git (so I got xatracker-based driver) xorg-server-1.11.4 Everything works perfectly and I'm able to get accelerated OpenGL. However, if I lock host screen (Win+L) and unlock it, I got guest screen corrupted and unusable. I've checked following situations: 1) vmwgfx kenel module loaded, Xorg isn't started - works fine 2) vmwgfx kenel module loaded with enable_fbdev, Xorg isn't started - works fine 3) vmwgfx kenel module loaded, Xorg is working and is on screen - FAIL 4) vmwgfx kenel module loaded, Xorg is working and VT on screen - FAIL 5) vmwgfx kenel module loaded with enable_fbdev, Xorg is working and is on screen - FAIL 6) vmwgfx kenel module loaded with enable_fbdev, Xorg is working and VT on screen - FAIL So for me look like something isn't reinitialized correctly in xorg driver after host screen is unlocked. Only possible way to fix screen corruption is to shutdown/kill X server. VT is redrawn correctly in few seconds. I'll be glad to provide any other information/backtraces/debug outputs if needed.
This is a known bug and is in the host. The problem is that the host discards the guest screen contents when the window is hidden, and has no way to tell the guest to redraw it. There is one thing that is a bit weird, the fact that it works "enable_fbdev" (2), are you sure that fbcon is running? Is the guest window size 800x600 or is the VGA mode as seen in (1)? Cheers, Jakob.
From what you're saying looks like there is no way to fix this. Is it possible to add some kind of workaround? For example, switching to/from VT should force full screen redraw. In my company I must lock screen when I leave my workplace; this issue makes 3D-acceleration unusable for me.
I've just retested case 2 (vmwgfx kenel module loaded with enable_fbdev, Xorg isn't started - works fine). I confirm that fbcon is loaded, and console is switched to graphics mode: Console: switching to colour frame buffer device 100x37 And yes, host screen locking doesn't cause any problems.
Thanks for retesting (2), its a bit odd tho as it should be broken as well. Does cases (3-6) work if 3D is disabled, or is it always broken (just need to test one case 5). One workaround is VT switching the guest from and back to the Xorg session, that should redraw the screen. On linux hosts you need escape the switch sequence with ctrl+alt+space (release only space) then press f1 and then do the same but pressing f7 instead of f1. Might be needed on WinXp hosts not sure. I hope that helps. Unfortunately host bugs take a lot longer to get to out. I'll try and at least revisit this bug when I have time to spend on it and see if anything can be done, leaving it open for now. Cheers, Jakob.
Jakob, Cases 3-6 are always broken. Switching to VT and back to Xorg doesn't help; this is main problem. Moreover, VT is also corrupted (even in VGA mode). I found only two ways to restore guest screen: 1) Restart Xorg (unacceptable :) 2) Suspend/resume virtual machine - takes too much time. That is why I'm thinking that current xatracker-based xf86-video-vmware should have some workaround like forced full screen redraw on enterVT/leaveVT.
(In reply to comment #5) > Jakob, > > Cases 3-6 are always broken. > > Switching to VT and back to Xorg doesn't help; this is main problem. > > Moreover, VT is also corrupted (even in VGA mode). VGA mode being broken sounds very bad, can you post a screenshot? If you interact with the VT does it eventually get better (VGA or fbdev)? > > I found only two ways to restore guest screen: > > 1) Restart Xorg (unacceptable :) > 2) Suspend/resume virtual machine - takes too much time. Understandable. > > That is why I'm thinking that current xatracker-based xf86-video-vmware should > have some workaround like forced full screen redraw on enterVT/leaveVT. It should do this already if not it that should be fixed. Btw are you running a 3D compositor (like compiz, gnome-shell, kwin)? Cheers, Jakob.
(In reply to comment #6) > > Cases 3-6 are always broken. > > > > Switching to VT and back to Xorg doesn't help; this is main problem. > > > > Moreover, VT is also corrupted (even in VGA mode). > > VGA mode being broken sounds very bad, can you post a screenshot? Sure, I will do that tomorrow > If you interact with the VT does it eventually get better (VGA or fbdev)? Unfortunately no, I've tried everything :( > > That is why I'm thinking that current xatracker-based xf86-video-vmware should > > have some workaround like forced full screen redraw on enterVT/leaveVT. > > It should do this already if not it that should be fixed. Btw are you running a > 3D compositor (like compiz, gnome-shell, kwin)? I've tried both ways: either I start KDE4.8 session or just twm and xterm - always same problem.
Created attachment 57577 [details] Xorg screen, xatracker enable driver is used; before host screen lock
Created attachment 57578 [details] 02: Switch from Xorg to VT; before host screen lock
Created attachment 57579 [details] 03: VT after host screen-lock. Image you see is my host wallpaper
Retested with Mesa-8.0.1: nothing changed.
Retested with xf86-video-vmware-1.12.0.1 - problem still occurs. I've also tried to see how things will go with xf86-video-modesetting, but it looks like vmwgfx kernel drm module doesn't support some features needed.
Retested with xf86-video-vmware-1.12.0.2, Mesa-8.0.2 and kernel-3.2.12: problem still present
This looks like it is a host issue unfortunately, when you suspend and resume a WinXp host all of the 3D contexts goes away for Workstation. Applications are suposed to re-upload all the assets. We can't do that, since that would involve either doing the same on the guest and adding support to all guest applications to re-upload or hold a copy of all the assets in memory. The one thing I don't know is if WinXp does this on screen-lock, as I can't test that but I'm guessing it does, if it doesn't this a bug within workstation and that could be fixed. Later Windows doesn't have this limitation, but I'm guessing your employer only allows WinXp. Cheers, Jakob.
Yeah, now I see :( Looks like this issue can't be resolved. I've found more or less deep explanation of what's going on here: http://www.virtualdub.org/blog/pivot/entry.php?id=269 Probably, you can change status to resolved/won't fix
Thanks for the link, Sorry this couldn't be fixed. :-/
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.