MOUSE_PS2_VMMOUSE and input/mice

Hi,

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

- Lauri

On 01/15/2016 11:39 AM, Lauri Kasanen wrote:

Hi,

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

- Lauri

Hi, Lauri.
What particular use-case is broken?

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

In the vmware gui there is a workaround, one can select 
edit->preferences->input->"Optimize mouse for games"->Always

This will send events through the relative USB mouse, and if there is no
USB controller in the VM, through the relative MOUSE_PS2_VMMOUSE

The other option is to limit the number of protocols the PS2 driver
checks for and avoid enabling the vmmmouse functionality. There is a
kernel module option for that, although I can't remember it offhand.

We can't send both relative and absolute events simultaneously since
that would confuse the X server severely.

/Thomas

On Fri, 15 Jan 2016 12:08:51 +0100
Thomas Hellstrom [off-list ref] wrote:

quoted

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

Hi, Lauri.
What particular use-case is broken?

VMWare + 4.2 kernel + Xvesa. This was reported for the current TinyCore
beta, which has that kernel.

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

In the vmware gui there is a workaround, one can select 
edit->preferences->input->"Optimize mouse for games"->Always

This will send events through the relative USB mouse, and if there is no
USB controller in the VM, through the relative MOUSE_PS2_VMMOUSE

The other option is to limit the number of protocols the PS2 driver
checks for and avoid enabling the vmmmouse functionality. There is a
kernel module option for that, although I can't remember it offhand.

We can't send both relative and absolute events simultaneously since
that would confuse the X server severely.

Yeah, I know of the psmouse.proto=imps workaround. But requiring either
bootcodes or VM setting tweaks is not nice, as what the users see will
be "distro version X worked in my VMWare, in version Y the mouse does
not work".

If we instead disable MOUSE_PS2_VMMOUSE, I assume a future
xf86-input-vmmouse version will drop support for the userspace-side
mouse synchronization, and then VMWare+Xorg users will suffer.

Can you think of any solution that would detect things at runtime?

- Lauri

On 01/15/2016 12:23 PM, Lauri Kasanen wrote:

On Fri, 15 Jan 2016 12:08:51 +0100
Thomas Hellstrom [off-list ref] wrote:

quoted

quoted

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

Hi, Lauri.
What particular use-case is broken?

VMWare + 4.2 kernel + Xvesa. This was reported for the current TinyCore
beta, which has that kernel.

quoted

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

In the vmware gui there is a workaround, one can select 
edit->preferences->input->"Optimize mouse for games"->Always

This will send events through the relative USB mouse, and if there is no
USB controller in the VM, through the relative MOUSE_PS2_VMMOUSE

The other option is to limit the number of protocols the PS2 driver
checks for and avoid enabling the vmmmouse functionality. There is a
kernel module option for that, although I can't remember it offhand.

We can't send both relative and absolute events simultaneously since
that would confuse the X server severely.

Yeah, I know of the psmouse.proto=imps workaround. But requiring either
bootcodes or VM setting tweaks is not nice, as what the users see will
be "distro version X worked in my VMWare, in version Y the mouse does
not work".

If we instead disable MOUSE_PS2_VMMOUSE, I assume a future
xf86-input-vmmouse version will drop support for the userspace-side
mouse synchronization, and then VMWare+Xorg users will suffer.

At present, MOUSE_PS2_VMMOUSE is only needed if you need to support
rootless Xorg or a native compositor without vmmouse driver in absolute
mode, like gnome-shell/wayland. If you're fine with that, perhaps
disabling the in-kernel vmmouse driver is the best option for now.
xf86-input-vmmouse will remain as-is for the forseeable future.

Guessing what protocol the client needs is always tricky. What we could
perhaps do is to try to detect the number of open clients on the
absolute mouse device and if == 0 tell the host to send relative events.
However, the host is not required to obey that request and I'm not sure
KVM/QEMU even implements that. One option would perhaps be to turn off
vmmouse and just forward ps2 data in that case.

However, I'm not sure there are hooks in the ps2 driver to detect the
number of open clients for a particular device...

/Thomas

Can you think of any solution that would detect things at runtime?

- Lauri

On Fri, Jan 15, 2016 at 04:45:28PM +0100, Thomas Hellstrom wrote:

On 01/15/2016 12:23 PM, Lauri Kasanen wrote:

quoted

On Fri, 15 Jan 2016 12:08:51 +0100
Thomas Hellstrom [off-list ref] wrote:

quoted

quoted

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

Hi, Lauri.
What particular use-case is broken?

VMWare + 4.2 kernel + Xvesa. This was reported for the current TinyCore
beta, which has that kernel.

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

quoted

quoted

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

