where mouse is drawn on guest does not match mouse coordinates -> fixed in SVN

[Stéphane Charette]

I've observed this on Debian Etch 64-bit guest running on Ubuntu 8.04 64-bit host; VirtualBox 2.0.2.

With *some* guest screen resolutions (not all) the mouse seems to be drawn in the wrong location. Near the top of the screen, the mouse is OK. But as the mouse progresses through the Y axis towards the bottom of the screen, an offset appears between the drawn mouse and where X think the mouse is located. Near the bottom of the screen, I've seen a difference of maybe 100 pixels between the drawn mouse and where X thinks the mouse is located.

This is very obvious when dragging a window towards the bottom of the screen, or trying to click on a button located near the bottom of the screen. End result is you must click anywhere between 50 to 100 pixels "higher" than where you actually want to click.

Example resolution (/etc/X11/xorg.conf) where this problem does not happen: 1280x1024

Example resolutions where this problem occurs: 1400x940, 1152x864, 1200x950

Workaround: if I disable mouse integration then the mouse works fine.

[Michael Thayer]

Could you please attach your guest xorg.conf file? I am wondering whether you have fixed the virtual Y resolution to 1024 or something similar. Of course, this should not cause the problem you are seeing, but knowing might help us fix it.

[Stéphane Charette]

I'm trying to use resolutions where Y is 950. So the VB window fits nicely in my screen without the use of scroll bars. My host resolution is 1050 pixels high.

The relevant parts of xorg.conf would be:

Section "Device"

Identifier "Generic Video Card"

Driver "vboxvideo"

BusID "PCI:0:2:0"

EndSection

Section "Screen"

Identifier "Default Screen" Device "Generic Video Card" Monitor "Generic Monitor" DefaultDepth 24 SubSection "Display"

Depth 24 Modes "1400x940" "1200x940" "1280x854" "1024x768" "800x600" "640x480"

EndSubSection

EndSection

All of this wouldn't matter if the dynamic desktop resizing function worked like it does when the guest is Windows and Ubuntu. But for some reason it doesn't work with Debian.

[Michael Thayer]

Reproduced it on a 32bit Etch guest, but only when I add "1280x1024" to the list of resolutions that you gave. Dynamic resizing doesn't work on Etch because it relies on features added in Xorg server 1.3 (RandR 1.2).

[Stéphane Charette]

Update: This is still happening for me with VirtualBox 2.0.4.

[Stéphane Charette]

Bump. Any news on this?

[Stéphane Charette]

Problem still exists in VirtualBox 2.0.6.

[Samus_Aran]

The mouse is always out of alignment when using low resolution SDL fullscreen modes in the guest, such as running "tuxpaint --fullscreen".

[Samus_Aran]

I should mention I am on the latest (2.0.6) with an Ubuntu 8.10 guest on an Ubuntu 8.04 host.

[Stéphane Charette]

Problem still exists in VirtualBox 2.1 released today.

My xorg.conf file contains:

SubSection "Display"

Depth 24 Modes "1650x940" "1280x1024" "1024x768" "800x600" "640x480"

EndSubSection

I run at 1650x940 simply because it fills up the right amount of my host's screen that I can still access the top bar. But due to this mouse issue, I must run with mouse integration disabled.

[Frank Mehnert]

Does it change anything if you change the resolution to something where the width is divisible by 8?

[Stéphane Charette]

I modified my /etc/X11/xorg.conf file (relevant portion posted in my comment above) to try the following resolutions:

1650x940 (neither width nor height are multiples of 8) 1648x940 (width is multiple of 8) 1650x936 (height is multiple of 8) 1648x936 (both width and height are multiple of 8)

Same incorect behaviour with all 4 of these resoltuions. The mouse is in sync at the top of the screen, but as you move down, the mouse is less and less in sync. The mouse is drawn higher up than where the "hidden true" mouse is located.

[Michael Thayer]

