Remember in the (archaics) old days of Windows 98, when it booted, the Windows logo would become all funny looking? This is now happening when I run Vmware. I can't fix it unless I restart Xorg.
I'd like to know if I can do something about it. I can'y find nothing about it, probably because I don't know how to search with proper terms to describe this.
Thanks.
Last edited by tecknojunky on Tue Jan 11, 2005 3:28 am, edited 1 time in total.
(7 of 9) Installing star-trek/species-8.4.7.2::talax.
I have the same problem. The only way I've found to fix it is to Ctrl-Alt-F1 out to console, then Alt-F7 back.
Odd part is I tried to take a screenshot of my own to show the corruption and the weirdness doesn't show up with either Gimp or scrot!
I'm running the fglrx 3.14.6 drivers on my ATI 9800 Pro, and am currently in BigHead (3200x1200) mode.
I also have both a vesa-tng framebuffer AND fbsplash bootsplash going on behind my KDE session.
Haven't tried turning anything off yet...anyone get rid of this annoying problem?
J0rus wrote:Odd part is I tried to take a screenshot of my own to show the corruption and the weirdness doesn't show up with either Gimp or scrot!
Gee, I just took a look at my screenshot I had link in my first post. It showed quite right and ok. I removed the link. It seem you can't screenshot it.
(7 of 9) Installing star-trek/species-8.4.7.2::talax.
This is not really a solution to your problem, but I found that starting gmplayer obviously restores whatever went wrong, this used to work for me with vmware and console switching.
Since I'm using the radeon drivers instread of fglrx everythings fine, though. Apart from no accelerartion being available, that is...
I haven't done any kind of investigation on what causes this, but I have discovered after uninstalling the gensplash features, that this palette problem no longer occurs. My first impression is that it has something to do with the way the splash works with the video memory in the framebuffer.
I also don't know if this is related, but every once in a while, when the kernel would switch to the higher resolution frame buffer settings, the system would freeze up tight, not even getting to init. Since I removed splash= from grub, I haven't had that issue. Whenever the splash= was active, the screen would start up with horrible looking fonts, then get to this one particular point in the boot, reset the video mode and display the fonts properly. This is the point where it would occasionally lock up on me. Without splash, it never does that video mode change and thus never locks up on me. However, the side effect was that VMWare no longer messes with the color palette.
Sorry if I seem like I'm rambling, but it's Friday, and I SO need the weekend to get here.
I've also experienced this problem. I've been using vmware for a while, then needed to rebuild the system from scratch. When I did so, I noticed that vmware started corrupting the screen. I tried the two latest gentoo-dev-sources, nvidia-kernel drivers, and combinations of them. However none of them solved the problem. From seeing one of the previous solutions, I decided to switch from vesa-tng to vesafb in my kernel. This seems to solve the problem for me too. It is my opinion that there may be a problem in the vesa-tng driver.
tredman2 wrote:That would make sense. That's the VESA driver I was using.
Not an absolute thrut. I'm using the tdfx framebuffer driver and I occasionnaly have the issue. But, finaly, switching to a text console and back to X fix it. Not that of a big deal.
(7 of 9) Installing star-trek/species-8.4.7.2::talax.
That seems to be the universal fix, no matter which driver you're using. I think all it needs is for the video mode to be reinitialized, and it's fine. Any program that you run in X that changes the video mode, like full screen media applications or games, should do the same thing.
And while doing an CTL-ALT-F1 followed by an ALT-F7 is a workaround, I'm in and out of VMWare so much that I just got weary of it.
Well, I usualy do it once. while I don't know your definition of "frequent", I too go back and forth between the guest and the host, but I don't use (or very occasionaly) the full screen feature. But if the color palette does get screwed up constantly, I have no problem imagining it would get anyone agravated.
(7 of 9) Installing star-trek/species-8.4.7.2::talax.
not sure, just a guess, but for me, it screw only the anti-aliased fonts. A Konsole text is OK, but texts in evolution and firefox are screwed.
ctrl-alt-F1 and back to ctrl-alt-F7 fixes it until the next vmware start.
Charles
Charles Bueche <charles@bueche.ch>
sand, snow, wave, wind and net -surfer
i'm experiencing the palette problem as well, with vmware workstation 5, the latest xorg and the latest ati-drivers, and I seem to have fixed the problem by simply setting the windows that runs inside the vmware to use 16 bit colour instead of 32 bit colour. the problem only stopped happening after one restart of xorg. not sure if that's a solution for anybody but it's worked for me.
# charles leaver
# obsidian switch (pty) ltd.
# charles@switch-it.co.za
you are using vesa framebuffer I suppose. To get rid of those permamently kernel has to be compiled without framebuffer suport, you will loose penguin/bootsplash etc but vmware will be working properly with no trash on the screen left and fully functional full screen mode. (at least it helped in my case)
Well I don't know if anything has to do with it but I was reading a article regarding how to speed up the system ...
One of the thing to we could do was sysctl -w vm.swappiness=10
well not only speed up a little bit my system as the vmware wks 5 stop messing with my color pallete.
by the way ... I'm using 2.6.11-gentoo-r7, ati-drivers 8.12.10, xorg-x11 latest version.
Death is just another step to get into another plane of existence.
This is interesting, I'm not suffering from this problem. I'll contribute my system details
kernel: 2.6.11.7 (vanilla)
vesa driver: vesafg (not vesa-tng)
gensplash: patched and worked
nvidia drivers: for geforce ti 4200
vmware: 5
vmware windows bit depth: 32