Bug 252236 - atp(4): Need EVDEV support for modern input stack
Summary: atp(4): Need EVDEV support for modern input stack
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.2-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-28 16:30 UTC by Jason W. Bacon
Modified: 2021-05-23 10:46 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
wsp_evdev_support.patch (47.22 KB, patch)
2021-02-28 23:31 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp_evdev_support.patch (50.44 KB, patch)
2021-03-10 23:01 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp_evdev_support.patch (50.24 KB, patch)
2021-03-12 22:29 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp_evdev_support.patch (51.46 KB, patch)
2021-03-13 13:47 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp dump_all_desc (5.09 KB, text/plain)
2021-03-13 15:35 UTC, Greg V
no flags Details
wsp HID dump (1.38 KB, text/plain)
2021-03-13 15:38 UTC, Greg V
no flags Details
linuxbcm.log (60.76 KB, text/plain)
2021-03-15 00:18 UTC, Greg V
no flags Details
bsdwsp.log (88.28 KB, text/plain)
2021-03-15 00:19 UTC, Greg V
no flags Details
wsp_evdev_support.patch (80.56 KB, patch)
2021-03-16 22:31 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp_evdev_support.patch (82.43 KB, patch)
2021-03-20 13:43 UTC, Vladimir Kondratyev
no flags Details | Diff
wsp_evdev_support.patch (87.97 KB, patch)
2021-03-29 15:24 UTC, Vladimir Kondratyev
no flags Details | Diff
xorg log with patched wsp, gestures fail (30.98 KB, text/plain)
2021-05-14 21:37 UTC, Constantin Fürst
no flags Details
dmesg usbhid (41.02 KB, text/plain)
2021-05-14 22:20 UTC, Constantin Fürst
no flags Details
wsp_evdev_support.patch (99.83 KB, patch)
2021-05-15 14:19 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 Jason W. Bacon freebsd_committer 2020-12-28 16:30:29 UTC
Mouse does not work in X11 under 12.2-RELEASE.  Works fine on the vt console with moused enabled.

Both my MacBook Pro 2,2 and MacBook Pro 8,3 required setting kern.evdev.rcpt_mask=3.

See also:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251149

dmesg.boot:

