wireguard-openbsd/sys/dev/wscons, branch masterWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/dev/wscons?h=master2021-03-24T18:28:24ZImprove the tap detection mechanism.2021-03-24T18:28:24Zbrubru@openbsd.org2021-03-24T18:28:24Zurn:sha1:4c234c18cc0aec48b9987f859e334c8dc81e675e
Revision 1.29 of wstpad.c has removed the 'maxdist' checks
for multi-finger taps. While this change makes tap detection
more reliable, and does not affect inputs intended for pointer
movement, it might interfere with short scroll gestures.
This version reorganizes the filtering code, and reintroduces
a weaker version of those checks for MT touchpads.
Make tap detection less restrictive for multi-finger taps.2021-03-24T07:40:37Zbrubru@openbsd.org2021-03-24T07:40:37Zurn:sha1:55f93ff42336bca6334eea71f9de878a3da64c06
In order to distinguish tap gestures from short movements, the mechanism
checks whether the distance between the first and the last position of a
touch exceeds the 'maxdist' limit. Some touchpads provide unreliable
coordinates when more than one contact is being made simultaneously, and
in this case the filter may be too strong - and superfluous, because only
one-finger contacts should trigger pointer movement.
Include wstpad allocations when cleaning up wsmouse resources.2021-03-21T16:20:49Zbrubru@openbsd.org2021-03-21T16:20:49Zurn:sha1:1ab10031e6af82de1c7ba4de9be86417aa293c27
ok gnezdo@
Add WSDISPLAYIO_DEPTH_30 in order to support 30-bit color support.2021-03-12T23:42:50Zketteniskettenis@openbsd.org2021-03-12T23:42:50Zurn:sha1:1278486711992b21be9a37e27e334687ea6fa24a
ok jsg@
Add a configurable button mapping for tap gestures on touchpads.2021-03-03T19:44:37Zbrubru@openbsd.org2021-03-03T19:44:37Zurn:sha1:b1ba6288e21c5788c3a17828782da55f65f7d523
Thanks to RJ Johnson for this work!
ok mpi@
ddb: when a new wsdisplay console attaches, resize ddb cols/rows to it2021-02-09T14:37:13Zjcsjcs@openbsd.org2021-02-09T14:37:13Zurn:sha1:e63dfe66074095c741b8d86a44210de9c7cc6138
ok visa
Revert mistaken commit: Stop wsmux_attach_sc race from anton@2021-01-09T20:51:00Zgnezdognezdo@openbsd.org2021-01-09T20:51:00Zurn:sha1:0e601247a82d3ce0a07e503a16f71c7a4be28961Stop wsmux_attach_sc race from anton@2021-01-09T20:45:55Zgnezdognezdo@openbsd.org2021-01-09T20:45:55Zurn:sha1:91cdf75c577079f0e4871747ee59ffbfe1031450
OK millert@
Refactor klist insertion and removal2020-12-25T12:59:51Zvisavisa@openbsd.org2020-12-25T12:59:51Zurn:sha1:9b0cf67b268a857fffa6a742ad6be57acdc35301
Rename klist_{insert,remove}() to klist_{insert,remove}_locked().
These functions assume that the caller has locked the klist. The current
state of locking remains intact because the kernel lock is still used
with all klists.
Add new functions klist_insert() and klist_remove() that lock the klist
internally. This allows some code simplification.
OK mpi@
Fix yet another wscons race. In the same subsystem, the following2020-12-06T07:58:54Zantonanton@openbsd.org2020-12-06T07:58:54Zurn:sha1:996a5b4d63fafd69b234669968225849b5adfda2
properties must always hold true:
1. A device (wsmouse0 is this scenario) can only be opened in rw mode
once. Such device cannot be a child of a wsmux at this point as it
operates on its own event queue.
2. A device being a child of a wsmux must use the wsmux event queue
assuming the wsmux is open. Otherwise, its event queue must be NULL.
There's a race in wsmux_attach_sc() allowing a device to be part of a
mux while using its own event queue. This in turn can cause a NULL
pointer deference in wsevent_fini() while closing the same device. The
solution is to check if the race was lost, i.e. another thread managed
to open the device in rw mode while sleeping in wsmux_attach_sc().
ok gnezdo@ visa@
Reported-by: syzbot+684707f0312345a090ef@syzkaller.appspotmail.com