Bug 252236

Summary: atp(4): Need EVDEV support for modern input stack
Product: Base System Reporter: Jason W. Bacon <jwb>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Some People CC: greg, manu, wulf
Priority: --- Flags: bugzilla: maintainer-feedback? (x11)
Version: 12.2-RELEASE   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
wsp_evdev_support.patch
none
wsp_evdev_support.patch
none
wsp_evdev_support.patch
none
wsp_evdev_support.patch
none
wsp dump_all_desc
none
wsp HID dump
none
linuxbcm.log
none
bsdwsp.log
none
wsp_evdev_support.patch
none
wsp_evdev_support.patch
none
wsp_evdev_support.patch none

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