No, this is not correct, mousedev (the one that provides
/dev/input/mouseX and /dev/input/mice) should bind to absolute device
exported by vmmouse on this rule:

	{
		.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
			INPUT_DEVICE_ID_MATCH_KEYBIT |
			INPUT_DEVICE_ID_MATCH_ABSBIT,
		.evbit = { BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) },
		.keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
		.absbit = { BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) },
	},	/* Mouse-like device with absolute X and Y but ordinary
		   clicks, like hp ILO2 High Performance mouse */

and it should convert absolute events to relative motion.

Lauri, can you please check your /proc/bus/input/devices and see if
"mouse" handlers are attached to vmmouse devices (could you also post
output of cat /proc/bus/input/devices here?).

By the way, could it be that we do have events, but the deltas are too
small since the declared axis sizes are too big. Do you see garbage
coming if you do "cat /dev/input/mice" and try moving pointer?

Thanks.

-- 
Dmitry

On 01/15/2016 06:50 PM, Dmitry Torokhov wrote:

On Fri, Jan 15, 2016 at 04:45:28PM +0100, Thomas Hellstrom wrote:

quoted

On 01/15/2016 12:23 PM, Lauri Kasanen wrote:

quoted

On Fri, 15 Jan 2016 12:08:51 +0100
Thomas Hellstrom [off-list ref] wrote:

quoted

quoted

Seems the new and shiny VMWare mouse driver does not pass events
to /dev/input/mice, rudely breaking userspace that doesn't
support absolute input devices.

Can this be changed? Would there be any downside to passing those
events?

Hi, Lauri.
What particular use-case is broken?

VMWare + 4.2 kernel + Xvesa. This was reported for the current TinyCore
beta, which has that kernel.

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

quoted

quoted

quoted

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

No, this is not correct, mousedev (the one that provides
/dev/input/mouseX and /dev/input/mice) should bind to absolute device
exported by vmmouse on this rule:

	{
		.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
			INPUT_DEVICE_ID_MATCH_KEYBIT |
			INPUT_DEVICE_ID_MATCH_ABSBIT,
		.evbit = { BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) },
		.keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
		.absbit = { BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) },
	},	/* Mouse-like device with absolute X and Y but ordinary
		   clicks, like hp ILO2 High Performance mouse */

and it should convert absolute events to relative motion.

Ah. Thanks for clarifying!

/Thomas

Hi,

Here's the /proc/bus/input/devices output. Also attaching the kernel
config in case it'd be useful.

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
U: Uniq=
H: Handlers=kbd event0 
B: PROP=0
B: EV=3
B: KEY=100000 0 0 0

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input1
U: Uniq=
H: Handlers=sysrq kbd leds event1 
B: PROP=0
B: EV=120013
B: KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe
B: MSC=10
B: LED=7

I: Bus=0011 Vendor=0002 Product=0013 Version=0006
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=event2 
B: PROP=0
B: EV=b
B: KEY=70000 0 0 0 0 0 0 0 0
B: ABS=3

I: Bus=0011 Vendor=0002 Product=0013 Version=0006
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input0
S: Sysfs=/devices/platform/i8042/serio1/input/input3
U: Uniq=
H: Handlers=mouse0 event3 
B: PROP=1
B: EV=7
B: KEY=30000 0 0 0 0 0 0 0 0
B: REL=103

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/devices/platform/pcspkr/input/input5
U: Uniq=
H: Handlers=kbd event4 
B: PROP=0
B: EV=40001
B: SND=6

I: Bus=0003 Vendor=0e0f Product=0003 Version=0110
N: Name="VMware VMware Virtual USB Mouse"
P: Phys=usb-0000:02:00.0-1/input0
S:
Sysfs=/devices/pci0000:00/0000:00:11.0/0000:02:00.0/usb2/2-1/2-1:1.0/0003:0E0F:0003.0001/input/input6
U: Uniq= H: Handlers=mouse1 event5 
B: PROP=0
B: EV=17
B: KEY=ff0000 0 0 0 0 0 0 0 0
B: REL=103
B: MSC=10

- Lauri

On Sat, Jan 16, 2016 at 05:39:45PM +0200, Lauri Kasanen wrote:

Hi,

Here's the /proc/bus/input/devices output. Also attaching the kernel
config in case it'd be useful.

...

I: Bus=0011 Vendor=0002 Product=0013 Version=0006
N: Name="VirtualPS/2 VMware VMMouse"
P: Phys=isa0060/serio1/input1
S: Sysfs=/devices/platform/i8042/serio1/input/input4
U: Uniq=
H: Handlers=event2 
B: PROP=0
B: EV=b
B: KEY=70000 0 0 0 0 0 0 0 0

So mousedev indeed did not bind to the absolute portion of the device.
Please try the patch below.

-- 
Dmitry


Input: vmmouse - fix absolute device registration

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We should set device's capabilities first, and then register it, otherwise
various handlers already present in the kernel will not be able to connect
to the device.

