WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/dev/hid?h=jd%2Fqueueboosts 2020-06-04T23:03:43Z 2020-06-04T23:03:43Z deraadt deraadt@openbsd.org 2020-06-04T23:03:43Z urn:sha1:8cdb15fb9fef2d7ac5c96516fc49393c9fc7abfa too many PUSH. report from Andy Nguyen @ google. fix by jcs This is errata 6.6/030_hid and 6.7/008_hid 2020-05-31T18:15:36Z jcs jcs@openbsd.org 2020-05-31T18:15:36Z urn:sha1:de1eb1375deacff22dafa36d8ebe007a1dfb98f7 2020-02-10T14:35:08Z patrick patrick@openbsd.org 2020-02-10T14:35:08Z urn:sha1:8945acc287c32d5270939c2b49dfd9022ee4fdd4 we will get hid_collection and hid_endcollection items. Since hid_ endcollection apparently returns the usage of the previous item, it was possible that we "see" two items for the same usage. Make sure that we only accept hid_input items. Both hidms and hidkbd do some- thing similar, fixes the Pinebook Pro's trackpad. ok kettenis@ 2019-12-17T13:08:54Z reyk reyk@openbsd.org 2019-12-17T13:08:54Z urn:sha1:1ba9f8e24a930839b47e1417a70ad7b6ffac57d7 While FIDO/U2F keys were already supported by the generic uhid(4) driver, this driver adds the first step to tighten the security of FIDO/U2F access. Specifically, users don't need read/write access to all USB/HID devices anymore and the driver also improves integration with pledge(2) and unveil(2): It is pledge-friendly because it doesn't require any ioctls to discover the device and unveil-friendly because it uses a single /dev/fido/* directory for its device nodes. It also allows to support FIDO/U2F in firefox without further weakening the "sandbox" of the browser. Firefox does not have a proper privsep design and many operations, such as U2F access, are handled directly by the main process. This means that the browser's "fat" main process needs direct read/write access to all USB HID devices, at least on other operating systems. With fido(4) we can support security keys in Firefox under OpenBSD without such a compromise. With this change, libfido2 stops using the ioctl to query the device vendor/product and just assumes "OpenBSD" "fido(4)" instead. The ioctl is still supported but there was no benefit in obtaining the vendor product or name; it also allows to use libfido2 under pledge. With feedback from deraadt@ and many others OK kettenis@ djm@ and jmc@ for the manpage bits 2019-11-08T01:20:22Z yasuoka yasuoka@openbsd.org 2019-11-08T01:20:22Z urn:sha1:43056ea13708c559b500ff9106919e88bdb025fe ok jcs 2018-09-05T16:34:58Z jcs jcs@openbsd.org 2018-09-05T16:34:58Z urn:sha1:a152958512f308afc63273a2baac73e466ba2c39 2018-09-01T20:48:00Z jcs jcs@openbsd.org 2018-09-01T20:48:00Z urn:sha1:cecb02cd4eb9c092e59ac7b37bad207101e1a50f when looking for logical min/max of screen. ok kettenis 2018-08-25T20:31:31Z jcs jcs@openbsd.org 2018-08-25T20:31:31Z urn:sha1:737d705b8780db06a36e2cfc49360998fb7264ee Based on imt(4) Rename HIDMT_INPUT_MODE_MT to HIDMT_INPUT_MODE_MT_TOUCHPAD ok deraadt 2018-08-25T18:32:05Z jcs jcs@openbsd.org 2018-08-25T18:32:05Z urn:sha1:253b28d04b9c6635c4d2e127060005b0bf7c3471 into hidmt. The HID code uses hid_feature, hid_input, and hid_output constants to refer to report types internally that then need to be converted to their bus-level counterparts before actually getting sent out (so hid_feature becomes UHID_FEATURE_REPORT for USB, I2C_HID_REPORT_TYPE_FEATURE for i2c). This conversion was hard-coded in ihidev but ihidev_[gs]et_report should assume the type passed is already an i2c-level define, not a hid one. This is how uhidev does it. Add a conversion routine callback that any hidmt callers need to set so that hidmt can convert hid constants to the bus-level versions. Also add a similar conversion function to uhidev. ok deraadt 2018-07-30T15:56:30Z jcs jcs@openbsd.org 2018-07-30T15:56:30Z urn:sha1:57f285d3fef5a05fcb2a5f30803337c9a941be72 claiming to be elantech devices