atp0 on uhub4
atp0: <Touchpad> on usbus1
Comment 1 Greg V 2020-12-28 19:18:05 UTC
atp needs a patch similar to https://cgit.freebsd.org/src/commit/?id=54d2dfc4b24db110c8a4b75e2f02a2360fd9fc8c
Comment 2 Vladimir Kondratyev freebsd_committer 2021-01-03 12:32:19 UTC
(In reply to Greg V from comment #1)
> atp needs a patch similar to https://cgit.freebsd.org/src/commit/?id=54d2dfc4b24db110c8a4b75e2f02a2360fd9fc8c

Unfortunately, patch should be more complex.

According to Linux and OpenBSD sources Apple's touchpad protocol does not contain touch tracking information so we have to solve so-called 'Euclidean bipartite matching problem'.

After some searching in the internet I found 3 realization of such a solver:
1. Kuhn (hungarian) algorithm from libmtdev: https://github.com/rydberg/mtdev/blob/master/src/match.c#L33
2. Lagrange relaxation method from Linux kernel: https://github.com/torvalds/linux/blob/master/drivers/input/input-mt.c#L315
3. Dinitz-Kronrod algorithm from OpenBSD: https://github.com/openbsd/src/blob/master/sys/dev/wscons/wsmouse.c#L1233

One of them have to be imported in to evdev as prerequisite for atp driver.
IMO OpenBSD code suits us better.
Comment 3 Greg V 2021-01-04 01:08:20 UTC
(In reply to Vladimir Kondratyev from comment #2)

I'm pretty sure atp already does this.
There is support for in-driver scrolling gesture recognition after all.
The code has functions named like `match_strokes_against_fingers` and so on.
In fact, IIUC it would not be possible to have *a* driver (that would track even just one finger and work as a simple mouse) without interpreting the sensor data to track fingers.
Comment 4 Vladimir Kondratyev freebsd_committer 2021-01-04 12:44:37 UTC
(In reply to Greg V from comment #3)
> I'm pretty sure atp already does this.
Yes it is. It uses some sort of naive assignment alghoritm:
https://github.com/freebsd/freebsd-src/blob/main/sys/dev/usb/input/atp.c#L1448
While it may work with sysmouse protocol, I am not sure if it will work with libinput.
Comment 5 Jason W. Bacon freebsd_committer 2021-01-04 19:29:11 UTC
All I can tell you is the mouse generally works well on my MacBook Pro with kern.evdev.rcpt_mask=3.

My only complaint, and not a serious one, is two-finger scrolling is jumpy.

FreeBSD beluga.acadix  bacon ~ 296: more /etc/X11/xorg.conf.d/30-tap.conf 
Section "InputClass"
Identifier "touchpad"
Driver "libinput"
  MatchIsTouchpad "on"
  Option "Tapping" "on"
  Option "NaturalScrolling" "on"
  Option "ClickMethod" "clickfinger"
EndSection

Some complaints in Xorg.0.log presumably because moused grabbed atp0 first:

FreeBSD beluga.acadix  bacon ~ 307: ps axw |grep moused
 1001  -  Ss      0:03.77 /usr/sbin/moused -p /dev/atp0 -t auto -I /var/run/moused.atp0.pid
 1614  -  Is      0:00.00 /usr/sbin/moused -p /dev/ums1 -t auto -I /var/run/moused.ums1.pid


[    75.608] (II) Using input driver 'libinput' for 'Touchpad'
[    75.608] (**) Touchpad: always reports core events
[    75.608] (**) Option "Device" "/dev/atp0"
[    75.608] (**) Option "_source" "server/udev"
[    75.705] (EE) xf86OpenSerial: Cannot open device /dev/atp0
        Device busy.
[    75.705] (II) atp0: opening input device '/dev/atp0' failed (Device busy).
[    75.705] (II) atp0    - failed to create input device '/dev/atp0'.
[    75.705] (EE) libinput: Touchpad: Failed to create a device for /dev/atp0
[    75.705] (EE) PreInit returned 2 for "Touchpad"
[    75.705] (II) UnloadModule: "libinput"
[    75.706] (II) config/udev: Adding input device System keyboard multiplexer (
/dev/input/event0)

Let me know if there's anything else I can provide.
Comment 6 Vladimir Kondratyev freebsd_committer 2021-01-04 21:02:08 UTC
(In reply to Jason W. Bacon from comment #5)
> My only complaint, and not a serious one, is two-finger scrolling is jumpy.

What do the word "jumpy" means? Two-finger scrolling is represented as mouse wheel rotation when kern.evdev.rcpt_mask is set to 3. So it can not be smooth by design in that case.

> Let me know if there's anything else I can provide.
Could you post device and report descriptors?

Former can be obtained with "usbconfig -d ugenX.X dump_all_desc" command and the latter with "usbhid-dump" from sysutils/usbhid-dump port. Be prepared that usbhid-dump will detach all USB HID devices!

And finally, you have one more option: webcamd.
If it does not support atp(4) just now, patch it to include drivers/input/mouse/bcm5974.c file.
Comment 7 Jason W. Bacon freebsd_committer 2021-01-04 21:41:17 UTC
(In reply to Vladimir Kondratyev from comment #6)

By jumpy I mean I move my fingers a considerable distance without any response and then the window suddenly scrolls 1/4 to 1/2 its height.

I recall reading a post by another user about this issue somewhere.  He stated that the wsp driver does much better than atp.  Like I said, though, it's not a big issue in my view.  I'd focus our time on more serious bugs that affect basic functionality before going after this one.

FreeBSD beluga.acadix  bacon ~ 299: grep ugen /var/run/dmesg.boot
ugen3.1: <Intel EHCI root HUB> at usbus3
ugen0.1: <Intel UHCI root HUB> at usbus0
ugen1.1: <Intel EHCI root HUB> at usbus1
ugen2.1: <Intel UHCI root HUB> at usbus2
ugen1.2: <vendor 0x0424 product 0x2514> at usbus1
ugen3.2: <vendor 0x0424 product 0x2514> at usbus3
ugen1.3: <Apple Inc. BRCM2070 Hub> at usbus1
ugen3.3: <Apple Computer, Inc. IR Receiver> at usbus3
ugen3.4: <Realtek 802.11n WLAN Adapter> at usbus3
ugen1.4: <vendor 0x05ac product 0x820a> at usbus1
ugen1.5: <vendor 0x05ac product 0x820b> at usbus1
ugen1.6: <Apple Inc. Bluetooth USB Host Controller> at usbus1
ugen1.7: <Apple Inc. Apple Internal Keyboard / Trackpad> at usbus1
ugen1.8: <Apple Inc. FaceTime HD Camera (Built-in)> at usbus1
ugen1.4: <vendor 0x05ac product 0x820a> at usbus1 (disconnected)
ugen1.5: <vendor 0x05ac product 0x820b> at usbus1 (disconnected)
FreeBSD beluga.acadix  bacon ~ 300: usbconfig -d ugen1.7 dump_all_desc
ugen1.7: <Apple Inc. Apple Internal Keyboard / Trackpad> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (40mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0008 
  idVendor = 0x05ac 
  idProduct = 0x0245 
  bcdDevice = 0x0108 
  iManufacturer = 0x0001  <Apple Inc.>
  iProduct = 0x0002  <Apple Internal Keyboard / Trackpad>
  iSerialNumber = 0x0000  <no string>
  bNumConfigurations = 0x0001 

 Configuration index 0

    bLength = 0x0009 
    bDescriptorType = 0x0002 
    wTotalLength = 0x0054 
    bNumInterfaces = 0x0003 
    bConfigurationValue = 0x0001 
    iConfiguration = 0x0000  <no string>
    bmAttributes = 0x00a0 
    bMaxPower = 0x0014 

    Interface 0
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0000 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0001 
      bInterfaceClass = 0x0003  <HID device>
      bInterfaceSubClass = 0x0001 
      bInterfaceProtocol = 0x0001 
      iInterface = 0x0003  <Apple Internal Keyboard>

      Additional Descriptor

      bLength = 0x09
      bDescriptorType = 0x21
      bDescriptorSubType = 0x11
       RAW dump: 
       0x00 | 0x09, 0x21, 0x11, 0x01, 0x21, 0x01, 0x22, 0x9c, 
       0x08 | 0x00

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0083  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x000a 
        bInterval = 0x0008 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 1
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0001 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0001 
      bInterfaceClass = 0x0003  <HID device>
      bInterfaceSubClass = 0x0000 
      bInterfaceProtocol = 0x0000 
      iInterface = 0x0004  <Touchpad>

      Additional Descriptor

      bLength = 0x09
      bDescriptorType = 0x21
      bDescriptorSubType = 0x11
       RAW dump: 
       0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x1b, 
       0x08 | 0x00

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0081  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0040 
        bInterval = 0x0002 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 


    Interface 2
      bLength = 0x0009 
      bDescriptorType = 0x0004 
      bInterfaceNumber = 0x0002 
      bAlternateSetting = 0x0000 
      bNumEndpoints = 0x0001 
      bInterfaceClass = 0x0003  <HID device>
      bInterfaceSubClass = 0x0001 
      bInterfaceProtocol = 0x0002 
      iInterface = 0x0004  <Touchpad>

      Additional Descriptor

      bLength = 0x09
      bDescriptorType = 0x21
      bDescriptorSubType = 0x11
       RAW dump: 
       0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x34, 
       0x08 | 0x00

     Endpoint 0
        bLength = 0x0007 
        bDescriptorType = 0x0005 
        bEndpointAddress = 0x0084  <IN>
        bmAttributes = 0x0003  <INTERRUPT>
        wMaxPacketSize = 0x0008 
        bInterval = 0x0008 
        bRefresh = 0x0000 
        bSynchAddress = 0x0000 

Thanks!
Comment 8 Vladimir Kondratyev freebsd_committer 2021-02-28 23:31:01 UTC
Created attachment 222890 [details]
wsp_evdev_support.patch

Finally, I imported OpenBSD touch-tracking code and modified wsp driver to use it.

Enclosed patch is done for FreeBSD 13/14. It is not tested yet.
Comment 9 Jason W. Bacon freebsd_committer 2021-03-01 01:41:32 UTC
FYI, I got wsp working, almost.  Originally wsp wasn't detecting my touchpad and I thought my old hardware might not be supported.  Today I spent a little time on it and discovered that it will recognize my touch pad if I don't load atp first.  So I commented out atp_load in /boot/loader.conf and added wsp_load.

With wsp, two-finger scrolling works much better.

However, I cannot drag a window.  When I click on a title bar, the cursor changes to the "drag" appearance, but when I move it, it either goes back to a regular cursor or something gets very confused and issues a right-click.

This is with moused enabled.  With moused disabled, Xorg crashes on startup.

So wsp is not usable on on this MacBook with 12.2-RELEASE.  I'll likely try it on 13.0 before submitting a separate PR.
Comment 10 Vladimir Kondratyev freebsd_committer 2021-03-01 20:25:54 UTC
(In reply to Jason W. Bacon from comment #9)

> So wsp is not usable on on this MacBook with 12.2-RELEASE.

Setting kern.evdev.rcpt_mask to 12, that is what aforementioned patch is addressing, effectively disables any driver's gesture handling, so you would not notice any difference between atp and wsp.

> I'll likely try it on 13.0 before submitting a separate PR.

IMO, submitting of a separate PR regarding handling of obsolete sysmouse protocol is a wasting of CPU time spent in incrementing of PR counter. Please, try wsp_evdev_support.patch patch on 13+ before!
Comment 11 Jason W. Bacon freebsd_committer 2021-03-02 18:29:08 UTC
(In reply to Vladimir Kondratyev from comment #10)

> Setting kern.evdev.rcpt_mask to 12, that is what aforementioned patch is 
> addressing, effectively disables any driver's gesture handling, so you would 
> not notice any difference between atp and wsp.

Set to 3, I get a mostly functional wsp driver except for the inability to drag windows.

Set to 12, wsp does not work at all under Xorg, just like atp.

I plan to try 13.0 ASAP and we can focus on that.

Thanks,

   JB
Comment 12 Vladimir Kondratyev freebsd_committer 2021-03-10 23:01:14 UTC
Created attachment 223176 [details]
wsp_evdev_support.patch

Basically the same patch with minor internal improvements. Not tested.
Comment 13 Jason W. Bacon freebsd_committer 2021-03-12 17:17:15 UTC
(In reply to Vladimir Kondratyev from comment #12)

Interestingly, this patch applies cleanly to 12.2-RELEASE as well.

For now, I only applied the patch to a copy of src out of curiosity.  I'll try a buildkernel on 12.2 when I'm ready to move to 13 and sacrifice the current installation.  Will report back on whether it actually works in case there's any interest in merging into 12.
Comment 14 Greg V 2021-03-12 20:33:25 UTC
(In reply to Vladimir Kondratyev from comment #12)

Testing on MacBookPro12,1 (BTW this is the amazing generation that supports both USB and SPI, so I'm trying to do something with SPI as well)

1. wasted quite some time trying to "fix" wsp_probe before realizing that it was probing other things — the actual touchpad interface was occupied by usbhid!
As a workaround, added a (uaa->info.idVendor == 0x5ac && uaa->info.bIfaceIndex == 2) check to usbhid_probe.

2. the touchpad's evdev only reports events when moused is running (i.e. /dev/wsp0 is open)!

3. after just starting moused, there's initially an uhhh stuck finger?? Basically no evdev events for just single finger movement, then adding a second finger makes one finger show up. Then it usually gets unstuck quickly after ending the touches (???) and everything starts working properly. At least from libinput debug-events I can see that 2-3-4 finger gestures get recognized correctly.
Comment 15 Vladimir Kondratyev freebsd_committer 2021-03-12 22:29:47 UTC
Created attachment 223223 [details]
wsp_evdev_support.patch

Make wspfifo-evdev open/close interaction closer to what ums(4) does
Comment 16 Vladimir Kondratyev freebsd_committer 2021-03-12 22:36:27 UTC
(In reply to Greg V from comment #14)
> 1. wasted quite some time trying to "fix" wsp_probe
wsp IDS should be blacklisted in usbhid quirk table

> 2. the touchpad's evdev only reports events when moused is running (i.e. /dev/wsp0 is open)!
Try updated patch.

> 3. after just starting moused, there's initially an uhhh stuck finger?
Some debug info is required, wsp log (sysctl hw.usb.wsp.wsp_debug=5) and corresponding evemu-record output.
Comment 17 Vladimir Kondratyev freebsd_committer 2021-03-12 22:40:16 UTC
(In reply to Jason W. Bacon from comment #13)
> Interestingly, this patch applies cleanly to 12.2-RELEASE as well.

It wont even compile under 12.2.
Comment 18 Greg V 2021-03-12 23:50:31 UTC
(In reply to Vladimir Kondratyev from comment #16)

> wsp IDS should be blacklisted in usbhid quirk table

hmm right now quirks can only exclude a whole device, not just an interface. That would prevent usbhid from attaching to the keyboard interface.

> Try updated patch.

Looks like it didn't help.

hmm does the usb_fifo_alloc_buffer stuff matter?

(also looks like closing moused would always kill evdev events -  wsp_fifo_stop_read doesn't check for evdev)

> Some debug info is required

Oops, actually, there are events on evemu as soon as moused is up. They're just not accepted by libinput.

Looks like the missing thing is the initial MT_SLOT 0 (for the first events, before any extra fingers arrive).
Comment 19 Vladimir Kondratyev freebsd_committer 2021-03-13 00:51:07 UTC
(In reply to Greg V from comment #18)
> hmm right now quirks can only exclude a whole device, not just an interface.
> That would prevent usbhid from attaching to the keyboard interface.
Does touchpad interface have a HID report descriptor?
If it has and it is properly sized, we can move wsp to hidbus.
If no than we can try to ignore HID-class usb devices which do not have report descriptor or boot protocol support.

> Looks like it didn't help.
That is strange. USB xfers starts with calling of usbd_transfer_start() in wsp_start_read(), and I can`t understand yet what blocks them when wsp_ev_open() is called from evdev when event device node is open()-ed.

> hmm does the usb_fifo_alloc_buffer stuff matter?
Directly only for /dev/wsp0 

> (also looks like closing moused would always kill evdev events -
> wsp_fifo_stop_read doesn't check for evdev)
Yes. This is inherited from ums(4). I tried to fix this in previous patch but it appeared to be broken too.
Comment 20 Greg V 2021-03-13 10:12:04 UTC
(In reply to Vladimir Kondratyev from comment #19)

> Does touchpad interface have a HID report descriptor?

Yes, it's a working basic hms mouse before switching to raw mode. There's a comment in wsp explaining this:

	 * By default the touchpad behaves like a HID device, sending
	 * packets with reportID = 8. Such reports contain only
	 * limited information. […]
Comment 21 Vladimir Kondratyev freebsd_committer 2021-03-13 13:47:43 UTC
Created attachment 223229 [details]
wsp_evdev_support.patch

Here is the next iteration of patch. Shoud fix killing of evdev events on moused close. Also adds more code from ums(4)
Comment 22 Vladimir Kondratyev freebsd_committer 2021-03-13 14:01:16 UTC
(In reply to Greg V from comment #20)
> Yes, it's a working basic hms mouse before switching to raw mode.

I need to know is trackpad's report descriptor is usable or not to recognize its interface number and size of input report. Could you post device and report descriptors here?

Former can be obtained with "usbconfig -d ugenX.X dump_all_desc" command and the latter with "usbhid-dump" from sysutils/usbhid-dump port. Be prepared that usbhid-dump will detach all USB HID devices!

Output of `hid-decode /dev/hidrawX` (from sysutils/hid-tools) and `usbhidctl -f /dev/hidrawX -r` could be useful too. hidraw.ko should be kldloaded before.
Comment 23 Jason W. Bacon freebsd_committer 2021-03-13 15:07:44 UTC
(In reply to Jason W. Bacon from comment #13)

Scratch this, typo in my grep command looking for patch failures in the output.

So this patch does not apply cleanly on 12.2.
Comment 24 Greg V 2021-03-13 15:35:57 UTC
Created attachment 223231 [details]
wsp dump_all_desc

Here's the USB stuff
Comment 25 Greg V 2021-03-13 15:38:05 UTC
Created attachment 223232 [details]
wsp HID dump

And this is HID. I use https://eleccelerator.com/usbdescreqparser/ to decode usually.

Interestingly, there is even Digitizer - Touch Pad - Vendor Defined stuff along with the mouse. I don't know if this is guaranteed to appear on all the older generations of the device. This is from Wellspring9.
Comment 26 Greg V 2021-03-15 00:18:49 UTC
Created attachment 223276 [details]
linuxbcm.log

Comparing evemu logs to Linux, the only reason I can find for libinput to not like your events very much is not sending ABS_MT_TRACKING_ID.

Here's a log from Linux, doing three simple movements, ABS_MT_TRACKING_ID clearly goes 2 → -1 → 3 → -1 → 4 → -1 according to the touches. Doing similar movements on wsp, I only see one ABS_MT_TRACKING_ID event (value 0). With my WIP SPI driver right now (which works with the exact same finger struct from the hardware), there are none, and libinput completely ignores these movements.

hmt works correctly, also reporting ABS_MT_TRACKING_ID -1 after each touch finishes (even with the new mt code).
Comment 27 Greg V 2021-03-15 00:19:03 UTC
Created attachment 223277 [details]
bsdwsp.log
Comment 28 Vladimir Kondratyev freebsd_committer 2021-03-15 01:25:03 UTC
(In reply to Greg V from comment #27)
There are no finger release events in your log.

Is it produced by my driver? or your?

If driver is your, don't forget to add

evdev_set_flag(sc->sc_evdev, EVDEV_FLAG_MT_AUTOREL);

line to evdev_register() section of driver.
Comment 29 Greg V 2021-03-15 13:28:17 UTC
(In reply to Vladimir Kondratyev from comment #28)

The log is from wsp, it has "wsp" in the name :) But of course autorel is enabled in my driver too.

I guess the matching algorithm keeps matching to the previous finger movement, so autorel never gets to detect the release.

The Linux driver skips finger data with touch_major 0, maybe that's a release signal from the hardware… so far that didn't help with my driver but I'll test this more.
Comment 30 Vladimir Kondratyev freebsd_committer 2021-03-15 13:51:13 UTC
(In reply to Greg V from comment #29)
I see a difference between our and Linux way of getting of number of touches.

They calculate it based on packet length while we read it from packet data.
Comment 31 Greg V 2021-03-15 15:31:54 UTC
(In reply to Vladimir Kondratyev from comment #30)
The number field always matches the calculated value from lengths.

But indeed touch_major 0 is key. This fixes that problem:

@@ -1109,7 +1109,7 @@ wsp_intr_callback(struct usb_xfer *xfer, usb_error_t error)
                        sc->pos_y[i] = -f->abs_y;
                        sc->index[i] = f;
 #ifdef EVDEV_SUPPORT
-                       if (evdev_rcpt_mask & EVDEV_RCPT_HW_MOUSE) {
+                       if ((evdev_rcpt_mask & EVDEV_RCPT_HW_MOUSE) && f->touch_major != 0) {
                                union evdev_mt_slot slot_data = {
                                        .id = i,
                                        .x = f->abs_x,


Also interesting: Y is `c->y.min + c->y.max - raw2int(f->abs_y)` in Linux, `params->y.max + params->y.min - f->abs_y` in wsp (min and max are swapped). But that doesn't matter at all??? Somehow o_0

Another strange problem: libinput for some reason rejects any movement when the button is clicked (that doesn't happen with hmt).

Other than that, the only remaining bug is the device opening thing.
Comment 32 Vladimir Kondratyev freebsd_committer 2021-03-16 22:31:22 UTC
Created attachment 223347 [details]
wsp_evdev_support.patch

Non-tested version with hidbus attachment (Supports only WSP9 and may be WSP8 touchpads). Previous usbus-based variant is included too.
Comment 33 Greg V 2021-03-19 14:00:24 UTC
(In reply to Vladimir Kondratyev from comment #32)

Three mistakes in the hidbus one:

- forgotten sc->sc_dev = dev
- evdev_set_methods needs dev (not sc) as second argument, because that's what hidbus_intr_start expects
- missing hidbus_set_intr(dev, bcm5974_intr, sc)

With these fixed, WSP9 works.

But it continues sending events on the hms device as well, so we get double movement :D

(btw when we have both bcm and wsp supporting this device, there's weird stuff like wsp loading instead of bcm on resume from S3 sleep)
Comment 34 Vladimir Kondratyev freebsd_committer 2021-03-20 13:43:59 UTC
Created attachment 223450 [details]
wsp_evdev_support.patch
Comment 35 Vladimir Kondratyev freebsd_committer 2021-03-20 13:57:42 UTC
(In reply to Greg V from comment #33)
> Three mistakes in the hidbus one:
Hopefully fixed.

> But it continues sending events on the hms device as well
I added dummy RAW-mode only HID report descriptor. It should workaround unwanted hms attachment.

> wsp loading instead of bcm on resume from S3 sleep)
Both wsp and atp drivers returned 0 instead of BUS_PROBE_DEFAULT from probe method on success, so no other driver had any chances to beat them. That is fixed in latest patch.
But usbhid still need to raise probe priority up to (BUS_PROBE_DEFAULT + 1) to be winner.

Also latest patch moved switching HID/RAW mode in bcm from attach/detach handlers to open/close ones and removed .025 sec delay from it to follow Linux/OpenBSD.
Comment 36 Vladimir Kondratyev freebsd_committer 2021-03-20 18:26:28 UTC
(In reply to Vladimir Kondratyev from comment #35)
> Also latest patch ... removed .025 sec delay from it to follow Linux/OpenBSD.
It looks like we can safely remove hid_get_report() and following pause() from bcm5974_set_device_mode() as we know both mode_bytes[2] sent by hid_set_report():
[0] is 0x02 - report ID
[1] is 0x01/0x00 - depending on mode
Comment 37 Vladimir Kondratyev freebsd_committer 2021-03-29 15:24:44 UTC
Created attachment 223683 [details]
wsp_evdev_support.patch

Add type1 and type2 touchpad support to bcm5974. It should be on par with wsp now.
Comment 38 Vladimir Kondratyev freebsd_committer 2021-03-29 15:50:14 UTC
Could anyone take a ruler and measure a size of active touch area of his Apple trackpad?

It is required by WIP EVDEV-awared moused https://github.com/wulf7/moused
Comment 39 Constantin Fürst 2021-05-13 16:32:06 UTC
Hello, we've talked on the forum and I'd like to do the testing. If you could give me some context on how to integrate your patch that would be very welcome. I'm quite a noob when it comes to FreeBSD but do write c++ professionally. Expect medium stupidity.
Comment 40 Constantin Fürst 2021-05-13 16:33:40 UTC
The Touchpad of my MacBook Pro 13" late 2011 is 10,5cm x 7,5cm. If I remember correctly this size is standard for all MBP until 2016.
Comment 41 Constantin Fürst 2021-05-14 16:16:25 UTC
I get an error in bcm5974:

/usr/src/sys/dev/hid/bcm5974.c:564:2: error: variable 'err' is used uninitialized whenever switch default is taken [-Werror,-Wsometimes-uninitialized]
        default:
        ^~~~~~~
/usr/src/sys/dev/hid/bcm5974.c:568:10: note: uninitialized use occurs here
        return (err);
                ^~~

Initializing with 0 now and recompiling.
Comment 42 Constantin Fürst 2021-05-14 17:29:49 UTC
The patch works flawlessly. Tracking, specifically scrolling, extraordinarily well. Thank you!
Comment 43 Vladimir Kondratyev freebsd_committer 2021-05-14 21:33:39 UTC
(In reply to Constantin Fürst from comment #42)
> The patch works flawlessly. Tracking, specifically scrolling, extraordinarily well. Thank you!

It is great to know that it works. As this patch contains 2 drivers, it is necessary to test both of them. Please do following steps:

1. Remove atp, wsp, usp and hidraw drivers from kernel config and ensure that 'device evdev' and 'options EVDEV_SUPPORT' lines are here.
2. Apply patch and rebuild kernel.
3. Test wsp(4). To do that add 'wsp_load="YES"' to /boot/loader.conf and reboot.
4. Test bcm5974(4). To do that replace previously added 'wsp_load="YES"' with 'usbhid_load="YES"' and 'hw.usb.usbhid.enable=1' lines and reboot again.

It is enough to check that tested driver is appeared as properly attachjed in console output during boot and is handled by evdev/libinput.

To do the latter check /var/log/Xorg.0.log file for presence of following line:
Using input driver 'libinput' for 'My Apple trackpad name',
and run 'libinput debug-events' or evdev-record from devel/evemu to test incoming input events
Comment 44 Constantin Fürst 2021-05-14 21:37:58 UTC
Created attachment 224948 [details]
xorg log with patched wsp, gestures fail

Touchpad gets detected and scrolling works. Gestures do not, which I first believed to be a config error of the sysctl-variables from wsp but that I ruled out now. With gestures I mean tap-to-click, two-finger-tap for right-click and two-finger-swipe for back/forward. These did work under atp without evdev.
Comment 45 Vladimir Kondratyev freebsd_committer 2021-05-14 22:00:21 UTC
(In reply to Constantin Fürst from comment #44)
tap-to-click is disabled in libinput by default
Comment 46 Constantin Fürst 2021-05-14 22:02:07 UTC
❯ doas evemu-record
Password:
Available devices:
/dev/input/event0:	System keyboard multiplexer
/dev/input/event1:	System mouse
/dev/input/event2:	Control Method Lid Switch
/dev/input/event3:	Power Button
/dev/input/event4:	Sleep Button
/dev/input/event5:	vendor 0x05ac product 0x820a, class 0/0, rev 2.00/1.00, addr 4
/dev/input/event6:	Apple Internal Keyboard
/dev/input/event7:	vendor 0x05ac product 0x820b Mouse
/dev/input/event8:	Apple Inc. Apple Internal Keyboard / Trackpad Mouse
Select the device event number [0-8]: 8
# EVEMU 1.3
# Kernel: 13.0-RELEASE
# Input device name: "Apple Inc. Apple Internal Keyboard / Trackpad Mouse"
# Input device ID: bus 0x03 vendor 0x5ac product 0x253 version 0x118
# Supported events:
#   Event type 0 (EV_SYN)
#     Event code 0 (SYN_REPORT)
#     Event code 1 (SYN_CONFIG)
#     Event code 2 (SYN_MT_REPORT)
#     Event code 3 (SYN_DROPPED)
#     Event code 4 ((null))
#     Event code 5 ((null))
#     Event code 6 ((null))
#     Event code 7 ((null))
#     Event code 8 ((null))
#     Event code 9 ((null))
#     Event code 10 ((null))
#     Event code 11 ((null))
#     Event code 12 ((null))
#     Event code 13 ((null))
#     Event code 14 ((null))
#     Event code 15 (SYN_MAX)
#   Event type 1 (EV_KEY)
#     Event code 272 (BTN_LEFT)
#     Event code 273 (BTN_RIGHT)
#     Event code 274 (BTN_MIDDLE)
#   Event type 2 (EV_REL)
#     Event code 0 (REL_X)
#     Event code 1 (REL_Y)
# Properties:
#   Property  type 0 (INPUT_PROP_POINTER)
N: Apple Inc. Apple Internal Keyboard / Trackpad Mouse
I: 0003 05ac 0253 0118
P: 01 00 00 00 00 00 00 00
B: 00 0b 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 07 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 01 00 00 00 00 00 00 00 00
B: 02 03 00 00 00 00 00 00 00
B: 03 00 00 00 00 00 00 00 00
B: 04 00 00 00 00 00 00 00 00
B: 05 00 00 00 00 00 00 00 00
B: 11 00 00 00 00 00 00 00 00
B: 12 00 00 00 00 00 00 00 00
B: 14 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
B: 15 00 00 00 00 00 00 00 00
################################
#      Waiting for events      #
################################

thats evdev output using usbhid.
Comment 47 Vladimir Kondratyev freebsd_committer 2021-05-14 22:15:01 UTC
(In reply to Constantin Fürst from comment #46)
It looks like ums is attached to touchpad rather than wsp

Try to add 'wsp_load="YES"' to /boot/loader.conf and reboot
Comment 48 Vladimir Kondratyev freebsd_committer 2021-05-14 22:18:18 UTC
(In reply to Vladimir Kondratyev from comment #47)
> thats evdev output using usbhid

Oops. Skip my previous sentence about ums. Could you post usbhid boot log here?
Comment 49 Constantin Fürst 2021-05-14 22:20:50 UTC
Created attachment 224949 [details]
dmesg usbhid

requested usbhid dmesg output
Comment 50 Constantin Fürst 2021-05-14 22:21:59 UTC
Seems like ums does attach right?
Comment 51 Vladimir Kondratyev freebsd_committer 2021-05-14 22:23:56 UTC
(In reply to Vladimir Kondratyev from comment #45)
> I first believed to be a config error of the sysctl-variables from wsp

wsp`s sysctls does not work with evdev protocol. It is up to libinput to handle gestures.

> tap-to-click is disabled in libinput by default
How-to for enabling tap-to-click:
https://forums.freebsd.org/threads/synaptics-touchpad-and-tap-to-click.77534/
Comment 52 Vladimir Kondratyev freebsd_committer 2021-05-14 22:33:27 UTC
(In reply to Constantin Fürst from comment #50)
> Seems like ums does attach right?

Ums should not attach in presence of usbhid.

In your case hms wrongly attached instead of bcm5974 as usbhid child.

What is console output if you execute '# kldunload hms' now?
Comment 53 Constantin Fürst 2021-05-14 22:35:37 UTC
(In reply to Vladimir Kondratyev from comment #51)

Sorry but I don't know what to take from that forum post. They seem to be using synaptics client, which I didn't think would work with my pad. Does it just set a libinput option or is the xorg-config for the touchpad suppoesed to fix my situation (it did not). Hope you're not getting annoyed with me. Thank you very much so far!
Comment 54 Constantin Fürst 2021-05-14 22:37:33 UTC
Unloading hms has no effect, no console out. It also does not seem to get unloaded, as a second (even third) unload did not yield any output at all, when I expected to get told something along the lines of "module not loaded".
Comment 55 Constantin Fürst 2021-05-14 22:45:09 UTC
Unloading from a non-x-session yielded immediate detach and reattach of hms0 and hms1 to the Touchpad.
Comment 56 Vladimir Kondratyev freebsd_committer 2021-05-14 22:47:32 UTC
(In reply to Constantin Fürst from comment #53)
> They seem to be using synaptics client
Initial post is about libinput.

> Sorry but I don't know what to take from that forum post.
Create /usr/local/etc/X11/xorg.conf.d/90-touchpad.conf file with following content and restart Xorg:

Section "InputClass"
        Identifier "touchpad"
        MatchIsTouchpad "on"
        Driver "libinput"
        Option "Tapping" "on"
EndSection

Taps also can be enabled from .xinitrc script or from some DE-s, but I does not remember how to do that just now. (In XFCE there is settings applet which configures taps)
Comment 57 Vladimir Kondratyev freebsd_committer 2021-05-14 22:51:58 UTC
(In reply to Constantin Fürst from comment #55)
> Unloading from a non-x-session yielded immediate detach and reattach of hms0 and hms1 to the Touchpad.

That means something broken in identify/probe handlers.
Fortunately I can test them with any other HID device. Will do it tomorrow.
Comment 58 Vladimir Kondratyev freebsd_committer 2021-05-14 22:54:12 UTC
Could you switch /boot/loader.conf to wsp now and recheck taps?
Comment 59 Constantin Fürst 2021-05-14 22:57:13 UTC
Thank you! Sleep does sounds like a good idea. If you need any logs etc. feel free to request those. If you'd like to involve me in the development process, that would also be appreciated. I do know C++ quite well but have never done non-userland programing. Good night!
Comment 60 Constantin Fürst 2021-05-14 23:02:22 UTC
tap does work with wsp_load="YES". That means that when I use usbhid, the generic hms driver gets used which does not allow advanced events. WSP does not have the conflict.
Comment 61 Vladimir Kondratyev freebsd_committer 2021-05-14 23:20:30 UTC
(In reply to Constantin Fürst from comment #60)
> tap does work with wsp_load="YES".

It is good to know that wsp works as expected. Good night!
Comment 62 Jason W. Bacon freebsd_committer 2021-05-15 13:10:02 UTC
(In reply to Vladimir Kondratyev from comment #45)

This was a recent change to default behavior.  Here's the fix:

FreeBSD coral.acadix  bacon ~/Prog/Src/desktop-installer 1006: more /etc/X11/xorg.conf.d/30-tap.conf 
Section "InputClass"
Identifier "touchpad"
Driver "libinput"
  MatchIsTouchpad "on"
  Option "Tapping" "on"
  Option "NaturalScrolling" "on"
  Option "ClickMethod" "clickfinger"
EndSection
Comment 63 Vladimir Kondratyev freebsd_committer 2021-05-15 14:19:01 UTC
Created attachment 224968 [details]
wsp_evdev_support.patch

I hope it fixes bcm probe
Comment 64 Constantin Fürst 2021-05-19 08:58:59 UTC
Sadly the latest patch did not change the behavior with the bcm driver. Are there any configuration options that are of relevance, besides 'usbhid_load="YES"' and 'hw.usb.usbhid.enable=1'? Maybe it's not the driver but some misconfig or overlap with kernel configs (although my kernel really does not contain much). What logs or config-files do you need to debug this further (If you'd like to)?
Comment 65 Vladimir Kondratyev freebsd_committer 2021-05-19 10:25:51 UTC
(In reply to Constantin Fürst from comment #64)
> Sadly the latest patch did not change the behavior
Have you got usbhid and hms attached after setting of loader tunables?
If yes, did it load bcm5974 driver automatically?
What happens is you kldload bcm5974.ko by hands?
Comment 66 Matt Anton 2021-05-23 10:46:09 UTC
(In reply to Jason W. Bacon from comment #9)

> However, I cannot drag a window.  When I click on a title bar, the cursor
> changes to the "drag" appearance, but when I move it, it either goes back
> to a regular cursor or something gets very confused and issues a 
> right-click.

I'm experiencing the same with wsp(4) on 12.2-RELEASE-p6 (MacBook Pro 9,2 here) and found that dragging and moving a window works by using 3 fingers plus the thumb to drag (that is for CSD windows).
SSD windows can be dragged/moved with one finger plus the thumb.

sysctl(8) wsp's settings used to achieve this:

hw.usb.wsp.enable_single_tap_clicks: 0
hw.usb.wsp.scr_hor_threshold: 20
hw.usb.wsp.pressure_tap_threshold: 120
hw.usb.wsp.pressure_untouch_threshold: 10
hw.usb.wsp.pressure_touch_threshold: 50
hw.usb.wsp.z_factor: 5
hw.usb.wsp.scale_factor: 12
hw.usb.wsp.debug: 1

> This is with moused enabled.  With moused disabled, Xorg crashes on startup.

I have specifically disabled moused(8) on /etc/rc.conf, still it is running:

ps aux |grep moused
root        711   0,0  0,1   11044  2376  -  Is   12:26    0:00,45 /usr/sbin/moused -p /dev/wsp0 -t auto -I /var/run/moused.wsp0.pid
root       1168   0,0  0,1   11044  2312  -  Is   12:26    0:00,00 /usr/sbin/moused -p /dev/ums1 -t auto -I /var/run/moused.ums1.pid