VirtualBox

Opened 16 years ago

Last modified 12 years ago

#2306 closed defect

where mouse is drawn on guest does not match mouse coordinates -> fixed in SVN — at Version 32

Reported by: Stéphane Charette Owned by:
Component: guest additions Version: VirtualBox 2.1.4
Keywords: Cc:
Guest type: Linux Host type: Linux

Description (last modified by Michael Thayer)

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.

Change History (35)

comment:1 by Michael Thayer, 16 years ago

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.

comment:2 by Stéphane Charette, 16 years ago

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.

comment:3 by Michael Thayer, 16 years ago

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).

comment:4 by Stéphane Charette, 15 years ago

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

comment:5 by Stéphane Charette, 15 years ago

Bump. Any news on this?

comment:6 by Frank Mehnert, 15 years ago

Version: VirtualBox 2.0.2VirtualBox 2.0.4

comment:7 by Stéphane Charette, 15 years ago

Problem still exists in VirtualBox 2.0.6.

comment:8 by Samus_Aran, 15 years ago

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

comment:9 by Samus_Aran, 15 years ago

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

comment:10 by Stéphane Charette, 15 years ago

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.

comment:11 by Frank Mehnert, 15 years ago

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

comment:12 by Stéphane Charette, 15 years ago

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.

comment:13 by Michael Thayer, 15 years ago

Version: VirtualBox 2.0.4VirtualBox 2.1.4

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.

comment:14 by Michael Thayer, 15 years ago

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

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.

comment:15 by Stéphane Charette, 15 years ago

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

comment:16 by Frank Mehnert, 15 years ago

Resolution: fixed
Status: newclosed

comment:17 by lonicerae, 14 years ago

Resolution: fixed
Status: closedreopened

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

comment:18 by sunlover, 14 years ago

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

comment:19 by Michael Thayer, 14 years ago

And is Win32 the host or the guest?

comment:20 by lonicerae, 14 years ago

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... :(

comment:21 by Frank Mehnert, 14 years ago

Resolution: worksforme
Status: reopenedclosed

comment:22 by Diggory, 12 years ago

Resolution: worksforme
Status: closedreopened

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.

comment:23 by Michael Thayer, 12 years ago

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

comment:24 by Diggory, 12 years ago

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?

comment:25 by Frank Mehnert, 12 years ago

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

comment:26 by Michael Thayer, 12 years ago

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

comment:27 by Diggory, 12 years ago

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.

comment:28 by Michael Thayer, 12 years ago

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?

comment:29 by Diggory, 12 years ago

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.

comment:30 by Michael Thayer, 12 years ago

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.

comment:31 by Christian Iseli, 12 years ago

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.

comment:32 by Michael Thayer, 12 years ago

Description: modified (diff)

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.

by Christian Iseli, 12 years ago

Attachment: lsmod.txt added

lsmod | grep box

by Christian Iseli, 12 years ago

Attachment: vboxadd-install.log added

by Christian Iseli, 12 years ago

Attachment: Xorg.0.log added
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use