Ubuntu

vmmouse doesn't work with input hotplug

Reported by Philip Langdale on 2008-10-18
16
Affects Status Importance Assigned to Milestone
xserver-xorg-input-vmmouse (Ubuntu)
High
Bryce Harrington
Intrepid
High
Bryce Harrington

Bug Description

The vmmouse driver currently included in Intrepid is broken when used in conjunction with Server 1.5. This has been noted in bug 248521.

I have made an upstream update release of the driver that fixes this problem:

http://xorg.freedesktop.org/releases/individual/driver/xf86-input-vmmouse-12.5.2.tar.bz2

However, it is insufficient to just fix the driver; we also need to handle detection of the vmmouse device so that HAL will set the x11_driver property correctly for the device.

I would like to track the hotplug detection separately with this bug.

In the medium term, I will be trying to push the detection mechanism into HAL proper, but in the short term, it is easy to leverage the existing 'vmmouse-detect' utility to enhance HAL.

I will be attaching a new fdi file and HAL callout script to do this. I'm not sure which package these files should ultimately go into - possible the vmmouse package itself or maybe mdetect?

Philip Langdale (langdalepl) wrote :
Philip Langdale (langdalepl) wrote :

I'd like to nominate adding input hotplug support as an SRU. Intrepid isn't officially out yet, but it will be before any update can take place. If we agree that the broken driver should be fixed, the driver will still be very difficult to actually use in the absence of fixing this bug. Users would need to edit their xorg.conf file and disable input hot plugging and then add a device entry for the mouse. This is a non-trivial process and could lead them to difficulties with any other programs that assume that input hotplug is working.

Bryce Harrington (bryce) on 2008-10-18
Changed in xserver-xorg-input-vmmouse:
importance: Undecided → High
milestone: none → ubuntu-8.10
status: New → Triaged
Timo Aaltonen (tjaalton) wrote :

Sounds like a trivial fix. The driver can host these files for now, until HAL can detect the device.

Steve Langasek (vorlon) wrote :

Do I understand correctly that you're proposing to fix this bug in SRU? In that case, we should drop the 'ubuntu-8.10' milestone, which refers to bugs fixed before the final release.

Bryce Harrington (bryce) wrote :

I added the ubuntu-8.10 milestone in hopes it could be included with the release, esp. if it is a trivial fix as Timo suggests.

Steve Langasek (vorlon) wrote :

if a fix is available we can still consider it prior to release, but I'm dropping the milestone since this shouldn't be a release blocker.

Changed in xserver-xorg-input-vmmouse:
milestone: ubuntu-8.10 → none

Martin, could you take a brief look at this?

Colin Watson (cjwatson) wrote :

Bryce, can you get a debdiff prepared with all of the bits from Philip so that we can review this?

Martin Pitt (pitti) wrote :

I don't have vmware at hand ATM, but I tested it with kvm. The .fdi and callout look sane, are focused, and do the right thing, my mouse now uses the "vmmouse" driver. ACK on those. However, the mouse just jumps around erratically between the corner in kvm, if I see it at all. I guess that's what is meant by "broken with 1.5 and needs new upstream release".

Of course it would be suboptimal to do this as an SRU, since the live system wouldn't use vmmouse then. But I don't think it's crucial enough to risk breaking the release, so an SRU will do fine.

Martin Pitt (pitti) wrote :

That is, since the current -vmmouse driver is broken and can hardly get worse, I wouldn't mind an upload of the newer version *without* the magic fdi for intrepid final. We don't use it by default, so having it available for people who enable it manually would be good.

I'm just a bit concerned about switching from evdev to vmmouse by default at this stage (which would happen when we use the fdi), which is why I'd like to see this step happen in an SRU.

Changed in xserver-xorg-input-vmmouse:
assignee: nobody → bryceharrington
milestone: none → intrepid-updates
Martin Pitt (pitti) wrote :

Sorry, I guess it wasn't pointed out anywhere: xserver-xorg-input-vmmouse.install needs fixed paths. The .fdi goes into /usr/share/hal/fdi/policy/10osvendor/, the hal callout goes into /usr/lib/hal/.

Martin Pitt (pitti) wrote :

Also, I guess that update should include the new upstream version?

Philip Langdale (langdalepl) wrote :

Change looks fine and Martin's file locations are the the ones to use.

As Martin says, we'd better make sure the updated vmmouse binary works correctly or the hotplug support will actually make things worse (throwing a completely broken driver at the user instead of a sub-optimal but basically functional one)

Bryce Harrington (bryce) wrote :

