FS#30700 - [virtualbox] Problem with the mouse when running archlinux as guest

Attached to Project: Community Packages
Opened by Olivier (olive) - Monday, 16 July 2012, 09:45 GMT
Last edited by Alexander F. Rødseth (xyproto) - Friday, 28 September 2012, 23:22 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Ionut Biru (wonder)
Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

There is a problem with the mouse integration when running archlinux as a guest in virtualbox. The mouse can behave erratically. I have already reported a bug about this (  FS#30477  ) ; unfortunately I completely misunerstood the cause of the problem; making the bug invalid.

The problem is that virtualbox present to the guest 3 mice: A generic Imps/2 mouse, a touchpad, the special device "virtualbox mouse integration". Evdev appears to pick one of these three devices at random but, provided the archlinux integration is properly installed (not sure if it is really necessary), only the third device "virtualbox mouse integration" works properly. So with the default configuration you have basically one chance out of three that everything works properly (making the problem so difficult to debug initially). The remede is to modify the files in /etc/X11/xorg.conf.d/ to remove all reference to mice expect one matching the virtual mouse integration and only this one:

Section "InputClass"
Identifier "evdev virtual mouse"
MatchProduct "VirtualBox mouse integration"
Driver "evdev"
EndSection

There are difficulties though, since we can only do this when running in a virtual machine and it is possible that Xorg won't run at all without the additions. I am not sure how to deal with this in a general way.

Additional info:
* package version(s)

xf86-input-evdev 2.7.0-2
xorg-server 1.12.3-1
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Friday, 28 September 2012, 23:22 GMT
Reason for closing:  No response
Additional comments about closing:  Please reopen if this is still an issue.
Comment by Olivier (olive) - Monday, 16 July 2012, 09:52 GMT
Updated: Now the cursor is good but the mouse does not respond to click. I am pretty sure there is a conflict with the different mice presented but I am still unsure of the remedy.
Comment by Olivier (olive) - Tuesday, 17 July 2012, 08:03 GMT
In case it can help, I attach two xorg.0.log file. One when the bug appears, one when everything works properly. Both situations apparently appears at random. It may be due to the order the mice are detected.
   Xorg.0.log.bug (22 KiB)
   Xorg.0.log.good (26.9 KiB)
Comment by Ionut Biru (wonder) - Friday, 20 July 2012, 12:15 GMT
it's not a good solution to remove the entries from 10-evdev.conf. Can you try to create /etc/X11/xorg.conf.d/20-virtualbox.conf containing:

Section "InputClass"
Identifier "evdev virtual mouse"
MatchProduct "VirtualBox mouse integration"
Driver "evdev"
EndSection
Comment by Olivier (olive) - Friday, 20 July 2012, 22:45 GMT
@Ionut Biru (wonder). Your solution seems to work. The bug was not reproduced after several reboot of the virtual machine.
Comment by Sébastien Luttringer (seblu) - Saturday, 21 July 2012, 02:07 GMT
Do you have only the archlinux default xorg config on the guest? Did you check "Enable absolute pointing device" on the host? I cannot reproduce the bug.

Reading your Xorg.0.log.bug and last result with Ionut suggestion, MatchIsPointer doesn't detect vbox driver as a pointer.

Comment by Olivier (olive) - Saturday, 21 July 2012, 07:42 GMT
@seblu. I have experienced the bug on a Windows XP host without an xorg.conf file but with a self created 15-SourisCarrefour.conf (attached below) and with the keyboard section of 10-evdev.conf modified as below (the reason of this file is that I can boot the same patition natively, but I have tried to be very specific in 15-SourisCarrefour.conf about the mouse I configured). The solution of Ionut Biru seems to definitively fix the problem but this bug is difficult to reproduce and it is difficult to say for sure when it appears without trying 10-20 times after having done unrelated things as rebooting the host several time. I can well imagine some kind of race condition in the mouse detection.

Section "InputClass"
Identifier "evdev keyboard catchall"
MatchIsKeyboard "on"
MatchDevicePath "/dev/input/event*"
Driver "evdev"
Option "XkbLayout" "fr"
Option "XkbModel" "pc105"
Option "XkbVariant" "oss"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection
   15-SourisCarrefour.conf (0.5 KiB)
Comment by Sébastien Luttringer (seblu) - Saturday, 21 July 2012, 13:56 GMT
from xorg.conf: The Identifier entry specifies the unique name for this input device.

your 15-SourisCarrouf.conf use the same identifier as 10-evdev.conf and add a MatchProduct. Maybe there are some issues around here.

Virtualbox on host (win xp) is the same version on the guest (arch)?

However, the question remains, should we put 20-virtualbox.conf in the package, knowing that is working correctly without it.
Comment by Olivier (olive) - Sunday, 22 July 2012, 07:04 GMT
I have succeeded to reproduce the bug without 15-SourisCarrefour.conf. Virtualbox on the host is 4.1.18. But I am puzzled because this bug is difficult to reproduce, the chances that it appears are greater when you boot the virtula machine for the first time after having booted the host. I can well imagine that for some reason all work fine for some (most?) people.
Comment by Willow Walthall (ghthor) - Tuesday, 07 August 2012, 01:53 GMT
Ionut Biru (wonder)'s fix isn't working for me. This bug appears everytime I boot my VM. Should I post my logs?
Comment by Sébastien Luttringer (seblu) - Sunday, 26 August 2012, 16:32 GMT
Can you attach the output of udevadm info --export-db (runned as root). I would know if udev export mouse correctly to evdev.
Comment by Willow Walthall (ghthor) - Sunday, 26 August 2012, 21:40 GMT
My issue doesn't appear to be arch specific. I haven't tested with other distributions but I've heard reports from 1 F17 user that is experiencing the same behavior.
   udevadm.out (60.9 KiB)
Comment by Sébastien Luttringer (seblu) - Sunday, 26 August 2012, 22:09 GMT
@olivier, can you attach the output of udevadm info --export-db (runned as root) when the bug occur and when not.

@ghthor, if your bug is not arch specific, please report it upstream.
Comment by Willow Walthall (ghthor) - Sunday, 26 August 2012, 22:23 GMT
Yes I am. I apologize, it appears that the bug I'm experiencing is producing the same behavior(erratic mouse movement) but doesn't share the same cause.
Comment by Olivier (olive) - Monday, 27 August 2012, 08:08 GMT
@seblu. Here are the two files requested. Both have been runned without the 20-virtualbox.conf of "wonder" (the bug never appear with this file).
   udev_db_with_bug (55.3 KiB)
   udev_db_without_bug (55.4 KiB)
Comment by Sébastien Luttringer (seblu) - Monday, 27 August 2012, 09:17 GMT
Ok, that's what I thought.

E: ID_INPUT_MOUSE=1
is missing when bug occur. udev doesn't detect this device as a mouse of the vbox drivers. This explain why wonder patch works.

Do you have the latest version of udev? You should probably report this upstream, as there is a race condition on detection of the mouse status by udev in the guest.
Comment by Olivier (olive) - Monday, 27 August 2012, 10:04 GMT
@seblu Yes the bus appaers with the latest version of udevd (systemd-tools 188-2). You seems to have understand the cause of the problem better than me. Maybe it would be more productive if you could report the bug upstream for me. You would be able to make a precise bug report reporting exactly what the problem is.
Comment by Sébastien Luttringer (seblu) - Monday, 27 August 2012, 10:31 GMT
I suggest you open the bug and i comment with our tests if needed. If upstream needs more test, i will not be able to provides it.
Comment by Olivier (olive) - Monday, 27 August 2012, 14:27 GMT
Done, here is the upstream report:

https://bugs.freedesktop.org/show_bug.cgi?id=54123
Comment by Sébastien Luttringer (seblu) - Tuesday, 28 August 2012, 19:55 GMT
hum. Misunderstanding. I suggest you to report this bug to virtualbox bug tracker not systemd one. There is probably no issue with udev.

My assessment of the situation:
Your mouse is not detected, it's because Xorg config rules MatchIsPointer is not true with this device. This parameter is based on evdev, which guess pointer/keyboard/etc on "udev input_id" informations.

From your last report, udev doesn't detect your mouse as input mouse. I don't know how udev guess this. So, maybe udev as issues, or kernel, or virtualbox code (most likely).
Comment by Olivier (olive) - Tuesday, 28 August 2012, 21:58 GMT
Ah yes, now I see... But maybe I will wait if there is any reaction on the systemd bug tracker instead of reporting this bug everywhere. Hopefully if it is indeed not udevd fault, they will at least forward the bug to VirtualBox. Because it is not a standard mouse maybe VirtualBox does not report it as mouse puposely in order to prevent unaware system of considering this as a mouse and thus malfunctioning. Or maybe I am wrong but I fear that reporting something like "mouse behaves erratically" to VirtualBox, kernelcode, etc... will just be not productive.
Comment by Sébastien Luttringer (seblu) - Tuesday, 28 August 2012, 22:12 GMT
Doesn't forget you have something worderful for a developer who wants troubleshoot, you can reproduce the bug!

I agreen, we can wait udev/systemd dev give their feeling on the br. There is some quirks in the udev code for some devices, like vmware usb mouse.

So, I looked into udev code about pointer detection, it's small and clean (src/udev/udev-builtin-input_id.c).

There is some interesting line printed in debug : log_debug("%s raw kernel attribute: %s\n", attr, text);

You can run something like udevadm --debug test-builtin input_id /class/input/mouse0 to have kernel parameter.
Comment by Sébastien Luttringer (seblu) - Sunday, 16 September 2012, 14:22 GMT
same issue with 4.2?
Comment by Alexander F. Rødseth (xyproto) - Friday, 28 September 2012, 23:22 GMT
No response for almost two weeks. Closing.

Loading...