Multiple monitor screen redraw problem w. 64 bit SL kernel?

[besson3c]

Hello,

Is anybody able to reproduce this persisting bug while booted into the 64 bit kernel? It seems to have gone away in the 32 bit kernel, I'm just wondering if this is reproducible elsewhere? Is there a separate download/recompile for the 64 bit kernel extensions?

[ukchucktown]

I don't think it has much to do with 32 or 64-bit. I booted both and the redraw problem is reproducible on my secondary display. When it does occur the display area in the VirtualBox window (Windows and Linux guests both) goes black if the window is maximized and I gesture to a window on the primary display. It redraws when I gesture to the maximized VB window but it does not redraw the entire window. I often have to move the mouse over the entire VB window area or click in the window before the entire display is repainted. Move the VB window to the primary display or reduce it slightly so it's not maximized and it repaints. If the VB window is not maximized the behavior is a little different, less predictable, but I can still produce the redraw problem on secondary displays.

[besson3c]

Hmmm... I'm getting the problem not in fullscreen or seamless mode, and with auto-resize guest unchecked. The window blacks entirely when I click outside of it, and bits and pieces redraw when I click on it.

I could have sworn that this wasn't a problem when I had my machine last booted in 32 bit mode, it's probably just me though. I knew this was sort of a long shot, but I also know that this bug was announced as being fixed for 3.0.10 (which I'm running).

Is there a workaround for this, short of disabling my secondary monitor?

[ukchucktown]

The only workaround I've found is keep the VB windows on the primary display and in different spaces. If you move them to the secondary display the redraw problem will occur. It happens for me regardless of which kernel I boot. I now boot 64-bit exclusively but I tried 32-bit and the problem persists in 3.0.10.

[besson3c]

You're right, so far I haven't been able to reproduce the problem on my primary display. I must have had the window there when I was in 32 bit mode...

Shouldn't this bug be reopened? http://www.virtualbox.org/ticket/4942 ? This is clearly not resolved yet.

[ukchucktown]

I reopened it.

[besson3c]

Thank you... Perhaps we should refer the ticket to this thread? I'll continue to test things to see if there are any other conditions which trigger this. Now that I know the workaround the fix isn't so bad, but it was definitely a little troublesome when I didn't. It would be nice to see this fixed.

[knitd]

Have a look at this topic:

http://forums.virtualbox.org/viewtopic.php?f=8&t=22880

The workaround posted there works perfectly for me.

[ukchucktown]

I'm not a big fan of sharing an ICC profile between my laptop LCD and NEC external monitor especially considering I took the time to profile both my monitors. I tried and the colour difference bothers me more than the redraw problem. I still prefer keeping the VMs on the primary display in different spaces but you are correct that sharing a profile is another workaround. I linked the tracker issue to this thread since this is not resolved in 3.0.10.

[martireca]

another workaround (Host OSX 10.6.2 guest xp sp3 vbox 3.0.10 secondary monitor apple cinema display):
if I move vbox gui in the secondary monitor and then I started the guest in that monitor it works without problem.
In other words, if the guest is not in the same display in which originally started I have problems.
It's like it saves some settings on start up and it's not able to change it dynamically

[knitd]

The issue seems to be fixed in the 3.1.0 release. Thanks for the great work!

[ukchucktown]

I'm curious if anyone else is still observing this problem on OS X hosts in 64-bit mode. I have read a number of suggested workarounds and claims it's fixed but the problem persists in the latest release and every previous release with my configuration. It has never worked for me (I don't run 32-mode) and I test every new release for the problem. The only workaround is to set the external LCD and laptop display to the same ICC profile. The results are pitiful so it's not really a workaround.

My model version is MacbookPro5,5 with a dual monitor setup. I have not tested with two external monitors. My configuration is a laptop LCD and external monitor. I'm looking for anyone with a similar configuration to test and confirm this bug. It's easy to reproduce the problem. You need a dual monitor setup (to mimic my setup a laptop and external should do it) with distinct ICC profiles. For me, anytime I run the virtual machine window in the laptop display I get paint problems. There is nothing special about my setup. I'm not trying to run any experimental 3D stuff and the guest OS doesn't matter. I have Windows and Linux VMs exhibiting the same problem.

[vmmaestro]

I am still seeing this in 3.1.6 in both Win32 / Win 64 clients on OSX 10.6.2&3.

Is this bug still open?

[dariof]

Just a "me too". It happens with VirtualBox 3.1.6 r59351, both with Windows XP and Ubuntu as guest OSes on a Mac Mini 2009 with dual screen display, running Snow Leopard 1.6.3. Should we file a new ticket?

[lootsd]

I am running VirtualBox 3.2.8 on MAC OS X 10.6.4 and I run into this problem only when I run in 64bit mode (by holding down "6" and "4" while booting).

When my MacBook Pro boots in 32bit mode, this is not a problem at all, even though I use dual screens (Laptop PLUS External screen) and they use different Display (Color) Profiles.

When it boots in 64bit mode, the guest OSes (Windows XP and Ubuntu Desktop) are hardly useable because of this problem, the screen is mostly black and does not draw correctly.