More than one way to skin a cat...

Philip Langdale (langdalepl) wrote :

If that doesn't work, nothing will :-)

Martin Pitt (pitti) wrote :

Sorry, I missed that in my first review: You need to install the hal callout in debian/rules with "install -m 755". Wit just dh_install, it will end up as 644 in /usr/lib/hal and not work. The script is in the diff.gz, so on unpacking the source it will be 644.

Also, this debdiff now removes a large chunk from debian/patches/vmmouse_abs_valuator_axis.diff. I agree that it looks irrelevant, since ABS_VALUATOR_AXES is already hardcoded in vmmouse.c later in the patch, but the changelog should point out why. Or is that already everything required to make it work with current xorg? (♪ it's a kind of magic ♫ ?)

Tux (peter-hoogkamer) wrote :

Is this realy still a problem?? I am using Intrepid RC on Vmware Workstation 5.5.0 and do not have this problem. The mouse releases with Ctrl-Alt and when I click into the VM it grabs my mouse. This also works with the livecd, an upgrade from 8.04 to Intrepid RC and with the latest updates.

2.6.27-7-generic
1:12.5.1-1ubuntu5 from vmmouse

Tux [2008-10-24 10:25 -0000]:
> Is this realy still a problem?? I am using Intrepid RC on Vmware
> Workstation 5.5.0 and do not have this problem. The mouse releases with
> Ctrl-Alt and when I click into the VM it grabs my mouse. This also works
> with the livecd, an upgrade from 8.04 to Intrepid RC and with the latest
> updates.

That's the behaviour of the standard mouse driver, i. e. which isn't
aware at all about the virtualization. The point of vmmouse is that
you *don't* have to click into the VM first, you just have one mouse
pointer for both the host and the guest (works with VMWare and KVM,
not sure about VirtualBox).

Tux (peter-hoogkamer) wrote :

Ok, clear. Can I help solve this by testing or providing information?

Tux

Tux (peter-hoogkamer) wrote :

I have no mouse entry in my xorg.conf and lshal | grep mouse gives me the following result:

 info.capabilities = {'input', 'input.mouse'} (string list)
  info.product = 'Macintosh mouse button emulation' (string)
  input.product = 'Macintosh mouse button emulation' (string)
  info.product = 'IBM Enhanced (101/102-key, PS/2 mouse support)' (string)
  pnp.description = 'IBM Enhanced (101/102-key, PS/2 mouse support)' (string)
  info.linux.driver = 'psmouse' (string)
  info.capabilities = {'input', 'input.mouse'} (string list)

Am I able to use vmmouse for debugging purposes and if so how to do this?

Tux

Bryce Harrington (bryce) wrote :

Martin, I don't understand your directions in #18, but attached is my guess at what you mean?

Philip Langdale (langdalepl) wrote :

Bryce, diff looks good to me.

I'm attaching an improved version of the fdi file - it tries to detect the VMware virtual machine so the probe binary isn't actually called on real hardware. The probe is still required because a VM could have the mouse device disabled.

This is just an optimization - there's nothing functionally wrong with the existing fdi.

Martin Pitt (pitti) wrote :

Bryce,

I meant that you cannot use debian/xserver-xorg-input-vmmouse.install to install the hal callout, since the package ships it with 644 permissions (in the diff.gz). Thus the .install should only install the FDI, and drop the hal-probe-vmmouse line. debian/rules shuold then do

  install -D -m 755 debian/hal-probe-vmmouse debian/usr/bin/xserver-xorg-input-vmmouse/usr/lib/hal/hal-probe-vmmouse

Thanks for improving the changelog to explain the removed parts from vmmouse_abs_valuator_axis.diff.

However, it's still my understanding that we actually need to upgrade to 12.5.2, since with the current version and the hall callout+fdi mouse is just plain broken.

Philip, your new FDI file looks too VMWare specific. I believe vmmouse works just as well in kvm, doesn't it? (Sorry, I didn't respond to that on the hal ML).

Philip Langdale (langdalepl) wrote :

Martin,

Good point. As I said, I have no problems shipping the original fdi file - it will work just fine.

Helge Titlestad (helgedt) wrote :

In my opinion, this fix should not be sent out until bug 248521 is fixed. It's marked as fixed now (after 1:12.5.1-1ubuntu5 was pushed out), but several comments and my own observations shows that it's not fixed.

It's better that vmware users get the mouse driver (which kind of works) than that HAL detects the vmware driver (which does not work).

Philip Langdale (langdalepl) wrote :