I have investigated this a bit more, and I have discovered the reason for the wrong mouse position, but have no idea how to fix it. The reason is that when we report the absolute position of the pointer to the X server, the server interprets this as an absolute position on the virtual desktop. If the virtual desktop is larger than the actual guest resolution, then the position at which the pointer is reported will be scaled, as the host reports a position relative to the physical resolution (was that understandable?) However, I can't find any way for the mouse driver to access this information (the graphics driver can, obviously, but the two don't communicate). The workaround is to make sure that the virtual desktop is no larger than the guest resolution.

[Michael Thayer]

I've implemented a better work-around for this situation. Now, if the virtual desktop in the guest is larger than the physical one we hide the host mouse pointer and let the guest draw its own pointer in software inside the VM. The guest will always draw the pointer where it thinks it ought to be. A slightly ugly solution, but still much better than before. Unfortunately this won't make it into the 2.1 series though.

[Stéphane Charette]

Thank you for the update, Michael. I've worked around this for now by choosing different resolutions.

[lonicerae]

Hi all, for virtualbox v3.0.x, I did not meet this problem(I use win32 version). but when I upgrade to v3.1.0, this happens again.

Flos

[sunlover]

lonicerae, please attach VBox.log of the VM. Have you updated guest additions?

[Michael Thayer]

And is Win32 the host or the guest?

[lonicerae]

Hi sunlover and michael

i'm very sorry i'm late...

my machine is a windows 2003 server, it was also the host, and installed a x86 debian as a guest. i upgraded virtualbox 3.0.10 to 3.1.0 and try to install additions iso for my guest debian, but failed to compiled the drivers. my debian had already installed the suitable kernel-source and kernel-headers and GCC compiler.

