* MOUSE_PS2_VMMOUSE and input/mice @ 2016-01-15 10:39 Lauri Kasanen 2016-01-15 11:08 ` Thomas Hellstrom 0 siblings, 1 reply; 14+ messages in thread From: Lauri Kasanen @ 2016-01-15 10:39 UTC (permalink / raw) To: linux-input; +Cc: thellstrom, dmitry.torokhov 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 10:39 MOUSE_PS2_VMMOUSE and input/mice Lauri Kasanen @ 2016-01-15 11:08 ` Thomas Hellstrom 2016-01-15 11:23 ` Lauri Kasanen 0 siblings, 1 reply; 14+ messages in thread From: Thomas Hellstrom @ 2016-01-15 11:08 UTC (permalink / raw) To: Lauri Kasanen, linux-input; +Cc: dmitry.torokhov 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 11:08 ` Thomas Hellstrom @ 2016-01-15 11:23 ` Lauri Kasanen 2016-01-15 15:45 ` Thomas Hellstrom 0 siblings, 1 reply; 14+ messages in thread From: Lauri Kasanen @ 2016-01-15 11:23 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: linux-input, dmitry.torokhov On Fri, 15 Jan 2016 12:08:51 +0100 Thomas Hellstrom <thellstrom@vmware.com> wrote: > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 11:23 ` Lauri Kasanen @ 2016-01-15 15:45 ` Thomas Hellstrom 2016-01-15 17:50 ` Dmitry Torokhov 0 siblings, 1 reply; 14+ messages in thread From: Thomas Hellstrom @ 2016-01-15 15:45 UTC (permalink / raw) To: Lauri Kasanen; +Cc: linux-input, dmitry.torokhov On 01/15/2016 12:23 PM, Lauri Kasanen wrote: > On Fri, 15 Jan 2016 12:08:51 +0100 > Thomas Hellstrom <thellstrom@vmware.com> wrote: > >>> 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. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 15:45 ` Thomas Hellstrom @ 2016-01-15 17:50 ` Dmitry Torokhov 2016-01-15 18:22 ` Thomas Hellstrom 2016-01-16 8:57 ` Lauri Kasanen 0 siblings, 2 replies; 14+ messages in thread From: Dmitry Torokhov @ 2016-01-15 17:50 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: Lauri Kasanen, linux-input On Fri, Jan 15, 2016 at 04:45:28PM +0100, Thomas Hellstrom wrote: > On 01/15/2016 12:23 PM, Lauri Kasanen wrote: > > On Fri, 15 Jan 2016 12:08:51 +0100 > > Thomas Hellstrom <thellstrom@vmware.com> wrote: > > > >>> 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. > > > >> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 17:50 ` Dmitry Torokhov @ 2016-01-15 18:22 ` Thomas Hellstrom 2016-01-16 15:39 ` Lauri Kasanen 2016-01-16 8:57 ` Lauri Kasanen 1 sibling, 1 reply; 14+ messages in thread From: Thomas Hellstrom @ 2016-01-15 18:22 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Lauri Kasanen, linux-input On 01/15/2016 06:50 PM, Dmitry Torokhov wrote: > On Fri, Jan 15, 2016 at 04:45:28PM +0100, Thomas Hellstrom wrote: >> On 01/15/2016 12:23 PM, Lauri Kasanen wrote: >>> On Fri, 15 Jan 2016 12:08:51 +0100 >>> Thomas Hellstrom <thellstrom@vmware.com> wrote: >>> >>>>> 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. > >>>> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 18:22 ` Thomas Hellstrom @ 2016-01-16 15:39 ` Lauri Kasanen 2016-01-16 18:16 ` Dmitry Torokhov 0 siblings, 1 reply; 14+ messages in thread From: Lauri Kasanen @ 2016-01-16 15:39 UTC (permalink / raw) To: Thomas Hellstrom; +Cc: Dmitry Torokhov, linux-input [-- Attachment #1: Type: text/plain, Size: 1739 bytes --] 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 [-- Attachment #2: config-4.2.7.xz --] [-- Type: application/octet-stream, Size: 29840 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 15:39 ` Lauri Kasanen @ 2016-01-16 18:16 ` Dmitry Torokhov 2016-01-18 8:30 ` Lauri Kasanen 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Torokhov @ 2016-01-16 18:16 UTC (permalink / raw) To: Lauri Kasanen; +Cc: Thomas Hellstrom, linux-input 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 <cand@gmx.com> 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; ^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 18:16 ` Dmitry Torokhov @ 2016-01-18 8:30 ` Lauri Kasanen 0 siblings, 0 replies; 14+ messages in thread From: Lauri Kasanen @ 2016-01-18 8:30 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Thomas Hellstrom, linux-input On Sat, 16 Jan 2016 10:16:35 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-15 17:50 ` Dmitry Torokhov 2016-01-15 18:22 ` Thomas Hellstrom @ 2016-01-16 8:57 ` Lauri Kasanen 2016-01-16 18:30 ` Dmitry Torokhov 1 sibling, 1 reply; 14+ messages in thread From: Lauri Kasanen @ 2016-01-16 8:57 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Thomas Hellstrom, linux-input On Fri, 15 Jan 2016 09:50:40 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> 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. > > >> 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 8:57 ` Lauri Kasanen @ 2016-01-16 18:30 ` Dmitry Torokhov 2016-01-16 19:10 ` Lauri Kasanen 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Torokhov @ 2016-01-16 18:30 UTC (permalink / raw) To: Lauri Kasanen; +Cc: Thomas Hellstrom, linux-input On Sat, Jan 16, 2016 at 10:57:35AM +0200, Lauri Kasanen wrote: > On Fri, 15 Jan 2016 09:50:40 -0800 > Dmitry Torokhov <dmitry.torokhov@gmail.com> 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. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 18:30 ` Dmitry Torokhov @ 2016-01-16 19:10 ` Lauri Kasanen 2016-01-16 19:38 ` Dmitry Torokhov 0 siblings, 1 reply; 14+ messages in thread From: Lauri Kasanen @ 2016-01-16 19:10 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Thomas Hellstrom, linux-input On Sat, 16 Jan 2016 10:30:08 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> 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. > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 19:10 ` Lauri Kasanen @ 2016-01-16 19:38 ` Dmitry Torokhov 2016-01-17 9:32 ` Lauri Kasanen 0 siblings, 1 reply; 14+ messages in thread From: Dmitry Torokhov @ 2016-01-16 19:38 UTC (permalink / raw) To: Lauri Kasanen; +Cc: Thomas Hellstrom, linux-input On Sat, Jan 16, 2016 at 09:10:11PM +0200, Lauri Kasanen wrote: > On Sat, 16 Jan 2016 10:30:08 -0800 > Dmitry Torokhov <dmitry.torokhov@gmail.com> 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. > > > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MOUSE_PS2_VMMOUSE and input/mice 2016-01-16 19:38 ` Dmitry Torokhov @ 2016-01-17 9:32 ` Lauri Kasanen 0 siblings, 0 replies; 14+ messages in thread From: Lauri Kasanen @ 2016-01-17 9:32 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Thomas Hellstrom, linux-input On Sat, 16 Jan 2016 11:38:08 -0800 Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > 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. > > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-01-18 8:30 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-01-15 10:39 MOUSE_PS2_VMMOUSE and input/mice Lauri Kasanen 2016-01-15 11:08 ` Thomas Hellstrom 2016-01-15 11:23 ` Lauri Kasanen 2016-01-15 15:45 ` Thomas Hellstrom 2016-01-15 17:50 ` Dmitry Torokhov 2016-01-15 18:22 ` Thomas Hellstrom 2016-01-16 15:39 ` Lauri Kasanen 2016-01-16 18:16 ` Dmitry Torokhov 2016-01-18 8:30 ` Lauri Kasanen 2016-01-16 8:57 ` Lauri Kasanen 2016-01-16 18:30 ` Dmitry Torokhov 2016-01-16 19:10 ` Lauri Kasanen 2016-01-16 19:38 ` Dmitry Torokhov 2016-01-17 9:32 ` Lauri Kasanen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.