Bryce has incorporated a more robust fix for 248521 into his diff for this bug.

Martin Pitt (pitti) wrote :

+ install -D -m 755 debian/hal-probe-vmmouse debian/usr/bin/xserver-xorg-input-vmmouse/usr/lib/hal/hal-probe-vmmouse

"debian/usr/bin/" is obviously wrong here, it's debian/PACKAGENAME, i. e. debian/xserver-xorg-input-vmmouse/usr...

Also, it's *still* not the new upstream version which fixes the actual driver.

While you are at changing the package, can you please put the VALUATOR... changelog entry part into its own line? It doesn't belong to the fdi/hal callout, but to vmmouse_abs_valuator_axis.diff.

Bryce Harrington (bryce) wrote :

Martin, sorry, I was just copying what you specified in your comment #25...

Regarding the upstream version, as comment #28 from the upstream developer points out, this patch carries the change which fixes the actual driver. The upstream changes were this one fix, plus a lot of autoconfage change meant to set the VALUATOR define. Near as I can tell, those autoconf changes do not actually work (neither in the upstream tarball that I tested, nor in my extraction of the autoconf settings).

However, in analyzing what the autoconf changes were attempting to do, it's just to enable the define when xserver 1.4 or newer is in use. Since our package already has a hard dependency on xserver 1.4, our patch is safe to just force the define directly.

Martin Pitt (pitti) wrote :

> Martin, sorry, I was just copying what you specified in your comment #25...

Argh, yeah, I'm a moron. Sorry. Looks good then.

Changed in xserver-xorg-input-vmmouse:
milestone: intrepid-updates → none
status: Triaged → Fix Committed
Martin Pitt (pitti) wrote :

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Tanker Bob (tankerbob) wrote :

Great work! I tested it with a Kubuntu 8.04.1 host, VMWare Workstation 6.5.0, Ubuntu 8.10 Intrepid guest with WMWare Tools 6.5.0 build 118116 installed. I installed the xserver-xorg-input-vmmouse fix from the intrepid-proposed repository, then restarted the virtual machine. The mouse now moves seamlessly between the guest and host. Thanks for fixing this issue.

Any hope for fixing the vsock module or the lack of cut-and-paste between host and guest?

Bruno Santos (bsantos) wrote :

I had a section for an aiptek tablet using the wacom driver that wasn't connected that started with 4/11 updates to give problems. X would consume ~40% CPU along with g-s-d ~30%, some settings applications would complain about g-s-d not being available (although it was running).

I first thought it was something wrong with some userside configuration, tried to clean stuff in gconf, etc, but nothing solved it. I then noticed > 300k errors in X log regarding the unavailability of the tablet so I tried to disable it in xorg.conf and the problems were gone.

Error opening /dev/input/aiptek_event : No such file or directory
(EE) xf86OpenSerial: Cannot open device /dev/input/aiptek_event
        No such file or directory.

Could have any of these changes provoke this? Can anyone try to create a xorg section for a missing device configured with sendcoreevents and check if the X server goes crazy?

Martin Pitt (pitti) wrote :

I confirm that with the old version I had to grab the input focus in kvm to use the mouse. With the -proposed version, the mouse works seamlessly between kvm guest and the host system.

Philip Langdale (langdalepl) wrote :

Package from -proposed works correctly in a VMware VM.

Bryce Harrington (bryce) wrote :

Thanks for confirming the changes fix the issue.

Please don't append additional unrelated issues to this bug report... this isn't a forum, it'll just add clutter. One issue per bug report please!

Changed in xserver-xorg-input-vmmouse:
status: Triaged → Fix Committed
Martin Pitt (pitti) wrote :

Intrepid-proposed copied to Jaunty.

Changed in xserver-xorg-input-vmmouse:
milestone: intrepid-updates → none
status: Fix Committed → Fix Released
milestone: none → intrepid-updates
Bryce Harrington (bryce) on 2008-11-08
Changed in xserver-xorg-input-vmmouse:
milestone: intrepid-updates → none
status: Fix Committed → Fix Released
status: Fix Released → Fix Committed

Same problems with VMWare Fusion and vmmouse_drv.so.

Can confirm update in proposed resolves the mouse problems.

Martin Pitt (pitti) wrote :

Copied to intrepid-updates.

Changed in xserver-xorg-input-vmmouse:
status: Fix Committed → Fix Released
elventear (elventear) wrote :

Does this issue happen with the current beta of Jaunty? I don't seem to be able to get vmmouse to work unless I disable AutoAddDevices.

To post a comment you must log in.