now the the server was take away by other workmates, i cannot get the previous VBox.log... :(

[Diggory]

I'm encountering this same issue in VirtualBox 4.1.4 r74291 (Currently the latest release) I'm running a 32-bit Ubuntu client on a 32-bit Vista host. Changing the display mode to a size smaller than the virtual desktop (In this case temporarily changing from 1280x708 to 800x600 for a fullscreen application) causes exactly the same problems as are described above.

[Michael Thayer]

Do you have the latest version of the Guest Additions installed?

[Diggory]

It's a fresh install of VirtualBox and the guest additions CD is called "VBOXADDITIONS_4.1.4_74291", so I presume so. Is there a better way to get the actual version that's installed?

[Frank Mehnert]

Yes, the installed version of the Guest Additions is shown if the guest is fully booted and you press HostKey+N.

[Michael Thayer]

Diggsey: are you using a custom xorg.conf file? If so, could you please attach it?

[Diggory]

Using HostKey+N also shows that the latest version of the guest additions is installed.

I'm not using a custom xorg.conf file. The file does not exist, which AFAIK is normal for the latest version of ubuntu.

[Michael Thayer]

Let me ask my question differently then - what did you do to get a guest resolution smaller than the virtual desktop size? Or in other words can you give me a more explicit recipe to reproduce this?

[Diggory]

The problem occurs in any program I run which changes the actual screen resolution rather than just scaling the output to fit. But I can show you the code I'm using in my own application:

if (options & keWindow_Fullscreen) {
	int numModes = 0;
	XF86VidModeModeInfo** modes = 0;
	XF86VidModeGetAllModeLines(_display, DefaultScreen(_display), &numModes, &modes);
	w->defaultMode = *modes[0];

	int bestMode = 0;
	int bestDist = 0x7FFFFFFF;
	for (int i = 0; i < numModes; i++) {
		int xdist = modes[i]->hdisplay - w->width;
		int ydist = modes[i]->vdisplay - w->height;
		int dist = xdist*xdist + ydist*ydist;
		if (dist < bestDist) {
			bestDist = dist;
			bestMode = i;
		}
	}
	XF86VidModeSwitchToMode(_display, DefaultScreen(_display), modes[bestMode]);
	XF86VidModeSetViewPort(_display, DefaultScreen(_display), 0, 0);
	XMoveResizeWindow(_display, w->wnd, 0, 0, w->width, w->height);
	XMapRaised(_display, w->wnd);
	XGrabPointer(_display, w->wnd, True, 0, GrabModeAsync, GrabModeAsync, w->wnd, 0L, CurrentTime);
	XGrabKeyboard(_display, w->wnd, False, GrabModeAsync, GrabModeAsync, CurrentTime);
	XFree(modes);

	waitForEvent<MapNotify>(w);

	XEvent xev = {0};

	xev.type = ClientMessage;
	xev.xclient.window = w->wnd;
	xev.xclient.message_type = _net_wm_state;
	xev.xclient.format = 32;
	xev.xclient.data.l[0] = 1;
	xev.xclient.data.l[1] = _net_wm_state_fullscreen;
	xev.xclient.data.l[2] = 0;	/* no second property to toggle */
	xev.xclient.data.l[3] = 1;	/* source indication: application */
	xev.xclient.data.l[4] = 0;	/* unused */

	XSendEvent(_display, _root, 0, SubstructureRedirectMask | SubstructureNotifyMask, &xev);
}

This should change the display mode to the window size and then tell the window manager to make the window borderless and full-screen.

[Michael Thayer]

Now I see what the problem is and I can reproduce it. I must admit that I didn't realise that this resizing API was still supported in current X servers. Unfortunately though we can't support this due to limitations in our virtual video setup which is more tuned to Windows than to X11. You might consider switching to the Resize and Rotate API for doing screen resizing which is the currently recommended way of doing things.

[Christian Iseli]

I apparently run into the same problem of mouse pointer offset.

I have a Win7-64bit host, running latest VirtualBox (4.1.16).

I installed Fedora 17 using a dual monitor setup. When F17 starts, both monitors show the same image, and the mouse is ok.

Then I use xrandr to setup the 2 monitors:

xrandr --output VBOX1 --right-of VBOX0

at this point, the drawn mouse pointer no longer corresponds with where the X server pointer really is.

I use the exact same setup in Fedora 16 with no such issue.

[Michael Thayer]

c4chris: Could you please attach the following files from the guest:

/var/log/Xorg.0.log /var/log/vboxadd-install.log

as well as providing the output of "lsmod | grep box"? Thanks.

[Christian Iseli]

lsmod | grep box

[Christian Iseli]

Replying to michael:

c4chris: Could you please attach the following files from the guest:

/var/log/Xorg.0.log /var/log/vboxadd-install.log

as well as providing the output of "lsmod | grep box"? Thanks.

Ok, done. Cheers.

[Michael Thayer]

For some reason X.Org on your guest is not using the Guest Additions mouse driver, but is using our emulated USB device (which doesn't support multi-monitor) instead. I will try installing an F17 guest here to see if the same thing happens to me.

[Christian Iseli]

Replying to michael:

For some reason X.Org on your guest is not using the Guest Additions mouse driver, but is using our emulated USB device (which doesn't support multi-monitor) instead. I will try installing an F17 guest here to see if the same thing happens to me.

Ok, thanks. In the meantime, is there an easy way for me to disable the emulated USB device (which I do not need I think) or to force usage of the correct mouse driver ?

[Michael Thayer]

You could apply this patch to /usr/src/vboxguest-4.1.16/vboxguest/VBoxGuest-linux.c (see attached file).

[Michael Thayer]

Patch to make mouse integration work in Fedora 17

[Michael Thayer]

That patch needs to be applied to the kernel module source code on the guest by the way, and then the module needs to be rebuilt by doing

$ /etc/init.d/vboxadd setup

Any future major releases of VirtualBox should contain this fix, not sure about 4.1 releases.

[Christian Iseli]

Replying to michael:

You could apply this patch to /usr/src/vboxguest-4.1.16/vboxguest/VBoxGuest-linux.c (see attached file).

Thanks! That works for me :-)

[Frank Mehnert]

Btw, VBox 4.1.18 does NOT contain that fix yet but the next maintenance release will.

[Michael Thayer]

Just confirming, I have applied the fix to 4.1, so any future 4.1 releases will contain it.

[Frank Mehnert]

Fixed in VBox 4.1.20.