Bug 1044118

Addendum: When i go to the "Activities Screen" the desktop looks perfectly ok. It remains ok even on the "desktop" as long as i don't move / close / resize any window. As soon as any action is performed on a window the desktop switches back to the strange white background showing all sorts of effects.

I think i've found the source of the problem. My default desktop size is 2560x1440 on the iMac Screen. This seems to cause a problem with all gnome backgrounds (even the simple color ones).

I've switched to 1600x1200, set the background and changed back to 2560x1440 and now all seems to be good.

* changed the compontents to gnome-backgrounds although it might also not be the correct one.

cheers
udo

This is biting me every time I turn on the VM, I don't think is related to the deskop size, mine is 1680x1050.

When I turn it on the background does not redraw corrcetly and it's completely white, the only way to fix it, just as Udo mentioned, is to lower the resolution and then revert the change.

cheers

A little update, looks like it only happens if you boot fedora while VMWare is already fullscreen, Udo can you confirm this behavior?

Mario,
yes, confirmed. When booting up in window mode the desktop behaves normally.

Seems fedora/x11/gnome are having problems with osx fullscreen mode. This started to happen with f20. i did not notice that on f19. i don't remember if i had the original VMWare tools installed on f19 or if they were the fedora/oss provided vmware-tools. i think it was the former.

Crazy things also happen when switching from fullscreen mode to windowed mode. Before rebooting my guest i was looged on in fullscreen mode. I switched to window mode. when resizing the window from there the guy behaves like it only sees part of the screen with the show widgets staying the same size wheres i would expect the screen to somehow scale acc. to the size of the window.

cheers
udo

Hi, im having this problem too, and since all my work machine is under fedora I'm not having the best work days since i updated. Does anyone have filled a bug with vmware? if not i think it could help too

Hi, i am also suffering from the same problem. But changing the resolution does not fix the problem for me. The problem occurs in my primary display of lenovo W530. But my extended second display is OK. The xrandr output is as follows;

LVDS-1 connected primary 1600x900+0+180 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080      60.0 +   60.0     50.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      59.9  
   1280x960       59.9  
   1152x864       60.0  
   1024x768       59.9  
   800x600        59.9  
   640x480        59.4  
   720x400        59.6  
   640x400        60.0  
   640x350        59.8  
   1600x900_60    60.0* 
VGA-1 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 480mm x 270mm
   1920x1080      60.0*+
   1680x1050      60.0  
   1400x1050      60.0  
   1600x900       60.0  
   1280x1024      75.0     60.0  
   1440x900       59.9  
   1280x800       59.8  
   1152x864       75.0  
   1280x720       60.0  
   1024x768       75.1     60.0  
   832x624        74.6  
   800x600        75.0     60.3     56.2  
   640x480        75.0     60.0  
   720x400        70.1

(In reply to Kemal Kaplan from comment #7)

After some further investigation, i found that this behaviour happens when i am using nouveau video driver. The lspci and lsmod outputs are as follows;

---

...~]$lspci | grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro K1000M] (rev a1)

---

...~]$ lsmod | grep video
uvcvideo               80968  0 
videobuf2_vmalloc      13163  1 uvcvideo
videobuf2_memops       13161  1 videobuf2_vmalloc
videobuf2_core         38938  1 uvcvideo
videodev              133350  2 uvcvideo,videobuf2_core
media                  20840  2 uvcvideo,videodev
i2c_core               38476  6 drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
video                  19206  1 nouveau

I can cofirm the bug too:

Host:
HW: Lenovo Workstation C30 model 10954M5
OS: Windows 7 64bit
VMWare Workstation 10.0.1 build 1379776

Guest: 
OS: Fedora 20 64bit with all latest updates, GNOME desktop, open-vm-tools 9.4.0

Switching from full screen mode to windowed mode and back helps.

Hi,

 as this bug seems to not make it out of the NEW status despite being confirmed by different people on different setups i'd like to know what the problem is.

Is it that nobody is interested in solving it, that the maintainer is not interested in bug-reports at all or that you simply don't really care as much for your users as some of your communications on forums and the webpage might suggest. i'm not expecting any instant feedback as you are possibly all working on your spare time for this project, but no official comment on the bug up to now really makes me wonder.

cheers
Udo

This was filed under gnome-backgrounds, which is the package containing the desktop wallpaper images. Assigning to xorg-x11-drv-vmware.

Its unlikely to be the guest driver causing the problem, so its probably a host driver issue, I'd report it upstream to the nouveau project if everyone who sees it is using the nouveau driver.

I'm not sure we'll get much traction to fix this here, since vmware is closed source.

any news?

