Bug 96259

I'll need an evemu-record of such a click sequence please. Any special configuration you have? and what version of libinput?

Created attachment 124261 [details]
imprecise1.txt

Created attachment 124262 [details]
imprecise2.txt

Created attachment 124263 [details]
imprecise3.txt

(In reply to Peter Hutterer from comment #1)
> I'll need an evemu-record of such a click sequence please. Any special
> configuration you have? and what version of libinput?

I have made 3 evemu-record :
- imprecise1.txt and imprecise2.txt are without moving the cursor. Just a click.
- imprecise3.txt is with moving the cursor before clicking.

No special configuration. I have libinput 1.2.4 (Fedora 23).

Thanks !

(In reply to Paviluf from comment #5)
> - imprecise1.txt and imprecise2.txt are without moving the cursor. Just a
> click.

I don't get any motion events here, just the click. so this seems to be working fine?

> - imprecise3.txt is with moving the cursor before clicking.

this one has a massive cursor jump in it which is a problem with all the cyapas (see Bug 94910). This is partially addressed in libinput 1.3 where we discard this jump now. There's other movement in here but that looks to be your finger movement.

run udevadm info /sys/class/input/eventX as well please (for your touchpad event node). I want to make sure the LIBINPUT_MODEL_ tag is applied correctly.


also, make sure you're on libinput-1.2.4-2.fc23 or later, that one has that patch that's in 1.3 as well

(In reply to Peter Hutterer from comment #6)
> I don't get any motion events here, just the click. so this seems to be
> working fine?

There was movement in all the 3 evemu-record.

> this one has a massive cursor jump in it which is a problem with all the
> cyapas (see Bug 94910). This is partially addressed in libinput 1.3 where we
> discard this jump now. 

Since it's me that opened Bug 94910 I'm well aware of it ;) Like I said there, there is no more "jump" thanks to your fix backported in libinput 1.2.4. evemu-record don't seems to "know" that these jump are now discarded. And just to be perfectly clear, while I did the evemu-record there was no "visible" jump.

> There's other movement in here but that looks to be your finger movement.

I guess that the movement I have when I click is due to my finger but that should not happen. When you make a click you have to apply pressure to trigger the button. The more you press, the more your finger take surface and kind of move (first it's the top of your finger that touch the touchpad and then the more you press more of your finger will touch the touchpad) and the more it trigger the sensitivity layer that make the cursor move. I hope I'm clear enough.

> run udevadm info /sys/class/input/eventX as well please (for your touchpad
> event node). I want to make sure the LIBINPUT_MODEL_ tag is applied
> correctly.

I think we fixed this here https://bugs.freedesktop.org/show_bug.cgi?id=93846#c15 but here it is :

P: /devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input13/event13
N: input/event13
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/event13
E: DEVPATH=/devices/pci0000:00/0000:00:15.1/i2c-7/7-0067/input/input13/event13
E: ID_INPUT=1
E: ID_INPUT_HEIGHT_MM=64
E: ID_INPUT_TOUCHPAD=1
E: ID_INPUT_WIDTH_MM=106
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=77
E: SUBSYSTEM=input
E: USEC_INITIALIZED=5416964

> also, make sure you're on libinput-1.2.4-2.fc23 or later, that one has that
> patch that's in 1.3 as well

I have libinput-1.2.4-4.fc23

I just tried with synaptics driver and the movement is less less less noticeable. It's not triggered easily.

Peter is there something that you can do to improve this ?

As I said there ( https://bugs.freedesktop.org/show_bug.cgi?id=94910 ) I just switched to the v2.0 firmware (from unofficial v2.1 provided by Dudley Du) for my Cyapa touchpad and the imprecise click is almost gone !

as usual, for any jumps leftover I'll need evemu recordings. though tbh at this point I think the only real difference to the synaptics driver is the hysteresis which should be enabled on the cyapas, so I'm surprised that the behavious is different

(In reply to Peter Hutterer from comment #11)
> as usual, for any jumps leftover I'll need evemu recordings. 

As I said in comment 7 Peter there is **no** jump anymore thanks to your patch ;) But evemu-record don't seems to "know" that these jump are now discarded.

> though tbh at this point I think the only real difference to the synaptics driver is the  hysteresis which should be enabled on the cyapas, so I'm surprised that the behavious is different

The hysteresis is enabled now ( https://bugs.freedesktop.org/show_bug.cgi?id=93846#c15 ). Maybe the hysteresis of synaptics is a little bit different ?

evemu record sits below/beside libinput and sees the same kernel events that libinput sees. libinput's patches don't affect it. 

and yes, true - the hysteresis in synaptics doesn't account for device resolution, it's just some fixed value. based on my calculation the synaptics one ends up being just over 0.5mm (8 units) whereas the libinput one is 0.5mm (x:6 or y:7 units). You could verify that by changing tp_init_hysteresis() to set the margin to a hardcoded 8.

Where I change tp_init_hysteresis() to test it ?

You'll have to modify the source itself (src/evdev-mt-touchpad.c). Then rebuild, run the tools/event-gui tool to check the differences. It will show any pointer movements on the canvas and you don't have to restart X after each change.

(In reply to Peter Hutterer from comment #15)
> You'll have to modify the source itself (src/evdev-mt-touchpad.c). Then
> rebuild, run the tools/event-gui tool to check the differences. It will show
> any pointer movements on the canvas and you don't have to restart X after
> each change.

Ok, this is what I have done and I have to say that it was not that simple for someone that is not a developer ;)

So, I cloned the libinput repo :

$ git clone git://anongit.freedesktop.org/wayland/libinput

I modified the source (src/evdev-mt-touchpad.c) like this :

tp_init_hysteresis(struct tp_dispatch *tp)
{
	int res_x, res_y;

	tp->hysteresis_margin.x = 0;
	tp->hysteresis_margin.y = 0;

	if (tp->device->model_flags & EVDEV_MODEL_PRECISE_TOUCHPAD)
		return;

	res_x = tp->device->abs.absinfo_x->resolution;
	res_y = tp->device->abs.absinfo_y->resolution;
	tp->hysteresis_margin.x = 8;
	tp->hysteresis_margin.y = 8;

	return;
}

I rebuild it  :

$ cd libinput
$ ./autogen.sh --prefix=$WLD --enable-event-gui

I didn't found the needed dependencies so I installed them each time it complain :D 
By the way it's not so easy to find that "--enable-event-gui" is needed to build the event-gui tool.

$ make && sudo make install
$ sudo reboot

It seem that worked because with the 2.1 firmware it's much much better, there is almost no movement, like with synaptics. With the 2.0 firmware there is no visible change since it already worked pretty well.

However I don't know how to use the event-gui tool.

(In reply to Paviluf from comment #16)
> By the way it's not so easy to find that "--enable-event-gui" is needed to
> build the event-gui tool.

sorry, I should've mentioned that: it's not needed if all the dependencies are installed. other than that you did the right thing.

> $ make && sudo make install
> $ sudo reboot

this isn't needed if you're just running the event-gui tool, just run that as sudo ./tools/event-gui and it will use the local modification. you won't have the new libinput controlling the cursor but for testing that doesn't matter.

> It seem that worked because with the 2.1 firmware it's much much better,
> there is almost no movement, like with synaptics. With the 2.0 firmware
> there is no visible change since it already worked pretty well.

ok, this would indicate that for your device the hysteresis should be a bit larger. change it to           

tp->hysteresis_margin.x = res_x * 0.75;
tp->hysteresis_margin.y = res_y * 0.75;

or possibly even just res_x/res_y. Which one works best?

(In reply to Peter Hutterer from comment #17)
> tp->hysteresis_margin.x = res_x * 0.75;
> tp->hysteresis_margin.y = res_y * 0.75;

That work pretty well.

> or possibly even just res_x/res_y. Which one works best?

I don't get it. Do you mean that ?

tp->hysteresis_margin.x = res_x/res_y;
tp->hysteresis_margin.y = res_x/res_y;

nope, that would just be 1 :)
I mean just using tp->hysteresis_margin.x = res_x;
we deal with physical distances in libinput, a margin of res_x equates to 1mm in the x direction. the default for the hysteresis is 0.5mm but clearly yours needs more.

also, I can't believe I haven't asked this yet: please run the touchpad-edge-detector tool and measure your physical touchpad's dimensions. If the dimensions are off, that may just explain it.

(In reply to Peter Hutterer from comment #19)
> nope, that would just be 1 :)
> I mean just using tp->hysteresis_margin.x = res_x;
> we deal with physical distances in libinput, a margin of res_x equates to
> 1mm in the x direction. the default for the hysteresis is 0.5mm but clearly
> yours needs more.

With this the cursor feel clumpsy

tp->hysteresis_margin.x = res_x;
tp->hysteresis_margin.y = res_y;

> also, I can't believe I haven't asked this yet: please run the
> touchpad-edge-detector tool and measure your physical touchpad's dimensions.
> If the dimensions are off, that may just explain it.

I measure 100.5x69mm.

Here is the output of touchpad-edge-detector

Touchpad Cypress APA Trackpad (cyapa) on /dev/input/event14
Move one finger around the touchpad to detect the actual edges
Kernel says:	x [0..1280], y [0..960]
Touchpad sends:	x [0..1279], y [0..959] /^C

Touchpad size as listed by the kernel: 106x64mm
Calculate resolution as:
	x axis: 1280/<width in mm>
	y axis: 960/<height in mm>

Suggested udev rule:
# <Laptop model description goes here>
evdev:name:Cypress APA Trackpad (cyapa):dmi:bvncoreboot:bvr:bd12/09/2014:svnHewlett-Packard:pnFalco:pvr1.0:cvnHewlett-Packard:ct3:cvr:*
 EVDEV_ABS_00=0:1279:<x resolution>
 EVDEV_ABS_01=0:959:<y resolution>
 EVDEV_ABS_35=0:1279:<x resolution>
 EVDEV_ABS_36=0:959:<y resolution>

It seem that the dimensions are wrong:

physical 100.5x69mm vs kernel 106x64mm

evdev:name:Cypress APA Trackpad (cyapa):dmi:*svnHewlett-Packard:pnFalco*
 EVDEV_ABS_00=::12
 EVDEV_ABS_01=::15
 EVDEV_ABS_35=::12
 EVDEV_ABS_36=::15


save the above as /etc/udev/hwdb.d/90-somefilename.hwdb, run sudo udevadm hwdb --update, restart. If you run evemu-describe afterwards you should see the x/y resolutions set to 12/15 and I suspect the original hysteresis margin may be good enough now.

I made more tests and I found something else. The size reported with the firmware 2.1 is 106x64mm whereas with the v2.0 the size is 98x64mm. The 2.1 is cleary wrong as the touchpad width is about 100mm but I think the v2.0 is right because I just noticed that there is a 5mm unsensitive zone at the bottom of the touchpad. I guess it's designed on purpose to avoid triggering some movement when you click. Since the zone is insensitive every click here is perfect as long as you not move out the zone. 

So I won't use the v2.1 as it's an unofficial firmware and Dudley Du recommend the v2.0 that was validated by Google. I simply have to use the provided unsensitive zone to click. I'm really surprised that I didn't saw this earlier. It's the measure vs the size reported that make me discover this.

I don't think it's needed to modify anything. I will do more test just to be sure and come back to you if needed but I really think that, since I didn't know that there was an unsensitive zone, I triggered the movement each time I clicked outside the zone. Probably nothing to do with the setting or even the firmware :D I just tested with synatics and the movement is present when I click outside the zone too. It was probably just a coincidence if I thought the touchpad behave differently depending on the driver, the firmware or the settings !

Thank you Peter and sorry for the inconvenience ;)

ok, note that libinput has some insensitive zones at the bottom of the touchpad too and they'll likely be to big if the touchpad has insenstive zones that aren't accounted for. So double check those zones, only if evemu doesn't record anything then they're definitely there in hw/fw, not software.

evemu show that there is a really small 2/3mm insensitive zone. For me the libinput insensitive zone are too small and if this could be changed, an insensitive zone of 15mm should be much better.

quick calculation shows that the zone is 9.6mm + the 2/3mm zone. that makes it more than 10mm which is bigger than on all other touchpads where we cap to 10mm.

tbh I don't really want to make this zone any bigger because especially on a touchpad that small you'll be accidentally putting your finger into the zone and then your touchpad doesn't move (at least not immediately). Honestly, i think this is something where it's better if you train yourself to click further south on the touchpad.

> evemu show that there is a really small 2/3mm insensitive zone.

fwiw, this could be a problem. if libinput doesn't get coordinates it cannot know where your finger is (it may be in the right button area) and will discard the click.

but now I'm losing track of this bug. What's left to fix?

(In reply to Peter Hutterer from comment #25)
> quick calculation shows that the zone is 9.6mm + the 2/3mm zone. that makes
> it more than 10mm which is bigger than on all other touchpads where we cap
> to 10mm.

> but now I'm losing track of this bug. What's left to fix?

It seem that is more complicated than this. If I move my finger from bottom to top the insensitive zone is about 13mm. Now if I move my finger from top to bottom the insensitive zone is about 5mm. The problem is that when I click I naturally put my finger at about 10mm and the **pressure is from top to bottom**. So I'm in the sensitive zone and the click is imprecise.

To not trigger the top to bottom sensitive zone I have to click in this small 5mm insensitive zone that is too small. You may be right, 15mm is maybe a little too big. An about 10mm insensitive top to bottom zone, like it should be it seems, will be good and a much better improvement.

(In reply to Paviluf from comment #26)
> (In reply to Peter Hutterer from comment #25)
> > quick calculation shows that the zone is 9.6mm + the 2/3mm zone. that makes
> > it more than 10mm which is bigger than on all other touchpads where we cap
> > to 10mm.
> 
> > but now I'm losing track of this bug. What's left to fix?
> 
> It seem that is more complicated than this. If I move my finger from bottom
> to top the insensitive zone is about 13mm. Now if I move my finger from top
> to bottom the insensitive zone is about 5mm. The problem is that when I
> click I naturally put my finger at about 10mm and the **pressure is from top
> to bottom**. So I'm in the sensitive zone and the click is imprecise.

If a finger starts outside the software button area, the button zone doesn't stop pointer movement. but when you start inside the button area, the pointer only starts moving when you move outside that area. that explains the different sizes.

there isn't much we can do about that because there is plenty of movement that would hit the button zone and should not be impeded. since there is no haptic feedback when the button zone is hit having the cursor stop moving is not ideal.

AIUI you're not lifting the finger between moving into the button area and clicking? If you do so, there shouldn't be any movement as long as the finger remains in the button area.
you can probably see why we're advocating clickfinger as the future default interaction :)

unfortunately we don't get enough data from the touchpad to detect pressure changes correctly before a button press.

(In reply to Peter Hutterer from comment #27)
> AIUI you're not lifting the finger between moving into the button area and
> clicking? If you do so, there shouldn't be any movement as long as the
> finger remains in the button area.
> you can probably see why we're advocating clickfinger as the future default
> interaction :)

I made some tests again and you are right. If I click with lifting my finger there is no movement as long as my finger remains in the button area (13mm). If I click without lifting my finger there is movement until the 5mm zone. But since I always click with lifting my finger it seems that there is no problem at all finally. In fact I click with the left finger that I use only for clicking and I use the right finger for movement. The movement happen only when my finger click outside (often just a little little bit) the button area (bottom to top 13mm insensitive zone). 

The 5mm top to bottom insensitive zone is not relevant finally. I just need to be careful and don't click outside the 13mm button area that is in fact large enough.

Thanks again Peter. I think we can close this ?

ok. thanks for the update. closing this now, let's open a new bug if something comes up on this hardware again