Reported-by: Lauri Kasanen <redacted>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
---
 drivers/input/mouse/vmmouse.c |   13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index e272f06..a3f0f5a 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c

@@ -458,8 +458,6 @@ int vmmouse_init(struct psmouse *psmouse)
 	priv->abs_dev = abs_dev;
 	psmouse->private = priv;
 
-	input_set_capability(rel_dev, EV_REL, REL_WHEEL);
-
 	/* Set up and register absolute device */
 	snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
 		 psmouse->ps2dev.serio->phys);

@@ -475,10 +473,6 @@ int vmmouse_init(struct psmouse *psmouse)
 	abs_dev->id.version = psmouse->model;
 	abs_dev->dev.parent = &psmouse->ps2dev.serio->dev;
 
-	error = input_register_device(priv->abs_dev);
-	if (error)
-		goto init_fail;
-
 	/* Set absolute device capabilities */
 	input_set_capability(abs_dev, EV_KEY, BTN_LEFT);
 	input_set_capability(abs_dev, EV_KEY, BTN_RIGHT);

@@ -488,6 +482,13 @@ int vmmouse_init(struct psmouse *psmouse)
 	input_set_abs_params(abs_dev, ABS_X, 0, VMMOUSE_MAX_X, 0, 0);
 	input_set_abs_params(abs_dev, ABS_Y, 0, VMMOUSE_MAX_Y, 0, 0);
 
+	error = input_register_device(priv->abs_dev);
+	if (error)
+		goto init_fail;
+
+	/* Add wheel capability to the relative device */
+	input_set_capability(rel_dev, EV_REL, REL_WHEEL);
+
 	psmouse->protocol_handler = vmmouse_process_byte;
 	psmouse->disconnect = vmmouse_disconnect;
 	psmouse->reconnect = vmmouse_reconnect;

On Sat, 16 Jan 2016 10:16:35 -0800
Dmitry Torokhov [off-list ref] wrote:

So mousedev indeed did not bind to the absolute portion of the device.
Please try the patch below.

Hi,

The tester reports the patch works. It has some issues in that pixels
moved in-VM do not match pixels moved in the host screen, but at least
the mouse moves now.

- Lauri

On Fri, 15 Jan 2016 09:50:40 -0800
Dmitry Torokhov [off-list ref] wrote:

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

TinyCore sends their regards, and tells they will consider evdev when
Xorg + evdev + paraphelia can total less than 650kb.

quoted

quoted

quoted

I'm assuming what's happening is that only the relative device gets
recognized as a mouse, and by default we don't send events through that
device.

No, this is not correct, mousedev (the one that provides
/dev/input/mouseX and /dev/input/mice) should bind to absolute device
exported by vmmouse on this rule:

	{
		.flags = INPUT_DEVICE_ID_MATCH_EVBIT |
			INPUT_DEVICE_ID_MATCH_KEYBIT |
			INPUT_DEVICE_ID_MATCH_ABSBIT,
		.evbit = { BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS) },
		.keybit = { [BIT_WORD(BTN_LEFT)] = BIT_MASK(BTN_LEFT) },
		.absbit = { BIT_MASK(ABS_X) | BIT_MASK(ABS_Y) },
	},	/* Mouse-like device with absolute X and Y but ordinary
		   clicks, like hp ILO2 High Performance mouse */

and it should convert absolute events to relative motion.

Lauri, can you please check your /proc/bus/input/devices and see if
"mouse" handlers are attached to vmmouse devices (could you also post
output of cat /proc/bus/input/devices here?).

By the way, could it be that we do have events, but the deltas are too
small since the declared axis sizes are too big. Do you see garbage
coming if you do "cat /dev/input/mice" and try moving pointer?

The reporter said there was no output at all when
catting /dev/input/mice. I'll forward the /proc/bus/input/devices
question.

- Lauri

On Sat, Jan 16, 2016 at 10:57:35AM +0200, Lauri Kasanen wrote:

On Fri, 15 Jan 2016 09:50:40 -0800
Dmitry Torokhov [off-list ref] wrote:

quoted

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

TinyCore sends their regards, and tells they will consider evdev when
Xorg + evdev + paraphelia can total less than 650kb.

I do not think you are doing your users any favors by limiting them to
PS/2 emulation. For desktops, unless they only use basic mice mousedev
emulation does not work well for neither touchpads, nor tablets, nor
touchscreens.  And for appliances you do not need mouse at all. Maybe if
you targeting kiosks with limited UI it will work for a bit. I wonder
how long Xorg will be keeping lights on for mouse_drv.

I am tempted to deprecate mousedev and maybe joydev as well. They were
supposed to fill the gap between then current applications and kernel,
but that was 10+ years ago.

Thanks.

