Bug 231058 - no support for active PS/2 multiplexing results in erratic behaviour of Synaptics touchpad on HP 8560w
Summary: no support for active PS/2 multiplexing results in erratic behaviour of Synap...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: Vladimir Kondratyev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-31 14:07 UTC by Michael Figiel
Modified: 2019-09-10 12:17 UTC (History)
2 users (show)

See Also:


Attachments
relevant syslog entries (7.50 KB, text/plain)
2018-08-31 14:07 UTC, Michael Figiel
no flags Details
acpidump ps2m section (906 bytes, text/plain)
2018-09-25 20:51 UTC, Michael Figiel
no flags Details
Synaptics touchpad initialization log (6.68 KB, text/plain)
2018-09-25 23:19 UTC, Michael Figiel
no flags Details
trackpoint initialization log (6.84 KB, text/plain)
2018-09-25 23:20 UTC, Michael Figiel
no flags Details
packet from initialized synaptics touchpad (36.69 KB, text/plain)
2018-09-27 23:07 UTC, Michael Figiel
no flags Details
trackpoint packets, touchpad not initialized (generic PS/2 device) (1.00 KB, text/plain)
2018-09-27 23:08 UTC, Michael Figiel
no flags Details
trackpoint used with initialized touchpad (2.36 KB, text/plain)
2018-09-27 23:08 UTC, Michael Figiel
no flags Details
touchpad/trackpoint coexistence patch (draft) (8.14 KB, patch)
2018-09-28 22:24 UTC, Vladimir Kondratyev
no flags Details | Diff
touchpad/trackpoint coexistence patch (draft) (8.67 KB, patch)
2018-09-29 19:06 UTC, Vladimir Kondratyev
no flags Details | Diff
packets logged with patch applied (5.49 KB, text/plain)
2018-09-30 09:53 UTC, Michael Figiel
no flags Details
touchpad/trackpoint coexistence patch (draft) (8.54 KB, patch)
2018-09-30 11:17 UTC, Vladimir Kondratyev
no flags Details | Diff
touchpad/trackpoint coexistence patch (draft) (8.57 KB, patch)
2018-09-30 11:23 UTC, Vladimir Kondratyev
no flags Details | Diff
loglevel 5, complete trace since initialization (8.42 KB, text/plain)
2018-09-30 17:43 UTC, Michael Figiel
no flags Details
PS/2 packets, after reverting second step of mux deactivation to 0xF6 (2.07 KB, text/plain)
2018-10-01 08:24 UTC, Michael Figiel
no flags Details
synaptics packet log (2.94 KB, text/plain)
2018-10-02 07:34 UTC, Michael Figiel
no flags Details
synaptics and trackpoint packets (14.13 KB, text/plain)
2018-10-02 07:39 UTC, Michael Figiel
no flags Details
log entries for working trackpoint and touchpad (1.43 KB, text/plain)
2018-10-11 07:08 UTC, Michael Figiel
no flags Details
touchpad/trackpoint coexistence patch (16.04 KB, patch)
2018-10-31 00:38 UTC, Vladimir Kondratyev
no flags Details | Diff
xev and syslog records of phantom clicks (5.96 KB, text/plain)
2018-10-31 16:48 UTC, Michael Figiel
no flags Details
touchpad tap and immediate trackpoint 1 click (5.70 KB, text/plain)
2018-10-31 19:55 UTC, Michael Figiel
no flags Details
disable middle button if touchpad or trackpoint is active (819 bytes, patch)
2018-11-01 12:51 UTC, Vladimir Kondratyev
no flags Details | Diff
touchpad middle button press-hold-release (11.96 KB, text/plain)
2018-11-01 18:41 UTC, Michael Figiel
no flags Details
disable middle button if trackpoint is active (2.58 KB, patch)
2018-11-01 23:13 UTC, Vladimir Kondratyev
no flags Details | Diff
disable middle button if trackpoint is active (2.59 KB, patch)
2018-11-02 08:41 UTC, Vladimir Kondratyev
no flags Details | Diff
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis (1.30 KB, patch)
2018-11-02 21:53 UTC, Vladimir Kondratyev
no flags Details | Diff
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis (1.53 KB, patch)
2018-11-04 08:23 UTC, Vladimir Kondratyev
no flags Details | Diff
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis (1.70 KB, patch)
2018-11-04 11:36 UTC, Vladimir Kondratyev
no flags Details | Diff
touchpad/trackpoint coexistence patch (18.64 KB, patch)
2018-11-10 21:53 UTC, Vladimir Kondratyev
no flags Details | Diff
mute trackpoint's middle button if touchpad is active (singletouch case) (744 bytes, patch)
2018-11-17 15:57 UTC, Vladimir Kondratyev
no flags Details | Diff
mute trackpoint's middle button if touchpad is active (767 bytes, patch)
2018-11-18 18:43 UTC, Vladimir Kondratyev
no flags Details | Diff
syslog, palm hovering just above the touchpad (21.40 KB, text/plain)
2018-11-18 21:51 UTC, Michael Figiel
no flags Details
mute trackpoint's middle button if touchpad is active (1.73 KB, patch)
2018-11-19 00:24 UTC, Vladimir Kondratyev
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Figiel 2018-08-31 14:07:49 UTC
Created attachment 196747 [details]
relevant syslog entries

I've got a HP EliteBook 8560w which is equipped with a Synaptics touchpad and a trackpoint. The trackpoint doesn't work at all (movements are repoted as button events or not at all), neither is the touchpad's middle button reported.

This is one of the devices which respond to the special query, which is used to identify it, with a middle byte of 0x46 instead of 0x47. The same hardware is properly recognized and works on Linux (Ubuntu 18.04). Linux accepts only 0x47 (I checked the source). I've seen in psm.c that FreeBSD accepts the 0x46 id but uses conservative defaults for settings, because the devices report garbage.

I think the root cause of the 0x46 id is that FreeBSD doesn't support active PS/2 multiplexing.
As a PoC I added functions to enable/disable the active multiplexing mode of the i8042 and in multiplexing mode I queried all four aux ports. I got two devices, and one of them sends 0x46 but the other sends a 0x47 in the middle byte.
I attach the relevant portion of syslog messages (line 19: the first device, line 34 the second device, from 36 on the normal initialization).

I found a document titled "Active PS/2 Multiplexing", version 1.1, from 1999 which describes this mode of operation. It hints on the fact, that a multiplexing controller operated in legacy (non-multiplexing) mode with more than one aux device might garble some of the data passed to the host. I think, that's what happens on my machine. 

