Bug 93846

according to this your touchpad is 102x56mm, is this correct?

please run the touchpad-edge-detector tool as well to make sure the range reflects what the device actually sends.

Yeah the size is ok though there is a little deviation of very few millimetres from my measurement. (touchpad-edge-detector is able to detect the entire resolution)

I further checked the behaviour with synaptics driver and also there I see that small movements lead to no effective moving of the cursor, Now I can better specify what makes my user experience different between the two drivers.
In synaptics the cursor speed depends on the velocity I'm moving the finger on my clickpad. It feels like the resolution is changing along with the finger velocity.
I.e. slow movement allows me fine positioning of the cursor, while fast movements allows the covering of the entire screen. I'm experiencing a flat behaviour instead under libinput. That is, cursor speed does not depends on the finger velocity.
I tried to change acceleration options with xinput according to arch wiki page
"Mouse_acceleration" with no results at all.
Is this property not yet implemented? Or is it software disabled on my specific clickpad?

The second problem is still in place. Scrolling leads to large jump.

First: the arch wiki page [1] is out of date, most of this won't work on libinput devices since we moved the acceleration into libinput. You'll need to set the "libinput Accel Speed" property to a value between [-1, 1], where anything > 0 is faster than the default

[1] https://wiki.archlinux.org/index.php/Mouse_acceleration


I looked at your recording, and my calculations say you've moved your scroll motion by 4.5mm. That's not a lot, but libinput-debug-event says libinput is sending about ca 30 small scroll events, with a value of 1.48 pixels each (except two are 3px and one is 0.37px). Can you run libinput-debug-event and match the output with the visual output? maybe the events are lost in the xorg driver or the server?

the finger movement before the scroll recording too shows a movement of less than 1mm. that's a pretty tiny movement, and half of that would be swallowed by the hysteresis of 0.5mm. Having said that, this is extremely fine-grained movement, is this really how you interact with the touchpad?

Created attachment 121347 [details]
record of libinput-debug

>>> is this really how you interact with the touchpad?

Actually it is not, although I was trying to manually compensate for the odd settings in gnome. I've made some search and I found out there is no way to influence the mouse/touchpad settings in gnome on wayland up to day. The mouse settings panel only allows adjustment of the cursor speed and I've checked what options were available in gnome-settings-daemon through dconf, but also there I'm not able to find "libinput Accel Speed".
  So for now the solution consists in setting the speed to the minimum to have better control.

>>> Can you run libinput-debug-event and match the output with the visual output?
>>> maybe the events are lost in the xorg driver or the server?

I ran libinput-debug-event filtered on POINTER_AXIS, please find it attached.
It looks fine to me; no jump is to be seen. Nevertheless in the graphical environment, jumps occurs during scrolling. I made at the same time of the libinput-debug-event a screencast for a gtk scrolled window to highlight the jumps, do you want me to attach it here?

yes please, it should help illustrate the problem.

recent gnome version have a org.gnome.desktop.peripherals.touchpad speed setting that adjusts the libinput accel speed. That is the only knob available right now (both in gnome and libinput). if you reduce that to the minimum, then you get a slowdown of the motion, in addition to a flat profile. See
http://wayland.freedesktop.org/libinput/doc/latest/pointer-acceleration.html

This makes it virtually impossible for me to debug what's going on, at least for this bug I need you to leave the speed at 0.0 so we talk about the same behaviour. Please do that, then restate the bug and why you had to reduce the speed. We should be able to address that, so reducing the speed becomes a matter of personal preference vs. something to work around broken behaviour.

Created attachment 121380 [details]
scrolling jump

I set the touchpad speed to 0.0.

I try to restate the problem in different words. (Sorry this sort of problems are hard to describe).

Well the problem is that I'm not able to properly point a target. I always over/undershoot it.  Let's consider this example.

I -slowly- move the finger from the top of the touchpad to the bottom (no movement on the x-axis). The cursor will move consequently from a point (x1,y1) to (x1,y2). 

Now I repeat the same movement on the touchpad but -faster-. Again the cursor on the screen moves from (x1,y1) to (x1,y2). 

This is not the behaviour I'd expect. 
When I move the finger faster I expect the cursor to reach a point (x1,y3) with y3 > y2. This is exactly what happens in synaptics driver. The range of the cursor movement on the screen depends on the speed I'm moving my finger on the touchpad.
(Note: I restricted the movement on the y axis albeit the problem applies generally)


In the previous comment there is attached a short video of the odd scrolling behaviour.

try the hysteresis-removal patch from bug 93503, this should help with the scroll jumps. if that doesn't fix it, please split the bugs into a scroll and a movement bug, it gets too confusing otherwise.

Note that the touchpad motion you describe is expected when you set the acceleration to the minimum - which you had before. This should not happen when you have the touchpad on 0.0 or higher though, the pointer will get accelerated then on faster motion. So do you still see this behaviour now that you've changed the speed?

I have the same kind of behavior on my HP Chromekook 14 (Falco) on Fedora 23.
The cursor is "shaking" when I try to make a precise movement.