I thought this might be related to Bug 1077453. I downgraded mesa-libxatracker-devel and friends to 9.x which allowed me to build a more recent xorg-x11-drv-vmware package, but it didn't help. I can verify that with the newer package the acceleration is enabled, but the background corruption and general sluggishness persists.

$ sudo yum downgrade  mesa-libxatracker llvm-libs mesa-dri-drivers xorg-x11-drv-vmware mesa-libxatracker-devel

Then I grabbed the srcrpm and built from a more recent version:
[dvhart@localhost SPECS]$ diff xorg-x11-drv-vmware.spec.orig xorg-x11-drv-vmware.spec
4,5c4,5
< %define gitdate 20131207
< %define gitversion a40cbd7b
---
> %define gitdate 20140115
> %define gitversion 8da981712f62050076cff53e1b40ed1e307fcca8

After installing that version, accel is enabled:

[    16.567] (II) vmware(0): Initialized VMWARE_CTRL extension version 0.2
[    16.578] (II) vmware(0): Gallium3D XA version: 1.0.0.
[    16.579] (II) vmware(0): Path of drm device is "/dev/dri/card0".
[    16.579] (II) vmware(0): [DRI2] Setup complete
[    16.579] (II) vmware(0): [DRI2]   DRI driver: vmwgfx
[    16.579] (--) vmware(0): Render acceleration is enabled.
[    16.579] (==) vmware(0): Rendercheck mode is disabled.
[    16.579] (--) vmware(0): Direct rendering (3D) is enabled.
[    16.579] (==) vmware(0): Direct presents are disabled.
[    16.579] (==) vmware(0): Hardware only presents are disabled.
[    16.579] (==) vmware(0): Backing store disabled
[    16.579] (==) vmware(0): Silken mouse enabled
[    16.579] (II) vmware(0): RandR 1.2 enabled, ignore the following RandR disabled message.

But, as stated, bug persists :-(

Building 13.0.2 of xorg-x11-drv-vmware with the same mesa-libxatracker-devel downgrade doesn't help either.

My host is Windows 7 Ultimate and I'm experiencing the exact same when running Fedora 20 in both VMware Workstation 9.0.1 and VMware Workstation 10.0.2

Most interestingly: I see the exact same issue (although not to this extend) when running Ubuntu 13.10 in VMware Workstation !

The workaround for me is also the same as others already noticed:
Switching from full screen mode to window mode and then back to full screen mode fixes this problem.

Can confirm here as well:

Host: Mac OS X 10.9.3
VM App: VMWare Fusion 6.0.3
Image: Fedora x86 64 20

In window mode I get the redraw issues, but in full screen the issue doesn't appear. Moving back and forth seems to remedy the issue.

FWIW: No such problems with Ubuntu on the same Machine.

i doubt that this really is an issue of the vmware driver as outline earlier.
Problem did also not happen with F19

Hi,

My problem turns out to be a desktop management conflict between KDE and GNOME.
After erasing all KDE and MATE packages, my GNOME desktop starts to work as expected. Hope it helps.

Regards...


(In reply to Kemal Kaplan from comment #8)
> (In reply to Kemal Kaplan from comment #7)
> 
> After some further investigation, i found that this behaviour happens when i
> am using nouveau video driver. The lspci and lsmod outputs are as follows;
> 
> ---
> 
> ...~]$lspci | grep VGA
> 01:00.0 VGA compatible controller: NVIDIA Corporation GK107GLM [Quadro
> K1000M] (rev a1)
> 
> ---
> 
> ...~]$ lsmod | grep video
> uvcvideo               80968  0 
> videobuf2_vmalloc      13163  1 uvcvideo
> videobuf2_memops       13161  1 videobuf2_vmalloc
> videobuf2_core         38938  1 uvcvideo
> videodev              133350  2 uvcvideo,videobuf2_core
> media                  20840  2 uvcvideo,videodev
> i2c_core               38476  6
> drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau,videodev
> video                  19206  1 nouveau

Removing Open VM Tools with:-

rpm -e open-vm-tools open-vm-tools-desktop

Doing a reboot, then installing the VMWare tools provided by VMWare fusion and doing another reboot fixed the issue for me.

This problem is not specific to Fusion - it also happens under VMWare Workstation 10 under Windows.

The problem seems to be in the X driver - I'm running:

xorg-x11-drv-vmware.x86_64                13.0.2-4.20140613git82c9b0c.fc20

removing that rpm, and running VESA mode drivers, I don't see any problems.

I'm using xfce for a desktop.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Why would anybody try to reproduce this bug under a later version if no one tried to fix it under the reported version. This is simply a complete waste of time.