VirtualBox

Ticket #2306 (closed defect: fixed)

Opened 6 years ago

Last modified 20 months ago

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

Reported by: stephanecharette Owned by:
Priority: major Component: guest additions
Version: VirtualBox 2.1.4 Keywords:
Cc: Guest type: Linux
Host type: Linux

Description (last modified by michael) (diff)

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.

Attachments

lsmod.txt Download (147 bytes) - added by c4chris 22 months ago.
lsmod | grep box
vboxadd-install.log Download (163.5 KB) - added by c4chris 22 months ago.
Xorg.0.log Download (35.2 KB) - added by c4chris 22 months ago.
VBoxGuest-linux.c.patch Download (7.7 KB) - added by michael 22 months ago.
Patch to make mouse integration work in Fedora 17

Change History

comment:1 Changed 6 years ago by michael

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 Changed 6 years ago by stephanecharette

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 Changed 6 years ago by michael

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 Changed 5 years ago by stephanecharette

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

comment:5 Changed 5 years ago by stephanecharette

Bump. Any news on this?

comment:6 Changed 5 years ago by frank

  • Version changed from VirtualBox 2.0.2 to VirtualBox 2.0.4

comment:7 Changed 5 years ago by stephanecharette

Problem still exists in VirtualBox 2.0.6.

comment:8 Changed 5 years ago by Samus_Aran

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

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by stephanecharette

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 Changed 5 years ago by frank

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

comment:12 Changed 5 years ago by stephanecharette

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 Changed 5 years ago by michael

  • Version changed from VirtualBox 2.0.4 to VirtualBox 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 Changed 5 years ago by michael

  • Summary changed from where mouse is drawn on guest does not match mouse coordinates to where 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 Changed 5 years ago by stephanecharette

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

comment:16 Changed 5 years ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

comment:17 Changed 4 years ago by lonicerae

  • Status changed from closed to reopened
  • Resolution fixed deleted

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 Changed 4 years ago by sunlover

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

comment:19 Changed 4 years ago by michael

And is Win32 the host or the guest?

comment:20 Changed 4 years ago by 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... :(

comment:21 Changed 4 years ago by frank

  • Status changed from reopened to closed
  • Resolution set to worksforme

comment:22 Changed 2 years ago by Diggsey

  • Status changed from closed to reopened
  • Resolution worksforme deleted

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 Changed 2 years ago by michael

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

comment:24 Changed 2 years ago by Diggsey

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 Changed 2 years ago by frank

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

comment:26 Changed 2 years ago by michael

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

comment:27 Changed 2 years ago by Diggsey

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 Changed 2 years ago by michael

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 Changed 2 years ago by Diggsey

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 Changed 2 years ago by michael

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 Changed 23 months ago by c4chris

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 follow-up: ↓ 33 Changed 22 months ago by michael

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

Changed 22 months ago by c4chris

lsmod | grep box

Changed 22 months ago by c4chris

Changed 22 months ago by c4chris

comment:33 in reply to: ↑ 32 Changed 22 months ago by c4chris

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.

comment:34 follow-up: ↓ 35 Changed 22 months ago by 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.

comment:35 in reply to: ↑ 34 Changed 22 months ago by c4chris

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 ?

comment:36 follow-up: ↓ 38 Changed 22 months ago by michael

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

Changed 22 months ago by michael

Patch to make mouse integration work in Fedora 17

comment:37 Changed 22 months ago by michael

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.

comment:38 in reply to: ↑ 36 Changed 22 months ago by c4chris

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

comment:39 Changed 22 months ago by frank

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

comment:40 Changed 22 months ago by michael

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

comment:41 Changed 20 months ago by frank

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed in VBox 4.1.20.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use