mouse drag

[omatsuda]

Thank you very much for this nice software.

I'm now using iichid daily on my Fujitsu notebook FMV WD2U with polling mode (it seems this machine requires GPIO interrupt).

Though I'm not sure whether it is related to iichid or not, I'm experiencing a small problem below.

In a drag motion (moving cursor with a button pressed), it sometimes happens a single stroke is not enough for the desired cursor motion. In this case, one needs to release the finger from the touch-pad once and continue the drag motion from the new point on the touch-pad, while the button is kept pressed. My problem is that sometimes (approx. once in 10 times) the second touch of the finger to the touch-pad makes the cursor returns to its previous original position, not retains the moved position. This is rather annoying.

Is there any way to avoid the cursor returning to its original position during the drag?

[wulf7]

Glad to hear you again, @omatsuda

Is there any way to avoid the cursor returning to its original position during the drug?

I've seen strange 'reports from the past' at the touch end in polled mode which could lead to backward jumps. I think they can be filtered out by hardware timestamps analysis. I hope, I'll get a time to implement it at this or next weekend.

[wulf7]

That 'strange reports' appeared to be a bug in hidraw driver and are irrelevant to hmt driver. So hard way should be taken with enabling of debug output: @omatsuda, plz do following:

1. Enable I2C debug with sudo sysctl hw.iichid.debug=5
2. Run any evdev client like libinput debug-events or evemu-record to open /dev/input/eventN device.
3. Switch to system console (ttyv0) You will see raw I2C traffic dumps slowly filling the screen. They must go faster when you are touching surface.

Could you post here dumps from both good and bad gestures? Most interesting part is a moment of finger release.

[omatsuda]

Thank you for your help.

Here is the event log "ev.log" and the I2C traffic dump "all.log".

The host name of the notebook computer with the touch pad is hostX. I used another machine hostY to execute commands for recording the events. On the terminal of hostY, I put the following commands.

slogin hostX su /etc/rc.d/syslogd stop vi /etc/syslog.conf # uncomment the line # "*.* /var/log/all.log" rm /var/log/all.log touch /var/log/all.log /etc/rc.d/syslogd start sysctl hw.iichid.debug=5 evmu-record /dev/input/event6 |& tee ev.log # mouse operation on hostX # ^C for to stop evemu-record /etc/rc.d/syslogd stop sysctl hw.iichid.debug=0 vi /etc/syslog.conf # comment the line # "*.* /var/log/all.log" /etc/rc.d/syslogd start

I'm using fvwm2 as the window manager on hostX. The dragging the title bar of a window moves the window. The events recorded on "ev.log" are as follows:

press the left button on a title bar of a window. drag the window position with several strokes. (keeping the left button pressed) release the left button.

You can play back these motions with placing the mouse cursor on the title bar of a window on hostX, and put the command

evemu-play ev.log

on hostY.

There are lots of strokes of drag in the recorded file, but most of them are OK. At the begining of the final stroke, the wondow position jumps unintentionally. This unintentional motion is distinguishable from the others as it is much quicker than other intended motions.

I'm sorry I just put rather huge I2C traffic file "all.log" as I couldn't figure out the part corresponding to the above mentioned "jump".

ev.log all.log

[wulf7]

Try updated iichid.

There is one strange thing in all.log. According to it your touchpad freezes periodically for ~0.1 sec. Look at "last message repeated 4 times" lines. I do not know is it related to iichid/sampling mode or not.

[omatsuda]

Thank you very much! The updated version seems working perfectly. I haven't had any jump so far.

As for the periodical freeze, is the following what you mentioned, for example?

Aug 10 13:38:07 hostX kernel: iichid0: 20 00 - 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a 8e 00 01 Aug 10 13:38:07 hostX syslogd: last message repeated 4 times

But I didn't notice it stopped so frequently. I will see.

[wulf7]

As for the periodical freeze, is the following what you mentioned, for example?

Aug 10 13:38:07 hostX kernel: iichid0: 20 00 - 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7a 8e 00 01 Aug 10 13:38:07 hostX syslogd: last message repeated 4 times

Yes, it is. 3-rd and 4-th bytes from the end of the packet is a counter. It must increase at equal step on each packet.

But I didn't notice it stopped so frequently. I will see.

Default polling frequency in sampling mode is 60Hz so freezes are very short. Moreover if libinput has a really good low-pass filter (I doubt, but who knows?), it could remove them completelly.

You can try to increase polling frequency to match touchpad's scan rate with $ sudo sysctl dev.iichid.0.sampling_rate_fast=90 and see if the freezes disappeared or not.

Anyway, I don't think you should worry about them. Sampling is not the way this device was designed to work.

[omatsuda]

Thank you for the explanation.

When I tested the jumps for all.log, dev.iichid.0.sampling_rate_fast was set to 200. Changing this value to 60 or 90, "last message repeated xx times" message has gone except for those for the complete idle state.

By the way, in my comment yesterday, I took a complicated way to log the I2C traffic dump. I don't know why I did that, but in fact the dump just comes to /var/log/messages if hw.iichid.debug is set to 5.

Anyway thank you so much for the improvement on iichid. It's working very nicely.