Hide Forgot
Created attachment 837939 [details] Screenshot showing a full screen shot of the iMac VMWare display Description of problem: After installing Fedora 20 in a VMWare Fusion virtual machine and logging on the desktop looks broken in a way that the graphics are not drawn correctly. All Windows draw multiple edges and instead of the selected desktop wallpaper i see a white background. Most of the windows show a very small blue edge like the desktop background is below the white background. I am assuming it's a driver problem although i'm not sure. No configuration change has been done towards display/resolution/.... Its a clean install from the f20 release iso plus the first round of updates. Problem is persistent accross reboots. The problem has only come up with F20, F19 showed no such effects Version-Release number of selected component (if applicable): N/A How reproducible: No special steps needed. As soon as i log on the display shows that behaviour Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Correct desktop display.44 Additional info:
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.