-- 
Dmitry

On Sat, 16 Jan 2016 10:30:08 -0800
Dmitry Torokhov [off-list ref] wrote:

quoted

quoted

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

TinyCore sends their regards, and tells they will consider evdev when
Xorg + evdev + paraphelia can total less than 650kb.

I do not think you are doing your users any favors by limiting them to
PS/2 emulation. For desktops, unless they only use basic mice mousedev
emulation does not work well for neither touchpads, nor tablets, nor
touchscreens.  And for appliances you do not need mouse at all. Maybe if
you targeting kiosks with limited UI it will work for a bit. I wonder
how long Xorg will be keeping lights on for mouse_drv.

I am tempted to deprecate mousedev and maybe joydev as well. They were
supposed to fill the gap between then current applications and kernel,
but that was 10+ years ago.

Hi,

It's a choice we leave up to the users. The majority uses normal
desktops with normal mice, touch screens and tablets tend to be a
rarity in our userbase. So we can serve the majority without the bloat
of Xorg, but those who need it can install it.

That's why I was asking for a runtime way - the default should work,
but so should VMWare's nicer mouse integration when Xorg is installed.
That concern was resolved with the statement the older support is not
being considered for removal. The original issue will be solved by
disabling VMMOUSE in our kernel.

- Lauri

On Sat, Jan 16, 2016 at 09:10:11PM +0200, Lauri Kasanen wrote:

On Sat, 16 Jan 2016 10:30:08 -0800
Dmitry Torokhov [off-list ref] wrote:

quoted

quoted

quoted

Although we will make vmmouse work with /dev/input/mice, could you
please tell TinyCore that 90s are calling and they want their mouse
technology back? And tell them to switch to switch to evdev X driver.

TinyCore sends their regards, and tells they will consider evdev when
Xorg + evdev + paraphelia can total less than 650kb.

I do not think you are doing your users any favors by limiting them to
PS/2 emulation. For desktops, unless they only use basic mice mousedev
emulation does not work well for neither touchpads, nor tablets, nor
touchscreens.  And for appliances you do not need mouse at all. Maybe if
you targeting kiosks with limited UI it will work for a bit. I wonder
how long Xorg will be keeping lights on for mouse_drv.

I am tempted to deprecate mousedev and maybe joydev as well. They were
supposed to fill the gap between then current applications and kernel,
but that was 10+ years ago.

Hi,

It's a choice we leave up to the users. The majority uses normal
desktops with normal mice, touch screens and tablets tend to be a
rarity in our userbase. So we can serve the majority without the bloat
of Xorg, but those who need it can install it.

So people who do not need Xorg do not need the mouse either, right? I am
still confused who your target user base is.

That's why I was asking for a runtime way - the default should work,
but so should VMWare's nicer mouse integration when Xorg is installed.
That concern was resolved with the statement the older support is not
being considered for removal. The original issue will be solved by
disabling VMMOUSE in our kernel.

I guess you can disable this (bit then you need to carry Xorg vmmouse
driver), but then you'll still have to pay the piper once Xorg drops
root support and X vmmouse driver will not be able to access the
hypervisor port.

Thanks.

-- 
Dmitry

On Sat, 16 Jan 2016 11:38:08 -0800
Dmitry Torokhov [off-list ref] wrote:

quoted

quoted

I do not think you are doing your users any favors by limiting them to
PS/2 emulation. For desktops, unless they only use basic mice mousedev
emulation does not work well for neither touchpads, nor tablets, nor
touchscreens.  And for appliances you do not need mouse at all. Maybe if
you targeting kiosks with limited UI it will work for a bit. I wonder
how long Xorg will be keeping lights on for mouse_drv.

I am tempted to deprecate mousedev and maybe joydev as well. They were
supposed to fill the gap between then current applications and kernel,
but that was 10+ years ago.

It's a choice we leave up to the users. The majority uses normal
desktops with normal mice, touch screens and tablets tend to be a
rarity in our userbase. So we can serve the majority without the bloat
of Xorg, but those who need it can install it.

So people who do not need Xorg do not need the mouse either, right? I am
still confused who your target user base is.

By default we ship Xvesa, as mentioned. It's a different X
server, very much smaller. It works with practically every graphics
card, and support for normal mice is quite enough for the majority.

quoted

That's why I was asking for a runtime way - the default should work,
but so should VMWare's nicer mouse integration when Xorg is installed.
That concern was resolved with the statement the older support is not
being considered for removal. The original issue will be solved by
disabling VMMOUSE in our kernel.

I guess you can disable this (bit then you need to carry Xorg vmmouse
driver), but then you'll still have to pay the piper once Xorg drops
root support and X vmmouse driver will not be able to access the
hypervisor port.

I believe Wayland will have become mainstream before that happens ;)

- Lauri