I'm not sure if it is really worth the effort to implement the multiplexing, as I suspect that the few machines which use it will die of old age pretty soon, but over the weekend I'll try to modify the psm.c to operate in multiplexing mode with only one enabled device.
Comment 1 Vladimir Kondratyev freebsd_committer 2018-09-23 13:56:16 UTC
(In reply to Michael Figiel from comment #0)
> I think the root cause of the 0x46 id is that FreeBSD doesn't
> support active PS/2 multiplexing.
Wow! I was not aware of 'active PS/2 multiplexing' when committed 0x46 hack. Unfortunately, now I do not have access to such a hardware to reimplement it in a right way.

> multiplexing controller operated in legacy (non-multiplexing)
> mode with more than one aux device might garble some of the
> data passed to the host.
I don`t think so. Trackpoint support code in synaptics driver expects trackpoint to be attached via special passthrough interface which does Generic->Synaptics protocol conversion. It (driver) it its current state just can not decode generic mouse protocol.

> I'm not sure if it is really worth the effort to implement the multiplexing
Proper multiplexing implementation requires a lot of changes in both atkbd and psm drivers. I think it is overkill. The simpler way is to enable multiplexing only for synaptics devices and just only for configuring/querying stage and return to legacy mode after. trackpad/trackpoint packet separation problem should be solved in that case.

> that the few machines which use it will die of old age pretty soon
0x46 hack was made for 2013 year model. It is not so old to die quickly.
Comment 2 Michael Figiel 2018-09-25 20:51:39 UTC
Created attachment 197498 [details]
acpidump ps2m section
Comment 3 Michael Figiel 2018-09-25 23:18:40 UTC
(In reply to Vladimir Kondratyev from comment #1)
Hello Vladimir,
sorry for responding late and thank you for looking into it. 

I toyed with the controller and can give you some more info:
the machine (hp 8560w) claims to have following devices attached to aux port of the i8042:
port 0: the trackpoint, the one returning ext. id 0x46
port 1,2 : nothing
port 3: touchpad, returning id 0x47

I've attached acpi PS2M section from the HP 8560w, it lists two id strings starting with SYN -- maybe both devices are Synaptics' ?

The active multiplexer implementation on 8560w doesn't work as expected: I can't disable single ports (that should be possible by sending 0x9[0-3] and 0xA7 sequence), so I always get data from both devices.

I'll attach the log of the initialization of the 0x47 device. It doesn't advertise passthrough.

The trackpoint is recognized as a generic PS/2 mouse, it reports only two buttons, but actually all three are working.

I've got two mostly working configurations: 
1) I send all commands to port 3, to the touchpad, and get working Synaptics touchpad, with occasional device resests if I touch the trackpoint or any of it's buttons (no passthrough on that machine, at least not advertised by the touchpad) -- you are right, the trackpoint sends generic ps2 packets, but additionally there ist the issue of interleaving both data streams.

2) I send all commands to port 0, and get a generic PS2 mouse. I removed the id 0x46 from psm.c, so this is the situation before your patch. All buttons work,  but  it's two times button one, two times two and two times button three, without any possiblity to tell them apart - not a big deal. I think, occasionally there are problems with interleaving both streams but generally it works well. But then there is no point enabling multiplexing in first place...

> The simpler way is to enable multiplexing only for synaptics devices and just > only for configuring/querying stage and return to legacy mode after.
> trackpad/trackpoint packet separation problem should be solved in that case.
This amounts to hidden multiplexing -- the data streams of both devices will be interleaved, at the level of three bytes. Additionally, the controller might try to be helpfull, and mangle the data (e.g. using bit 3 of byte one of a packet to mark the source, a problem with six byte packets). But I haven't tried it - that's just what this document claims. 

I think, with this special hardware there are only two viable solutions:
1) removing the 0x46 id, leaving i8042 in legacy mode and using the touchpad and the stick as one generic ps/2 device. One has no gestures, no multi-touch (two fingers scrolling), but I think it's possible to configure the scrolling zones on the edges in X11. Actually that sounds like reverting your change :-/

2) to implement a proper multiplexing driver

If you want any logs/traces I'd be happy to provide them. I think it should be possible to give you access via ssh to the 8560w, at least for a few days.

But if you think that's not worth the effort, it's OK, because solution 1) is good enough for me, I can maintain a patch locally, there is no point in  reverting your change if it works well for others.
Comment 4 Michael Figiel 2018-09-25 23:19:59 UTC
Created attachment 197499 [details]
Synaptics touchpad initialization log
Comment 5 Michael Figiel 2018-09-25 23:20:38 UTC
Created attachment 197500 [details]
trackpoint initialization log
Comment 6 Vladimir Kondratyev freebsd_committer 2018-09-26 21:50:03 UTC
(In reply to Michael Figiel from comment #3)
> I've attached acpi PS2M section from the HP 8560w, it lists two id
> strings starting with SYN -- maybe both devices are Synaptics' ?
I doubt it. My trackpoint-less HP laptop has exactly the same list of CIDS.

> I can't disable single ports ... so I always get data from both devices.
You can filter out unwanted data inside read_aux_data_no_wait() routine with dropping read_data() result if previous read_status() invocation has returned port number of port that should be disabled.

> This amounts to hidden multiplexing -- the data streams of both devices will be interleaved, at the level of three bytes.
Fortunately, according to Synaptics docs, driver could be modified to support 3bytes packets. Bit6 of 1-st byte is always 0 while bit6 of 4-th byte is always 1.  This fact can be used to do a proper assembly of single 6 byte packet from two 3 byte ones.

> I think, with this special hardware there are only two viable solutions:
3) Switch touchpad to absolute mode with packetsize reduced to 3 bytes and use hidden multiplexing. I would like to avoid massive psm.c refactoring as it currently supports only one device at time.

> But if you think that's not worth the effort
Really I hate 0x46 hack. I spent 2 weekends trying to find a proper initialization way of HP touchpad and did not succeed. :(

> If you want any logs/traces I'd be happy to provide them. 
1. Trackpoint name as it was detected by Linux
2. Short snippets of dmesg or systemlog reflecting both trackpad and trackpoint touches made with debug.psm.loglevel=5 inserted in to /boot/loader.conf

I'll make 3-byte packetsize patch to test and will post it here than. Note I'll be AFK for next two weeks so it can take some time.
Comment 7 Michael Figiel 2018-09-27 23:05:31 UTC
(In reply to Vladimir Kondratyev from comment #6)
>> I can't disable single ports ... so I always get data from both devices.
> You can filter out unwanted data inside read_aux_data_no_wait() routine with 
> dropping read_data() result if previous read_status() invocation has returned 
> port number of port that should be disabled.
Yes, that's true. But I mentioned it just to warn you, that the HP implementation isn't totally faithful to the documentation (OTOH the multiplexing isn't a standard anyways). I had a look at the Linux code again, and they have quite a list of systems which react weird or hostile to an attempt to activate multiplexing, some don't support the D3h(echo) controller command. They use DMI/SMBios data, vendor and model, to avoid known problems - it's probably a good idea to use their lists and implement something similar here.

Here are the Linux lines:
Sep 27 11:54:13 ubuntu kernel: psmouse serio4: synaptics: Touchpad model: 1, fw: 7.5, id: 0x1c0b1, caps: 0xd40033/0x640000/0xa0400/0x0, board id: 1651, fw id: 708038
Sep 27 11:54:13 ubuntu kernel: input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input9
the trackpoint isn't really recognized, but works OK (all three buttons, too).

I destroyed (unintentinally) my test BE with all my modifications and I had to recreate it. I observed a funny third variant: if I activate the multiplexing, but don't modify the write_command() to replace D4h with 90h or 93h, then the touchpad/trackpoint is recognized as IntelliMouse, with three buttons and 4 byte packets.
Both devices work OK with the exception of the trackpoint's middle button, which is silent (all three touchpad buttons work). I see no device resets.

>> But if you think that's not worth the effort
> Really I hate 0x46 hack. I spent 2 weekends trying to find a proper 
> initialization way of HP touchpad and did not succeed. :(
OK, after a few days of using the devices as generic PS/2 I remembered what triggered me to research this: the lack of palm detection and no possibility to deactivate the touchpad at runtime. So yes, alone therefore I'd like to see this synaptics device operating properly.

The place to deactivate active multiplexing after touchpad's initialization would be at the end of psmattach(), wouldn't it? I'm going to try it tomorrow. Now I just attach the logs:
1) initialized synaptics packets, 
2) the trackpoint as generic PS/2 device, touchpad not initialized
3) trackpoint used with initialized synaptics touchpad (this results in deactivation of psmouse because I haven't modified the aux reset function yet).
Comment 8 Michael Figiel 2018-09-27 23:07:10 UTC
Created attachment 197560 [details]
packet from initialized synaptics touchpad
Comment 9 Michael Figiel 2018-09-27 23:08:11 UTC
Created attachment 197561 [details]
trackpoint packets, touchpad not initialized (generic PS/2 device)
Comment 10 Michael Figiel 2018-09-27 23:08:58 UTC
Created attachment 197562 [details]
trackpoint used with initialized touchpad
Comment 11 Michael Figiel 2018-09-28 07:59:15 UTC
I finally tested your suggestion to enable multiplexing only for configuration and then let it run in legacy mode. It works, I think the data are not mangled at any point, the synaptics driver chokes on trackpoint data as expected:

psmintr: 90 bb 4c c0 db 68
synaptics: ipacket: [3035, 2920], 76, 4
synaptics: virtual scrolling: NO (direction=0, dxp=569, dyp=814, fingers=1)
smoother0: ipacket: [3035, 2920], 76, 4
smoother0: cursor[6]: x=3035, y=2920, dx=-1, dy=1
smoother0: peer=5, len=129, weight=0/0, div=13/13
smoother0: avg_dx~=-1, avg_dy~=1
smoother0: [-1, 1] -> [0, 0]
psmintr: 90 bb 3e c0 db 68
synaptics: ipacket: [3035, 2920], 62, 4
synaptics: virtual scrolling: NO (direction=0, dxp=569, dyp=814, fingers=1)
smoother0: ipacket: [3035, 2920], 62, 4
smoother0: cursor[5]: x=3035, y=2920, dx=0, dy=0
smoother0: peer=4, len=91, weight=0/0, div=17/17
smoother0: avg_dx~=0, avg_dy~=0
smoother0: [0, 0] -> [0, 0]
psmintr: 90 bb 1a c0 db 68
synaptics: zmax=76, dx=569, dy=814, delta=80, fingers=1, queue=10
synaptics: not a tap-hold
psmintr: 90 bb 08 c0 a8 af
psmintr: 80 00 03 c0 01 01
psmintr: 80 00 02 c0 01 01
psmintr: 80 00 00 c0 00 00
last message repeated 62 times
psmintr: 28 00 ff 28 00 ff
psmintr: out of sync (0000 != 0080) 3941 cmds since last error.
psmintr: discard a byte (1)
psmintr: 00 ff 28 00 ff 28
psmintr: out of sync (0000 != 0080) 0 cmds since last error.
psmintr: discard a byte (2)
psmintr: ff 28 00 ff 28 00
psmintr: out of sync (00c0 != 0080) 0 cmds since last error.
psmintr: discard a byte (3)
psmintr: 28 00 ff 28 00 ff
psmintr: out of sync (0000 != 0080) 0 cmds since last error.
psmintr: discard a byte (4)
psmintr: 00 ff 28 00 ff 28
psmintr: out of sync (0000 != 0080) 0 cmds since last error.
psmintr: discard a byte (5)
psmintr: ff 28 00 ff 28 00
psmintr: out of sync (00c0 != 0080) 0 cmds since last error.
psmintr: re-enable the mouse.  

so apparently at least this particular implementation of PS/2 multiplexing is mostly harmles :-D
Comment 12 Vladimir Kondratyev freebsd_committer 2018-09-28 22:24:22 UTC
Created attachment 197580 [details]
touchpad/trackpoint coexistence patch (draft)

I was able to test this patch on laptop with single touchpad connected to AUX multiplexer. (HP ProBook 4320, no external PS/2 port, no TrackPoint)

Results:

1. It works correctly with 3 bytes interleaving.
2. Looks like it successfully enables active mode (It returns the same mux version  as Linux does).
3. Trackpoint is not tested (absent)
4. Synaptics probe detects touchpad at any of 4 aux ports??? I did not find out if it a bug or a feature yet.
Comment 13 Vladimir Kondratyev freebsd_committer 2018-09-28 23:33:36 UTC
(In reply to Michael Figiel from comment #7)
> I activate the multiplexing, but don't modify the write_command()
> to replace D4h with 90h or 93h, then the touchpad/trackpoint is
> recognized as IntelliMouse, with three buttons and 4 byte packets.
Looks like you triggered undocumented? command sequence to switch # of interleaved bytes from 3 to 4 (it can be necessary to support wheel). According to docs, d4h can not be used in active multiplexing mode:
"D4h - This command always causes the KBC to revert to Legacy mode"

> The place to deactivate active multiplexing after touchpad's
> initialization would be at the end of psmattach(), wouldn't it? 
I do not see any reason to detect all supported device types if active mode is not used after device has been run. In hidden mux mode we stick to 3-bytes packets and can not use other sizes. Fortunately, synaptics 6-bytes packets can be easily split and than joined back so we can treat them as two 3-bytes packets. Attached patch just enables active mode, probes 4 ports for synaptics touchpad presence and than returns back to legacy mode. It supports only generic mouses and synaptics touchpads that should cover 99% of cases.

Could you test the patch and fix p.4. (Synaptics probe detects touchpad at any of 4 aux ports) if it is necessary to fix?
Comment 14 Vladimir Kondratyev freebsd_committer 2018-09-29 19:06:08 UTC
Created attachment 197603 [details]
touchpad/trackpoint coexistence patch (draft)

> 4. Synaptics probe detects touchpad at any of 4 aux ports???
The stupid bug is fixed. Touchpad is detected only at port #3 now.

Still need to find out why SEND_AUX_DEV_STATUS command does not return correct port number
Comment 15 Michael Figiel 2018-09-30 09:52:08 UTC
The initialization works, the touchpad is correctly recognized and configured.
There is a bug in set_aux_mux_state(): the sequences for enabling/disabling should be F0h, 56h, enable ? A4h : A5h
so I think multiplexing wasn't ever disabled.

Still, even with that fixed, it doesn't work well: as soon as I touch the trackpoint, psm loses synchronization and never recovers (I'll attach a log).

> It supports only generic mouses and synaptics touchpads that should cover 99% of cases.
Yes, it sounds good.

> Still need to find out why SEND_AUX_DEV_STATUS command does not return correct port number
Sorry, I can't find it in code...
Comment 16 Michael Figiel 2018-09-30 09:53:19 UTC
Created attachment 197619 [details]
packets logged with patch applied
Comment 17 Vladimir Kondratyev freebsd_committer 2018-09-30 11:17:00 UTC
Created attachment 197625 [details]
touchpad/trackpoint coexistence patch (draft)

> the sequences for enabling/disabling should be F0h, 56h, enable ? A4h : A5h
Fixed. Thanks!

> it doesn't work well: as soon as I touch the trackpoint,
> psm loses synchronization and never recovers
Looks like your mux clobbers bit 3 of 0-th byte which is used as generic mouse packet marker. I attached patch with other packet type detector.

> Sorry, I can't find it in code...
It is called PSMC_SEND_DEV_STATUS in code. But it is logged/printfed as SEND_AUX_DEV_STATUS
Comment 18 Vladimir Kondratyev freebsd_committer 2018-09-30 11:23:11 UTC
Created attachment 197626 [details]
touchpad/trackpoint coexistence patch (draft)

Ooops. Wrong patch replaced
Comment 19 Michael Figiel 2018-09-30 17:43:09 UTC
Created attachment 197637 [details]
loglevel 5, complete trace since initialization

No, it doesn't work. Could it be, that now all packets are consumed by the generic PS/2?
Comment 20 Vladimir Kondratyev freebsd_committer 2018-09-30 23:33:40 UTC
(In reply to Michael Figiel from comment #19)
It seems like 4-byte packet interleaving mode is enabled. Look at 0x80 byte staircase.

could you revert latest set_aux_mux_state() fix (0xfe->0x56 byte on disable_aux_mux) and retest?

I am away now so I can not post patch to test
Comment 21 Michael Figiel 2018-10-01 08:24:46 UTC
Created attachment 197658 [details]
PS/2 packets, after reverting second step of mux deactivation to 0xF6

I added a log record just before the last return in set_aux_mux_state() and it's reached only in case of enabled == true, so with 0xF6 as second step, the muxer is not disabled.

With 0x56 as second step, the third step echos 0x11 instead of 0xA5 so the muxer gets (probably) disabled.

Regardless of the state of the muxer, the separation of the data doesn't work... at least not all the time: I observed, that occasionally the touchpad's packets are assembled/recognized correctly for a few seconds and then wihtout me touching the trackpoint (or it's buttons), psm gets confused and doesn't ever recover. I wasn't able to capture it in log yet.
Comment 22 Vladimir Kondratyev freebsd_committer 2018-10-01 18:49:01 UTC
(In reply to Michael Figiel from comment #21)
Could you place
pb->ipacket[3] &= 0xf7;

right after following line and retest: 
pb->ipacket[0] &= 0xf7;
Comment 23 Michael Figiel 2018-10-02 07:34:47 UTC
Created attachment 197703 [details]
synaptics packet log

OK, I added the line. It works slightly better, but it's still not usable.
The synaptics works for a time (a few seconds) and then, even if I don't touch the trackpoint it loses synchronization. I've captured this in the attached log.

After some time (maybe a minute, I haven't measured it -- I think it's longer then the periond over which the PS/2 devices send data even if nothing happens) the psm recovers, for a few seconds and the cycle repeats. In this attachment I captured the transition between working and not working.
Comment 24 Michael Figiel 2018-10-02 07:39:19 UTC
Created attachment 197704 [details]
synaptics and trackpoint packets

in this log I captured the transition between not working, working (touchpad only) and then I pressed the left trackpoint button and provoked the transition to not working. sorry, this one is lengthy but the interesting parts are at the begin and at the end. I'm surprised about the 'palm detected' messages, but that may be just a question of tuning.
Comment 25 Vladimir Kondratyev freebsd_committer 2018-10-09 20:22:32 UTC
(In reply to Michael Figiel from comment #24)
I'm sorry for my long silence

> interesting parts are at the begin and at the end.

Strange. Generic mouse button press should result in "09 00 00" or "0a 00 00" sequence depending on left or right button have been pressed. Most similar sequence I was able to find is "09 01 80" so I thing mux merges some bits in any byte. That can explain palm misdetection.

Could you check your touchpad
1. after suspend/resume cycle (acpiconf -s3) as resume handler can reinitialize mux
2. after disable_aux_mux() call have been deleted or commented out
Comment 26 Michael Figiel 2018-10-10 16:53:55 UTC
(In reply to Vladimir Kondratyev from comment #25)
 after a suspend/resume: it works! I can use the touchpad and trackpoint without any problems, all buttons are recognized, there are synaptics/smoother records in logs, no hiccups.
A few other things do not work, but that's not related to this problem. Do you want the log - with the re-init and a portion of record when I use both devices?

Now I'm going to comment out the disable_aux_mux(), but I think I did it before and it did not work well.
Comment 27 Michael Figiel 2018-10-10 17:10:27 UTC
(In reply to Michael Figiel from comment #26)
Now, with disable_aux_mux() commented out, the touchpad works recognized as synaptics; I've seen the message about AUX IRQ firing in muxed mode once and the trackpoint doesn't work at all (no log entries if I try to use it).
Comment 28 Vladimir Kondratyev freebsd_committer 2018-10-10 23:21:32 UTC
(In reply to Michael Figiel from comment #26)
> after a suspend/resume: it works!
Nice!

Could you move enable_synaptics_mux() call to begin of probe sequence and check if it works w.o suspend/resume? I think one of the probe routines can trigger bad mux behavior.
Just move corresponding member of vendortype array to 0-th position. vendortype array is declared at lines 667-697 of psm.c

Corresponding member is
        { MOUSE_MODEL_SYNAPTICS,        /* Synaptics Touchpad on Active Mux */
          0x00, MOUSE_PS2_PACKETSIZE, enable_synaptics_mux },

> Do you want the log - with the re-init and a portion
> of record when I use both devices?
Yes. Please provide me a short snippets of both pad and stick touches. I want to see if bit3 is garbled or not.
Comment 29 Michael Figiel 2018-10-11 07:08:58 UTC
Created attachment 198030 [details]
log entries for working  trackpoint and touchpad

as it worked as the first probe I moved it further back and found it's the Microsoft IntelliMouse Explorer probe which triggers the muxer's strange behaviour.

Now I used it for a few hours and everything works flawlessly. Awesome! Thanks!
Comment 30 Vladimir Kondratyev freebsd_committer 2018-10-31 00:38:38 UTC
Created attachment 198791 [details]
touchpad/trackpoint coexistence patch

Hi Michael,

Could you test this version of the patch?

It now does not probe touchstyk and enables mux support if 2 or more active ports detected and one of them has synaptics touchpad attached.
0x46 kludge is reverted also.

If it is OK I'll commit it.
Comment 31 Michael Figiel 2018-10-31 14:42:51 UTC
(In reply to Vladimir Kondratyev from comment #30)
Hello Vladimir,
yes it works, I applied the patch to 11.2-RELEASE-p4 and tested following configurations:
1) kernel without evdev, moused enabled, xorg input via /dev/sysmouse: everything works
2) kernel without evdev, moused disabled, xf86-input-libinput: seg fault
3) kernel with evdev, xorg-server built with udev support, xf86-input-libinput: everything works

However, the config 2) has  ever worked - regardless of the patch.

"everything works": 
* both, the  touchpad and the trackpoint/touchstyk work
* both sets of three buttons work
* two-finger-scrolling works

So I think it's OK to commit.
Comment 32 Michael Figiel 2018-10-31 16:48:13 UTC
Created attachment 198807 [details]
xev and syslog records of phantom clicks

I found a problem:
a movement or tap on the touchpad followed by clicking trackpoint's button 1 results in two clicks reported: button one and button two. It's only the first click, following clicks are reported correctly.

It's the only sequence of events which results in the additional click: touchpad movement immediately followed by a click on trackpoint's button 1.

If there is a pause between the movement and the click, the click is reported correctly.

The attached file contains xev and syslog records of this behaviour.
Comment 33 Vladimir Kondratyev freebsd_committer 2018-10-31 18:11:58 UTC
(In reply to Michael Figiel from comment #32)
> The attached file contains xev and syslog records of this behaviour.
I do not see trackpoint packets here. Trackpoint button press should look like
psmintr: 09 00 00 00 00 00
or
psmintr: 0a 00 00 00 00 00

First nibble must be in range [0-3] (assuming no X/Y overflow has happened)
Comment 34 Michael Figiel 2018-10-31 19:53:15 UTC
(In reply to Vladimir Kondratyev from comment #33)
I got another capture, and yes,  the psm/synaptics doesnt register any spurious clicks... but xev and X clients recieve button 2 press/release events. 

However: it happens not every time (maybe I don't get the timing right) and sometimes there are two button 2 press/release event combos. They usually interleave with the button 1 press/release events, e.g.:
button 1 press, button 2 press, button 2 release, button 2 press, button 1 release, button 2 release

This happens with evdev (I can record the event sequence with evemu-record) and without evdev, when I run xorg and moused.
Comment 35 Michael Figiel 2018-10-31 19:55:46 UTC
Created attachment 198824 [details]
touchpad tap and immediate trackpoint 1 click

This time it's complete recording, but still no real traces, only the button 1 click is in the log.
Comment 36 Vladimir Kondratyev freebsd_committer 2018-10-31 21:24:20 UTC
(In reply to Michael Figiel from comment #35)
If your touchpad has a middle button than these spurious clicks are result of merging of button bits from 2 devices. Synaptics 6 byte protocol maps left button of 2-nd 3bytes to a middle button.

Starting from Oct 31 20:21:31 :

psmintr: 88 00 00 e1 ce c2 <- TPad   1-st 3of6. Left button is still released
psmintr: c9 00 00 c0 00 00 <- TPad   2-nd 3of6. Middle button is pressed!!!
psmintr: 09 00 00 e1 e5 69 <- TPoint Left button is pressed
psmintr: 89 00 00 c0 00 00 <- TPad   1-st 3of6. Left button is pressed
psmintr: c9 00 00 e5 c4 27 <- TPad   2-nd 3of6. Middle button is released!!! (bit 0 of byte 0 is set but it is XOR-ed with left button)
psmintr: 89 00 00 c0 00 00 <- TPad   1-st 3of6. Left button is still pressed
psmintr: c9 00 00 c1 01 01 <- TPad   2-nd 3of6. Middle button is released
psmintr: 89 00 00 c0 00 00 <- TPad   1-st 3of6. Left button is still pressed
psmintr: c9 00 00 c1 01 01 <- TPad   2-nd 3of6. Middle button is released
psmintr: 89 00 00 c0 00 00 <- TPad   1-st 3of6. Left button is still pressed
psmintr: c9 00 00 c1 01 01 <- TPad   2-nd 3of6. Middle button is released
synaptics: button RELEASE: 1 
psmintr: 89 00 00 c0 00 00 <- TPad   1-st 3of6. Left button is still pressed
psmintr: 08 00 00 c1 01 01 <- TPoint Left button is released
psmintr: c8 00 00 c0 00 00 <- TPad   2-nd 3of6. Middle button is pressed!!! (bit 0 of byte 0 is unset but it is XOR-ed with left button)
psmintr: 88 00 00 c1 01 01 <- TPad   1-st 3of6. Left button is released
psmintr: c8 00 00 c0 00 00 <- TPad   2-nd 3of6. Middle button is released

I do not know an easy way to fix it.
Comment 37 Vladimir Kondratyev freebsd_committer 2018-10-31 21:28:36 UTC
(In reply to Vladimir Kondratyev from comment #36)
> I do not know an easy way to fix it.
Except just disabling touchpad's middle button
Comment 38 Michael Figiel 2018-11-01 11:28:00 UTC
(In reply to Vladimir Kondratyev from comment #37)
Maybe, make it configurable via sysctl? Default setting would be to have all three touchpad buttons and if someone runs into the problem frequently, they can disable the (touchpad's) middle button.

Rationale:
The problem with the spurious clicks occurs only with this very specific hw configuraton (muxer, trackpoint and 3-buttons) and sequence of events. In my workflow, I noticed it maybe twice in the last two weeks - using the machine daily for several hours. 
Maybe a different workflow/desktop environment intensifies the problem, but then disabling the touchpad's middle button with sysctl is acceptable, IMHO - you'd still be left with one working middle button.
Comment 39 Vladimir Kondratyev freebsd_committer 2018-11-01 12:51:41 UTC
Created attachment 198852 [details]
disable middle button if touchpad or trackpoint is active

Try attached patch on top of previous one. It should disable middle button only if touchpad or trackpoint is active so it should still work being pressed standalone.

I hope touchpad's button press does not generate 1 second of trailing packets.
Comment 40 Michael Figiel 2018-11-01 16:26:45 UTC
(In reply to Vladimir Kondratyev from comment #39)
on the positive site: I can't reproduce the spurious middle button events any more.
but it appears, that the touchpad's middle button is now disabled permanently: not even after a quiescence period of 10s are any middle button events reported.
Comment 41 Vladimir Kondratyev freebsd_committer 2018-11-01 18:04:51 UTC
(In reply to Michael Figiel from comment #40)
> touchpad's middle button is now disabled permanently

Could you check what is going on while you are pressing and releasing the middle button. Does your touchpad send only 2 packets (press and release) like trackstick does or it continuously repeats 'button is pressed' packet every 0.015 sec or so?
Comment 42 Michael Figiel 2018-11-01 18:41:34 UTC
Created attachment 198863 [details]
touchpad middle button press-hold-release

It's more then one/two packets. I kept the button pressed, but after the "psmsoftintridle: 80 00 00 c1 00 00" message, no new records appeared. 
The following records resulted from releasing the button.
Comment 43 Vladimir Kondratyev freebsd_committer 2018-11-01 23:13:40 UTC
Created attachment 198878 [details]
disable middle button if trackpoint is active

Next version :-)

Try this patch on top of attachment #198791 [details].
Comment 44 Michael Figiel 2018-11-02 07:58:11 UTC
(In reply to Vladimir Kondratyev from comment #43)
OK, all six buttons are working, but the spurious middle button is back, too.
It appears, that the false middle button press/release is reported most of the time only once, but at east once it was reported twice. Previously, that happened more frequently - but that may be an artifact of my form of day :-/
Comment 45 Vladimir Kondratyev freebsd_committer 2018-11-02 08:41:57 UTC
Created attachment 198880 [details]
disable middle button if trackpoint is active

Wrong buffer was checked for middle button press.

Next version is ready.
Comment 46 Michael Figiel 2018-11-02 09:39:12 UTC
(In reply to Vladimir Kondratyev from comment #45)
mid-air collision :-)
OK, I applied the new patch and it works: all buttons reporting, no spurious middle button clicks in xev/clients. It appears that everything is OK.

But, that's what I was writing before "colliding" with the new patch:
I use kernel woth evdev, no moused, xorg with udev and libinput.
libinput-list-devices returns three potential pointers:
event0 : System Mouse -- that one remains mute, never ever any events
event3 : Syn Touchpad
event4 : Gen PS/2 -- the trackpoint
I started to use evemu-record to watch the events on the three devices.

with the patch 198880:

* click on left trackpoint button after a quiescence period reports press/release on event4
* tap/touch touchpad and click on left trackpoint separated by less than 1s produce left press/release on event3 and event4; occasionally, additional middle press/release is reported on event4 -- but that's  rare maybe one in 20 clicks? I can't reproduce it reliably. however, I'm pretty sure, that xev doesn't report any spurious middle button events.

with the 198878 the behaviour was slightly different:

* clicking left trackpoint button after a quiescence period was reported on event4 only
* tap/touch and click on left tp button separated by less than 0.5s reported middle+left press/release on event3 and left press/release on event4 (it was easy to reproduce)
* tap/touch and click on left tp button separated by 0.5-1s reported left press/release on both event3 and event4

I'm not sure if it's a problem to have the events duplicated - I did not observe any negative consequences yet, however my testing is far from exhaustive.
Comment 47 Vladimir Kondratyev freebsd_committer 2018-11-02 21:53:02 UTC
Created attachment 198898 [details]
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis

> event0 : System Mouse -- that one remains mute, never ever any events
sysctl kern.evdev.rcpt_mask=12 makes it ever silent

> * click on left trackpoint button after a quiescence
> period reports press/release on event4
It is expected as mux merges button bits of both devices. Unfortunately at this point source info is lost so we can only guess who has produced the press event.

> I'm not sure if it's a problem to have the events
> duplicated - I did not observe any negative consequences yet,
> however my testing is far from exhaustive.
I prepared next patch with different approach to duplicate/spurious events problem:
It prefers trackpoint buttons over touchpad ones to remove duplicates and adds a hysteresis loop to filter out spurious touchpad button presses
Comment 48 Michael Figiel 2018-11-03 18:16:26 UTC
(In reply to Vladimir Kondratyev from comment #47)
>> event0 : System Mouse -- that one remains mute, never ever any events
> sysctl kern.evdev.rcpt_mask=12 makes it ever silent
OK, thanks for the explanation

> I prepared next patch with different approach to duplicate/spurious events 
> problem:
> It prefers trackpoint buttons over touchpad ones to remove duplicates and adds a hysteresis loop to filter out spurious touchpad button presses

OK, the spurious middle button clicks are fixed and I could not observe any dupplicate button events.
But there is a new problem, this time it's the track points middle button:
a sequence of touching/tapping the touchpad and pressing the trackpoints middle button and keeping it pressed results in maybe a second of movement events reported from trackpoint. After the second, the events stop regardless of keeping the button pressed:
E: 558.341129 0002 0000 0001	# EV_REL / REL_X                1
E: 558.341129 0002 0001 -001	# EV_REL / REL_Y                -1
E: 558.341129 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +16ms
using the touchpad and just clicking the trackpoints middle button produces 0-6 of the movement events.
Comment 49 Vladimir Kondratyev freebsd_committer 2018-11-03 18:55:53 UTC
(In reply to Michael Figiel from comment #48)
Try to replace line 4984:

trbutt = pb->ipacket[0] & 0x03;

with

trbutt = pb->ipacket[0] & 0x07;
Comment 50 Vladimir Kondratyev freebsd_committer 2018-11-04 08:23:31 UTC
Created attachment 198926 [details]
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis

One extra step to prevent trackpoint's movement & middle button press interference
Comment 51 Michael Figiel 2018-11-04 09:19:22 UTC
(In reply to Vladimir Kondratyev from comment #50)
The last patch and the one line change behave the same: no spurious movement events. But both produce spurious trackpoint middle button events, very infrequently, however. I can't really reproduce it very reliable. 

The sequence is: touch touchpad and then trackpoint left button; a spurious trackpoint middle button event is reported.

Besides that, everything seems to work. 

I'm runnig low on battery now, I'll be back in fife or six hours :-/
Comment 52 Vladimir Kondratyev freebsd_committer 2018-11-04 11:36:37 UTC
Created attachment 198934 [details]
prefer trackpoint buttons over touchpad's + touchpad button state hysteresis

+ disables middle trackpoint button if left or right trackpoint button is being pressed or released simultaneously
Comment 53 Michael Figiel 2018-11-04 18:24:06 UTC
(In reply to Vladimir Kondratyev from comment #52)
it looks good, no spurious events so far, neither clicks nor movements. 
Everything works: touchpad, trackpoint and all six buttons.
Comment 54 Vladimir Kondratyev freebsd_committer 2018-11-05 22:50:19 UTC
(In reply to Michael Figiel from comment #53)
> it looks good, no spurious events so far, neither clicks nor movements. 
> Everything works: touchpad, trackpoint and all six buttons.

Excellent!

It worth trying to reduce hysteresis lag:
Could you replace 3 with 2 or with 1 in following condition: "sc->fpcount < 3" (line 4971) and retest for spurious middle touchpad button events?
Comment 55 Michael Figiel 2018-11-06 10:49:49 UTC
(In reply to Vladimir Kondratyev from comment #54)

"sc->fpcount < 1": everything works, no spurious events.
Comment 56 Michael Figiel 2018-11-06 11:43:31 UTC
(In reply to Michael Figiel from comment #55)
"sc->fpcount < 2" : everything works, too. no spurious events.
Comment 57 Vladimir Kondratyev freebsd_committer 2018-11-10 21:53:48 UTC
Created attachment 199114 [details]
touchpad/trackpoint coexistence patch

Hopefully, final version. Just refactored, no functional changes. To be applied on top of plain sources.
Comment 58 Michael Figiel 2018-11-11 09:40:21 UTC
(In reply to Vladimir Kondratyev from comment #57)
Great! I built and deployed it, and it worked correctly - most of the time :-/

I've got some issues with libinput, I assume, but there was one case of spurious events - I can't reproduce it. I touched the trackpoint to move the cursor and three trackpoint middle button press/release events were generated. I've seen them in evemu-record log. As I can't reproduce it, give me a few days more time, maybe I can figure out a way to reproduce/record the problem.
Comment 59 Vladimir Kondratyev freebsd_committer 2018-11-11 12:26:26 UTC
(In reply to Michael Figiel from comment #58)
> I touched the trackpoint to move the cursor and three trackpoint middle button press/release events were generated.
I bet, your palm was touching or hovering the touchpad same time.
Comment 60 Michael Figiel 2018-11-14 21:35:30 UTC
(In reply to Vladimir Kondratyev from comment #59)
Yes, you are right, I finally reproduced it: if I hover my palm just over the touchpad and move the trackpoint, the touchpad doesn't generate any events but the trackpoint generates a middle button press/release events additionally to the movement events. But you have to get the palm distance  just right to reproduce it. Occasionally, only middle button pressed event is generated and as I configured the middle button pressed + trackpoint movement to be interpreted as scroll events, I can scroll with trackpoint :-)

Besides that, everything works nicely - I used the maxhine the last few days without any problems.
Comment 61 Vladimir Kondratyev freebsd_committer 2018-11-17 15:57:25 UTC
Created attachment 199294 [details]
mute trackpoint's middle button if touchpad is active (singletouch case)

> if I hover my palm just over the touchpad and move the trackpoint,
> the touchpad doesn't generate any events but the trackpoint generates
> a middle button press/release events additionally to the movement events.
Try attached patch
Comment 62 Michael Figiel 2018-11-18 17:15:42 UTC
(In reply to Vladimir Kondratyev from comment #61)
No, that doesn't fix it. The trackpoint's middle button events are suppressed if I use the touchpad (left and right work), but hovering above the touchpad (not touching) and moving trackpoint produces middle button events.
However, contrary to my previous report, hovering generates touchpad events (I'm pretty sure I haven't seen them last time, but maybe I mixed up the devices?). Sorry for spreading confusion.
The touchpad events are  strange - the pressure value reported is way higher than normally touching/cliking): 230 vs normally clicking 80-90
It was not a palm, but two fingers hovering above, definitely not touching the pad. Another thing: sometimes only X-Postion was reported... at the same time trackpoint reported the middle button press/release events:

E: 1102.930099 0003 0039 0000	# EV_ABS / ABS_MT_TRACKING_ID   0
E: 1102.930099 0003 0035 2661	# EV_ABS / ABS_MT_POSITION_X    2661
E: 1102.930099 0003 0036 4963	# EV_ABS / ABS_MT_POSITION_Y    4963
E: 1102.930099 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 1102.930099 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1102.930099 0003 0000 2661	# EV_ABS / ABS_X                2661
E: 1102.930099 0003 0001 4963	# EV_ABS / ABS_Y                4963
E: 1102.930099 0003 0018 0223	# EV_ABS / ABS_PRESSURE         223
E: 1102.930099 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +15ms
E: 1102.947960 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1102.947960 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 1102.947960 0001 014d 0000	# EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1102.947960 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 1102.947960 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +17ms
E: 1102.995703 0003 0039 0000	# EV_ABS / ABS_MT_TRACKING_ID   0
E: 1102.995703 0003 0035 2917	# EV_ABS / ABS_MT_POSITION_X    2917
E: 1102.995703 0003 003a 0232	# EV_ABS / ABS_MT_PRESSURE      232
E: 1102.995703 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 1102.995703 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1102.995703 0003 0000 2917	# EV_ABS / ABS_X                2917
E: 1102.995703 0003 0018 0232	# EV_ABS / ABS_PRESSURE         232
E: 1102.995703 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +48ms
E: 1103.012554 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1103.012554 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 1103.012554 0001 014d 0000	# EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1103.012554 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 1103.012554 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +17ms
E: 1103.218334 0003 0039 0000	# EV_ABS / ABS_MT_TRACKING_ID   0
E: 1103.218334 0003 0035 3173	# EV_ABS / ABS_MT_POSITION_X    3173
E: 1103.218334 0003 0036 5218	# EV_ABS / ABS_MT_POSITION_Y    5218
E: 1103.218334 0003 003a 0238	# EV_ABS / ABS_MT_PRESSURE      238
E: 1103.218334 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 1103.218334 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1103.218334 0003 0000 3173	# EV_ABS / ABS_X                3173
E: 1103.218334 0003 0001 5218	# EV_ABS / ABS_Y                5218
E: 1103.218334 0003 0018 0238	# EV_ABS / ABS_PRESSURE         238
E: 1103.218334 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +206ms
E: 1103.233195 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1103.233195 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 1103.233195 0001 014d 0000	# EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1103.233195 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 1103.233195 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +15ms
E: 1103.282852 0003 0039 0000	# EV_ABS / ABS_MT_TRACKING_ID   0
E: 1103.282852 0003 003a 0232	# EV_ABS / ABS_MT_PRESSURE      232
E: 1103.282852 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 1103.282852 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1103.282852 0003 0018 0232	# EV_ABS / ABS_PRESSURE         232
E: 1103.282852 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +49ms
E: 1103.296776 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1103.296776 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 1103.296776 0001 014d 0000	# EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1103.296776 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 1103.296776 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +14ms
E: 1103.311722 0003 0039 0000	# EV_ABS / ABS_MT_TRACKING_ID   0
E: 1103.311722 0003 0035 2149	# EV_ABS / ABS_MT_POSITION_X    2149
E: 1103.311722 0003 003a 0239	# EV_ABS / ABS_MT_PRESSURE      239
E: 1103.311722 0001 014a 0001	# EV_KEY / BTN_TOUCH            1
E: 1103.311722 0001 014d 0001	# EV_KEY / BTN_TOOL_DOUBLETAP   1
E: 1103.311722 0003 0000 2149	# EV_ABS / ABS_X                2149
E: 1103.311722 0003 0018 0239	# EV_ABS / ABS_PRESSURE         239
E: 1103.311722 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +15ms
E: 1103.328564 0003 0039 -001	# EV_ABS / ABS_MT_TRACKING_ID   -1
E: 1103.328564 0001 014a 0000	# EV_KEY / BTN_TOUCH            0
E: 1103.328564 0001 014d 0000	# EV_KEY / BTN_TOOL_DOUBLETAP   0
E: 1103.328564 0003 0018 0000	# EV_ABS / ABS_PRESSURE         0
E: 1103.328564 0000 0000 0001	# ------------ SYN_REPORT (1) ---------- +17ms
Comment 63 Vladimir Kondratyev freebsd_committer 2018-11-18 18:43:51 UTC
Created attachment 199322 [details]
mute trackpoint's middle button if touchpad is active

> However, contrary to my previous report, hovering generates
> touchpad events (I'm pretty sure I haven't seen them last time,
> but maybe I mixed up the devices?). Sorry for spreading confusion.
There is no palm detection for 2 finger touches on semi-mt touchpads yet. 

> sometimes only X-Postion was reported...
It means that Y-position remains the same

Try next patch :-)
Comment 64 Michael Figiel 2018-11-18 21:51:09 UTC
Created attachment 199327 [details]
syslog, palm hovering just above the touchpad

No, it doesn't work. No spurious middle button events, but somtimes middle button doesn't generate anything (here me clicking repeatedly the middle button, syslog, debug.psm.loglevel=5):

psmintr: 08 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00
psmintr: 0c 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00
psmintr: 08 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00
psmintr: 0c 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00
psmintr: 08 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00
psmintr: 0c 00 00 c4 00 00
synaptics: 84 08 00 c4 00 00

in the attached file, the data did not result in any touchpad events being generated.
As long as the touchpad sends the data, trackpoints middle button is suppressed, but as mentioned above, occasionally it remains suppressed for a longer time.
Comment 65 Vladimir Kondratyev freebsd_committer 2018-11-18 22:48:54 UTC
(In reply to Michael Figiel from comment #64)
I was able to reproduce dirty trailing packets with my touchpad.

Could you replace

sc->muxsave[2] != 0

with

sc->muxsave[2] > 8

in last patch?

It may be necessary to use 9 or 10 instead of 8 as pressure threshold as I can not find exact value in specs just now.
Comment 66 Vladimir Kondratyev freebsd_committer 2018-11-19 00:24:56 UTC
Created attachment 199329 [details]
mute trackpoint's middle button if touchpad is active

Middle trackpoint button suppression timeout of 0.1 sec added.
Comment 67 Michael Figiel 2018-11-19 08:57:04 UTC
(In reply to Vladimir Kondratyev from comment #66)
I applied the patch (third hunk didn't apply cleanly but I inserted the changes manually). 
I tested it with:
sc->muxsave[2] != 0
   a few times a middle button press event without corresponding release event was generated. some times the missing event arrived 2-3 seconds later. Most of the time the middle button is inhibited if I try to use the trackpoint with my hands on the keyboard - a part of my palm is apparently detected hovering above the touchpad.


sc->muxsave[2] > 8
sc->muxsave[2] > 10
   both work well, not much difference between these two. I've got far fewer middle clicks suppressed - actually I have to hit rather markedly the upper edge of the touchpad while attempting to press the middle button for the suppression to kick in.

I think it works OK now (with threshold 8 or 10); while the disabling of the middle button is unfortunate, the setup works predictable and reliable if you _know_ about it. The behaviour may be confusing if someone disables the touchpad (e.g. with xinput) in order to exclusively use the trackpoint - the middle button events will still get suppressed if the touchpad registers anything.

At least on this machine, the touchpad doesn't react properly to the PS/2 command 'disable device' - so, no chance to separate and suppress its data stream...
Comment 68 Vladimir Kondratyev freebsd_committer 2018-11-19 21:27:05 UTC
(In reply to Michael Figiel from comment #67)
> I applied the patch (third hunk didn't apply cleanly but
> I inserted the changes manually). 
It is a diff to 199114 rather than to previous version of 199329

> a few times a middle button press event without corresponding
> release event was generated.
That is strange. No trackpoint events are discarded with this patch.

> I think it works OK now (with threshold 8 or 10); while the
> disabling of the middle button is unfortunate, the setup works
> predictable and reliable if you _know_ about it.
Ok. I should mention it in commit message.

> The behaviour may be confusing if someone disables the touchpad
> (e.g. with xinput) in order to exclusively use the trackpoint
> - the middle button events will still get suppressed if the
> touchpad registers anything.
try 'sysctl hw.psm.synaptics.min_pressure=255' hack - it disables touch surface leaving touchpad buttons active

> At least on this machine, the touchpad doesn't react properly
> to the PS/2 command 'disable device' - so, no chance to
> separate and suppress its data stream...
IIRC, to disable PS/2 device reliably you should disable port, device and interrupts all at once. See psmclose() or psmopen() routine sources.

Thanks for testing!
Comment 69 Michael Figiel 2018-11-21 18:04:45 UTC
(In reply to Vladimir Kondratyev from comment #68)
> try 'sysctl hw.psm.synaptics.min_pressure=255' hack - it disables touch surface
> leaving touchpad buttons active
Oh, that's a nice trick, haven't thought of that.

> IIRC, to disable PS/2 device reliably you should disable port, device and 
> interrupts all at once. See psmclose() or psmopen() routine sources.
That should do it, but it's a no-go with multiplexers :-)

Anyways, I found no new other problems, thank for your work on this!
Comment 70 commit-hook freebsd_committer 2018-11-24 21:24:11 UTC
A commit references this bug:

Author: wulf
Date: Sat Nov 24 21:23:13 UTC 2018
New revision: 340913
URL: https://svnweb.freebsd.org/changeset/base/340913

Log:
  psm(4): Add minimal support for active AUX port multiplexers

  Active PS/2 multiplexing is a method for attaching up to four PS/2
  pointing devices to a computer. Enabling of multiplexed mode allows
  commands to be directed to individual devices using routing prefixes.
  Multiplexed mode reports input with each byte tagged to identify
  its source. This method differs from one currently supported by psm(4)
  where so called guest device (trackpoint) is attached to special
  interface located on the host device (touchpad) and latter performs
  guest protocol conversion to special encapsulation packet format.

  At present time active PS/2 multiplexing is used in some models of
  HP laptops e.g. EliteBook 8560w, 9470m. Enabling of absolute operation
  mode on such touchpads is connected with following problems:
  1. Touchpad's port priority is lower than trackpoint's. That blocks
     information queries thus prevents touchpad detection and configuration.
  2. Touchpad and trackpoint have different protocol packet sizes and
     sync bytes.

  As PS/2 usage is on decline only minimal possible set of changes to
  support Synaptics touchpad and generic mouses is implemented.
  Active multiplexing mode is enabled only at probe stage to scan through
  attached PS/2 devices to query and configure Synaptics touchpad.
  After touchpad has been configured, mux is switched back to legacy
  (hidden multiplexing) mode to perform normal interrupt-driven input
  data processing. Overflow bit values rather than tags are used to
  separate packets produced by different devices. Switching back to
  legacy mode allows to avoid psm(4) and atkbd(4) rework to support
  4 instances of mouse driver.

  Note: While in hidden multiplexing mode KBC does some editing of the
  packet stream. It remembers the button bits from the last packet
  received from each device, and replaces the button bits of every
  packet with the logical OR of all devices? most recent button bits.
  This sort of button crosstalk results in spurious button events
  which are inhibitted with various tricks. E.g. trackpoint middle
  button events are suppressed while trackpad surface is touched and
  touchpad left and right button events are suppressed if corresponding
  trackpoint buttons are pressed.

  PR:		231058
  Reported by:	Michael Figiel <mifigiel@gmail.com>
  Tested by:	Michael Figiel <mifigiel@gmail.com>
  MFC after:	2 weeks

Changes:
  head/sys/dev/atkbdc/atkbdc.c
  head/sys/dev/atkbdc/atkbdcreg.h
  head/sys/dev/atkbdc/psm.c
Comment 71 commit-hook freebsd_committer 2019-01-18 21:11:31 UTC
A commit references this bug:

Author: wulf
Date: Fri Jan 18 21:11:03 UTC 2019
New revision: 343157
URL: https://svnweb.freebsd.org/changeset/base/343157

Log:
  MFC r340912,r340913:

  psm(4): Revert r328640 and add minimal support for active AUX port
          multiplexers

  Active PS/2 multiplexing is a method for attaching up to four PS/2
  pointing devices to a computer. Enabling of multiplexed mode allows
  commands to be directed to individual devices using routing prefixes.
  Multiplexed mode reports input with each byte tagged to identify
  its source. This method differs from one currently supported by psm(4)
  where so called guest device (trackpoint) is attached to special
  interface located on the host device (touchpad) and latter performs
  guest protocol conversion to special encapsulation packet format.

  At present time active PS/2 multiplexing is used in some models of
  HP laptops e.g. EliteBook 8560w, 9470m. Enabling of absolute operation
  mode on such touchpads is connected with following problems:
  1. Touchpad's port priority is lower than trackpoint's. That blocks
     information queries thus prevents touchpad detection and configuration.
  2. Touchpad and trackpoint have different protocol packet sizes and
     sync bytes.

  As PS/2 usage is on decline only minimal possible set of changes to
  support Synaptics touchpad and generic mouses is implemented.
  Active multiplexing mode is enabled only at probe stage to scan through
  attached PS/2 devices to query and configure Synaptics touchpad.
  After touchpad has been configured, mux is switched back to legacy
  (hidden multiplexing) mode to perform normal interrupt-driven input
  data processing. Overflow bit values rather than tags are used to
  separate packets produced by different devices. Switching back to
  legacy mode allows to avoid psm(4) and atkbd(4) rework to support
  4 instances of mouse driver.

  Note: While in hidden multiplexing mode KBC does some editing of the
  packet stream. It remembers the button bits from the last packet
  received from each device, and replaces the button bits of every
  packet with the logical OR of all devices? most recent button bits.
  This sort of button crosstalk results in spurious button events
  which are inhibitted with various tricks. E.g. trackpoint middle
  button events are suppressed while trackpad surface is touched and
  touchpad left and right button events are suppressed if corresponding
  trackpoint buttons are pressed.

  PR:		231058
  Reported by:	Michael Figiel <mifigiel at gmail.com>
  Tested by:	Michael Figiel <mifigiel at gmail.com>

Changes:
_U  stable/12/
  stable/12/sys/dev/atkbdc/atkbdc.c
  stable/12/sys/dev/atkbdc/atkbdcreg.h
  stable/12/sys/dev/atkbdc/psm.c
Comment 72 commit-hook freebsd_committer 2019-01-18 21:12:34 UTC
A commit references this bug:

Author: wulf
Date: Fri Jan 18 21:12:00 UTC 2019
New revision: 343158
URL: https://svnweb.freebsd.org/changeset/base/343158

Log:
  MFC r340912,r340913:

  psm(4): Revert r328640 and add minimal support for active AUX port
          multiplexers

  Active PS/2 multiplexing is a method for attaching up to four PS/2
  pointing devices to a computer. Enabling of multiplexed mode allows
  commands to be directed to individual devices using routing prefixes.
  Multiplexed mode reports input with each byte tagged to identify
  its source. This method differs from one currently supported by psm(4)
  where so called guest device (trackpoint) is attached to special
  interface located on the host device (touchpad) and latter performs
  guest protocol conversion to special encapsulation packet format.

  At present time active PS/2 multiplexing is used in some models of
  HP laptops e.g. EliteBook 8560w, 9470m. Enabling of absolute operation
  mode on such touchpads is connected with following problems:
  1. Touchpad's port priority is lower than trackpoint's. That blocks
     information queries thus prevents touchpad detection and configuration.
  2. Touchpad and trackpoint have different protocol packet sizes and
     sync bytes.

  As PS/2 usage is on decline only minimal possible set of changes to
  support Synaptics touchpad and generic mouses is implemented.
  Active multiplexing mode is enabled only at probe stage to scan through
  attached PS/2 devices to query and configure Synaptics touchpad.
  After touchpad has been configured, mux is switched back to legacy
  (hidden multiplexing) mode to perform normal interrupt-driven input
  data processing. Overflow bit values rather than tags are used to
  separate packets produced by different devices. Switching back to
  legacy mode allows to avoid psm(4) and atkbd(4) rework to support
  4 instances of mouse driver.

  Note: While in hidden multiplexing mode KBC does some editing of the
  packet stream. It remembers the button bits from the last packet
  received from each device, and replaces the button bits of every
  packet with the logical OR of all devices? most recent button bits.
  This sort of button crosstalk results in spurious button events
  which are inhibitted with various tricks. E.g. trackpoint middle
  button events are suppressed while trackpad surface is touched and
  touchpad left and right button events are suppressed if corresponding
  trackpoint buttons are pressed.

  PR:		231058
  Reported by:	Michael Figiel <mifigiel at gmail.com>
  Tested by:	Michael Figiel <mifigiel at gmail.com>

Changes:
_U  stable/11/
  stable/11/sys/dev/atkbdc/atkbdc.c
  stable/11/sys/dev/atkbdc/atkbdcreg.h
  stable/11/sys/dev/atkbdc/psm.c
Comment 73 Eirik Oeverby 2019-08-11 21:32:54 UTC
Hi,
I'm trying to make my ThinkPad X1 touchpad work, but whenever I enable synaptics support it just keeps spewing errors - "packet rejected" and "out of sync" being the most common. I'm replying on this issue because it gave me a lot of pointers; behaviour does change (but not for the better) after suspend/resume, and the debug information did bring me further. 

As a curiosity, /dev/input/event3, which is the Synaptics trackpad whether support is enabled in loader.conf or not, has never worked with libinput/evdev. I have to use event0 to make it work at all.

If I should open a new issue for this, let me know.

/Eirik
Comment 74 Vladimir Kondratyev freebsd_committer 2019-09-10 12:17:09 UTC
(In reply to Eirik Oeverby from comment #73)
> If I should open a new issue for this, let me know.

I doubt that IBMs laptops have the AUX MUX. So it is better to open a new ticket and send me a link on it.