What infos should I give to help ?

The Falco has a Cyapa touchpad that should have the hysteresis applied and thus remove that shaking cursor. Does LIBINPUT_MODEL_CYAPA show in udevadm info /sys/class/input/eventX for your device?

Here is the output of "udevadm info /sys/class/input/event8"

P: /devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input8/event8
N: input/event8
S: input/by-path/pci-0000:00:15.1-event-mouse
E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-event-mouse
E: DEVNAME=/dev/input/event8
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input8/event8
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=64
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=98
E: ID_PATH=pci-0000:00:15.1
E: ID_PATH_TAG=pci-0000_00_15_1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=18/0/0/1:i2c-7-0067
E: MAJOR=13
E: MINOR=72
E: SUBSYSTEM=input
E: USEC_INITIALIZED=4692248

As you can see "LIBINPUT_MODEL_CYAPA" is not present. What does this mean ?

I don't know if it's related but the cursor "jump" sometimes too. A little like described here https://bugs.freedesktop.org/show_bug.cgi?id=91695. It's often when I want to make a click with the bottom left touchpad button, sometimes at the moment I touch the button the cursor jump at the bottom left of the sreen.

Please file a separate bug for the cursor jump, I'll likely need extra recordings for that one and they are often touchpad-specific.

For this bug: run evemu-describe against the touchpad and attach it here, that has a dmi string that we can then check for

(In reply to Peter Hutterer from comment #13)
> Please file a separate bug for the cursor jump, I'll likely need extra
> recordings for that one and they are often touchpad-specific.

Done, see here https://bugs.freedesktop.org/show_bug.cgi?id=94910

> For this bug: run evemu-describe against the touchpad and attach it here,
> that has a dmi string that we can then check for

Here is the pitput of evemu-describe 

http://pastebin.com/T49aLgQs

Created attachment 122888 [details] [review]
0001-udev-update-the-hwdb-matches-to-avoid-use-of-and.patch

Try this one, this should apply the tag now and stop the wobbling

That don't work :( To be sure that I try correctly this is the file I patched :

/usr/lib/udev/hwdb.d/90-libinput-model-quirks.hwdb

And this is the content of the file :

http://pastebin.com/0cXDwRzE

I rebooted too.

did it apply the property to the device? udevadm info /sys/class/input/eventX with your event node. also: you'll need to run sudo udevadm hwdb --update after installing the hwdb file.

That work ! I needed to run "sudo udevadm hwdb --update" and reboot. Here is the output of "udevadm info /sys/class/input/event12"

P: /devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input12/event12
N: input/event12
S: input/by-path/pci-0000:00:15.1-event-mouse
E: DEVLINKS=/dev/input/by-path/pci-0000:00:15.1-event-mouse
E: DEVNAME=/dev/input/event12
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input12/event12
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=64
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=98
E: ID_PATH=pci-0000:00:15.1
E: ID_PATH_TAG=pci-0000_00_15_1
E: ID_SERIAL=noserial
E: LIBINPUT_DEVICE_GROUP=18/0/0/1:i2c-7-0067
E: LIBINPUT_MODEL_CHROMEBOOK=1
E: LIBINPUT_MODEL_CYAPA=1
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=4616336

However I lost the right click. That's understandable because it's the way chromebook touchpad works but how can I re-enable it ?

Thanks !

right-click still works by using a two-finger click, but the chromebooks default to the clickfinger method. If you're using GNOME, run this:

gsettings set org.gnome.desktop.peripherals.touchpad click-method 'areas'

otherwise check man libinput for the xf86-input-libinput driver option to set the click method

I'm on Gnome and I first tried that :

/etc/X11/xorg.conf.d/50-cros-touchpad.conf
	Section "InputClass"
	        Identifier "MyTouchpad"
	        MatchIsTouchpad "on"
	        Driver "libinput"
	        Option "ClickMethod" "buttonareas"
	EndSection

But that didn't worked. So I tried the gsettings command and that worked. The right click is back. Thanks !

Just for my knowledge, is Gnome overwrite the xorg setting or I didn't use the right one ?

(In reply to Peter Hutterer from comment #19)
> right-click still works by using a two-finger click, but the chromebooks
> default to the clickfinger method. If you're using GNOME, run this:
> 
> gsettings set org.gnome.desktop.peripherals.touchpad click-method 'areas'
> 
> otherwise check man libinput for the xf86-input-libinput driver option to
> set the click method

From what I found it seems that Gnome override xorg.conf.d settings. Is that right ?

correct. the xorg.conf.d settings are server-wide, the gnome settings are per session and thus override the xorg.conf settings

Ok thank you very much. Do you know when your patch will be merged into libinput and in Fedora ?

commit 8ebe33827e52816bdb1da4873c98168a8fcc2ae4
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Wed Apr 13 11:15:56 2016 +1000

    udev: update the hwdb matches to avoid use of ( and )

Great, I guess it will be available for libinput 1.2.4.
Thank you again !

I lost track, sorry - what's the remaining problem of this bug now?

No more problem here for me. Thanks !

ok, closing. thanks!