vmmouse doesn't work with input hotplug

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.

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

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.

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.

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.

Martin, could you take a brief look at this?

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

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.

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.

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

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

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)

More than one way to skin a cat...

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

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 ♫ ?)

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

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

Tux

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

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

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.

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

Martin,

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

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

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

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

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, sorry, I was just copying what you specified in your comment #25...

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

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!

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?

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?

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.

Package from -proposed works correctly in a VMware VM.

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!

Intrepid-proposed copied to Jaunty.

Same problems with VMWare Fusion and vmmouse_drv.so.

Can confirm update in proposed resolves the mouse problems.

Copied to intrepid-updates.

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.