VirtualBox Negative Image
 

I've had this problem for a while; when VirtualBox is started all Linux-side windows go "negative," kind of like a photographic negative and are pretty much unusable until KDE is restarted.

This happens on two Dell Dimension boxes both running Slackware 13.0 32-bit with attached LCD displays (one Acer, one Dell [who knows what that actually is]). The problem does not appear on a Dell Inspiron 1750 (running Slackware 13.0 64-bit).

All three servers are running KDE 4.2.x and all three are running VirtualBox-3.1.4-57640-Linux_amd64.run or VirtualBox-3.1.4-57640-Linux_x86.run as appropriate for the platform (the latest version). This problem existed prior to the update to the current version as well on the 32-bit boxes but not on the 64-bit.

Any ideas?

What is the host OS, What is the guest OS, what are the color palettes that the host OS are using?

Are some of the windows (application) using there own color sets?

It might be KDE4.2.4 that's the problem. Get the 4.3.1 packages from here:

http://cardinal.lizella.net/~vbatts/...ackages/4.3.1/

Get them all in a directory, the run:
Don't forget to blacklist them if you use slackpkg.

The host OS is Slackware 13.0 32-bit, the guest is XP. The window manager, in Slackware, is KDE 4.2. What palettes? I dunno, and don't know how to find out -- but both KDE and XP are their default, 32-bit and neither has been fooled around with. None of the three servers have an /etc/xorg.conf file, I let them default to udev and everything else works just fine. I did try running xorgsetup to auto-generate an xorg.conf on one of the problem servers, but that didn't make any difference in anything so I removed it.

It does not matter if anything is actually exectued in XP -- simply starting VirtualBox causes the problem or starting VirtualBox, booting XP and immediately shutting it down also causes the problem.

Again, this is a problem with two servers -- the other, a laptop, does not have the problem and it and the other servers are identically configured with the same distribution (except for the 32-bit on the two and 64-bit on the one).

This problem has existed through three versions of VirtualBox, all the "binary" versions (I don't compile the open source versions because of the functions that version does not support, I use the "run" one to install).

Thanks, I did think about that... but, had the same problem on the same server with KDE 3.x (from Slackware 12.x) too. And through two updates of VirtualBox.

So, I dunno.

The reason I asked about the palettes is the X has many available.

If I am running in "24-bit color" and an application "creates it's window' in "32-bit color", the colors go weird in the the other windows (24-bit color) while the "32-bit color" window has the focus and via-a-versa.

Window specific information can be obtained via the "xwininfo" command then click on the window. For example my firefox has the output of:
Because the next tool I talk about, I see that this is '24-bit color' window.



The command "xdpyinfo" reports information about the display including the palettes. Most of the Linux video is "24-bit color". The palettes are called "visual" within X. For example my computer has support for:

So, if I understand what you're telling me, if the Linux host is 24-bit and the XP guest is 32-bit, I should set the XP guest to 24-bit and all will be well? No more making KDE go crazy (and stay insane until it's shut down and restarted)? And what if an XP application demands 32-bit (so the guest window doesn't all of a sudden go to postage-stamp size and is unadjustable)?

Tiz a puzzlement.

I am asking if the weird colors on the host correct when you focus a host window.

The current "X window system" protocol (X11) dates back to 1987 while the first version was in 1894 at MIT after doing surgery to "W" to make it run faster under UNIX. When the "protocol" changes the major version number changes and about at major version 9, people started referring to it as X9 as well as simply X.

The typical GUI environment on a Linux system has three layers of GUI.
3) Desktop environment (KDE, Gnome, xfce, ...) which sits on top of layer 2
2) Window manager (Compiz Fusion, Compiz, Metacity, Blackbox, FVWM, Enlightenment, Openbox, Sawfish, IceWm, ... which sits on top of layer 1
1) X server (this server provides access to the hardware display, keyboard, mice)

When a "GUI application" is written, the author has to decide which layer (in 1993 I had an application that had been written to layer 1 and we added access to layer 2 in a year long migration to a layer 2 application) they will be using to talk to the hardware. If at layer 3 then the layer 3 talks to the layer 2 which talks to layer 1 which talks to the hardware. The biggest advantage of X over windows is that the hardware being talked to can reside on a completely different computer (completely network transparent from the first version).

Because there are may "visual" definitions and the "GUI application" in Linux can select which "visual" is being used. If that "GUI application" results in its own color palette, then when it has "focus" the whole display is using its palette. Realize that X was created from "W" back in 1984 when every thing was black and white (color was as added in September 1985 with version 9 of X) and at that time 8-bit color was the normal. Without the capability of allowing an application to be able to create its own palette, the total number of colors would be the first 16 colors registered and of those 16 two were white and black. Do if the first application grabbed another 10 colors, the second application would have access to the 12 already allocated and could allocate up to 4 more. As soon as the full 16 were grabbed, an application requesting a new color would be rejected as the palette was full. By allowing the capability to have your own palette (which must be present in the code for the application) the application would be allowed to use the full 16 colors.

This could be true if 24-bit and 32-bit applications reside at the same time. I have not gotten "uevent" X to be 32-bit and it falls back to 24-bit so my color count has suffered at the freedom of not having an "xorg.conf" file.

Nope.

It goes like this

1. log in
2. startx
3. start VirtualBox
4. start XP
5. click or focus on a host window -- weird colors
6. shut down XP
7. shut down VirtualBox
8. weird colors -- entire screen
9. shut down KDE
10. startx
11. all is normal

Tiz a puzzlement.

I'm running KDE 4.3.3, virtualbox (non-OSE) 3.0.12, xorg-server 1.6.5-r1. Gentoo, on a Thinkpad R60, intel i950 video. When and loaded a Windows XP pro to test (took twice as long to install as Fedora 12 over the net). I have none of these issues with it.

The only thing I can think of at this time to attempt is:
"ctrl-alt-f4" and then "ctrl-alt-f7" does this help, as it changes the video card modes most of the time.