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
atp needs a patch similar to https://cgit.freebsd.org/src/commit/?id=54d2dfc4b24db110c8a4b75e2f02a2360fd9fc8c
(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.
(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.
(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.
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.
(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.
(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!
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.
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.
(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!
(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
Created attachment 223176 [details] wsp_evdev_support.patch Basically the same patch with minor internal improvements. Not tested.
(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.
(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.
Created attachment 223223 [details] wsp_evdev_support.patch Make wspfifo-evdev open/close interaction closer to what ums(4) does
(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.
(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.
(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).
(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.
(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. […]
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)
(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.
(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.
Created attachment 223231 [details] wsp dump_all_desc Here's the USB stuff
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.
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).
Created attachment 223277 [details] bsdwsp.log
(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.
(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.
(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.
(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.
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.
(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)
Created attachment 223450 [details] wsp_evdev_support.patch
(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.
(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
Created attachment 223683 [details] wsp_evdev_support.patch Add type1 and type2 touchpad support to bcm5974. It should be on par with wsp now.
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
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.
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.
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.
The patch works flawlessly. Tracking, specifically scrolling, extraordinarily well. Thank you!
(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
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.
(In reply to Constantin Fürst from comment #44) tap-to-click is disabled in libinput by default
❯ 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.
(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
(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?
Created attachment 224949 [details] dmesg usbhid requested usbhid dmesg output
Seems like ums does attach right?
(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/
(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?
(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!
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".
Unloading from a non-x-session yielded immediate detach and reattach of hms0 and hms1 to the Touchpad.
(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)
(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.
Could you switch /boot/loader.conf to wsp now and recheck taps?
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!
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.
(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!
(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
Created attachment 224968 [details] wsp_evdev_support.patch I hope it fixes bcm probe
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)?
(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?
(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
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=8d73071c47ff1f911bdaec6356f37feb4e3b7cb5 commit 8d73071c47ff1f911bdaec6356f37feb4e3b7cb5 Author: Vladimir Kondratyev <wulf@FreeBSD.org> AuthorDate: 2021-08-24 23:01:42 +0000 Commit: Vladimir Kondratyev <wulf@FreeBSD.org> CommitDate: 2021-08-24 23:01:42 +0000 wsp(4): Add evdev support. Reviewed by: hselasky Tested by: Greg V, Constantin Furst<constantin_AT_fuersten_DOT_info> MFC after: 2 weeks PR: 252236 Differential revision: https://reviews.freebsd.org/D31653 sys/dev/usb/input/wsp.c | 305 ++++++++++++++++++++++++++++++++++++++++--- sys/modules/usb/wsp/Makefile | 4 +- 2 files changed, 287 insertions(+), 22 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=139144a7ae7c72eda955b1fbc5e31f5feb7a403a commit 139144a7ae7c72eda955b1fbc5e31f5feb7a403a Author: Vladimir Kondratyev <wulf@FreeBSD.org> AuthorDate: 2021-08-24 23:01:42 +0000 Commit: Vladimir Kondratyev <wulf@FreeBSD.org> CommitDate: 2021-09-08 00:01:07 +0000 wsp(4): Add evdev support. Reviewed by: hselasky Tested by: Greg V, Constantin Furst<constantin_AT_fuersten_DOT_info> PR: 252236 Differential revision: https://reviews.freebsd.org/D31653 (cherry picked from commit 8d73071c47ff1f911bdaec6356f37feb4e3b7cb5) sys/dev/usb/input/wsp.c | 305 ++++++++++++++++++++++++++++++++++++++++--- sys/modules/usb/wsp/Makefile | 4 +- 2 files changed, 287 insertions(+), 22 deletions(-)
Thanks for your hard work on this!