*ping* In case stable self-hosted distfile is preferred, I uploaded the tarball to:
MASTER_SITES = https://thfr.info/distfiles/ DISTNAME = libhidapi-0.8.0.20160128 (of course, EXTRACT_SUFX = .tar.gz) On Sat, May 05, 2018 at 11:59:58AM -0700, Thomas Frohwein wrote: > Hi, > > Please find attached this port of libhidapi, a library for communicating with > HID devices via USB (or Bluetooth). It is a dependency of 2 upcoming ports > from > me (openhmd and dolphin). > > A few comments: > > - Upstream stopped making releases in 2013 and there hasn't been any activity > as of late. Last release tag was 0.8.0-rc1. I set version number to > 0.8.0.20160128 (the last number being the date of most recent commit) in > order to avoid EPOCH if there's ever going to be another release. Is this > ok? > - The API contains hid_init which is the same name as a function in usbhid(3). > To avoid risk of collision, I patched this port to hidapi_hid_init instead. > - There is a testgui - adds the dependency devel/fox and is buggy/segfaults. I > don't see a great justification to install this, therefore disabled it. > - In order to work, the HID devices need to attach as ugen, _not_ uhid/uhidev. > This is similar to the situation with ulpt and cups (cups uses libusb1 as > does libhidapi). At the moment this can be done by disabling uhid and uhidev > in 'boot -c' (don't do that if you require USB mouse/keyboard). The way > forward to avoid disabling all uhid would be either quirks entries for each > affected device, or disabling uhid as needed with mpi@ recent patch from > tech@: > > https://marc.info/?l=openbsd-tech&m=152457124405318&w=2 > > - This has been tested with several HMDs via upcoming openhmd port (Oculus > Rift > DK1, OSVR HDK2, Dell Visor) and works. Upcoming dolphin uses hidapi for > controller support for e.g. the Wii controller which I don't own, and it > likely uses Bluetooth.
