Age | Commit message (Collapse) | Author |
|
reported by kirill@
|
|
|
|
This is for newer PowerBooks with ukbd(4), and doesn't affect older
models with akbd(4). The Fn key now makes a numpad,
7 8 9 0 - 7 8 9 / =
U I O P => 4 5 6 *
J K L ; 1 2 3 -
M . / 0 . +
Also, Fn+F6 is Num Lock. This acts like Num Lock on other USB
keyboards, and unlike Num Lock on akbd(4).
From jon (at) elytron (dot) openbsd (dot) amsterdam
|
|
ok mpi@
|
|
ok kettenis@
|
|
truncated report.
|
|
keyboards.
From jon (at) elytron (dot) openbsd (dot) amsterdam with some changes by me
ok gkoehler@
|
|
done by Vladimir Meshcheriakov (first name dot last name at epita somewhere in
frogland), thanks!
Tested by Peter J. Philipp on Intuos Draw and by espie@ on Intuos S.
|
|
feedback and ok miod@
|
|
(like sparc64) require it explicitly
|
|
|
|
ok anton@ patrick@
|
|
report since it unconditionally uses the size of the longest input
report. This is quite harmless and the defensive check in hidcc can
therefore be relaxed and instead only examining the number of expected
bytes.
ok matthieu@ patrick@
|
|
toward attaching hidcc over i2c.
ok matthieu@
|
|
ok kettenis@, miod@
|
|
If the HID descriptors don't provide a HUD_BUTTON_TYPE property, hidmt
should treat all devices as clickpads if they report a "clickpad button",
or don't report to have both a left and right external button.
|
|
to hidkbd so that it can be re-used by apldc(4) and aplhidev(4) as well
this also adds support for apple fn key combinations to aplhidev(4)
ok miod@
|
|
Thanks to Sven M. Hallberg.
|
|
now.
|
|
passes hid_none as the wanted hid kind to hid_start_parse(). This
becomes a problem for descriptors with multiple report IDs per
collection. Therefore change the semantics of the hid_none kind to let
it represents all possible kinds.
Gets rid of "uhidev_intr: bad repid" console spam as reported by sthen@
on bugs@.
Have been in snaps for a week.
|
|
feedback and ok tb@ jmc@ ok ratchov@
|
|
more common volume increment/decrement usages in which each volume
change direction is represented using a distinct usage. The volume usage
instead uses bits of the interrupt buffer to represent the wanted
volume. The same bits should be within the bounds given by the logical
min/max associated with the HID item. However, the volume is not
interpreted as an absolute value but rather just looking at the sign bit
in order to determine the volume change direction.
I couldn't find any documentation of this usage and the implementation is
therefore solely based on analysing actual data from Richard Toohey's
<richardjtoohey at gmail dot com> Dell keyboard.
|
|
|
|
include X and Y usages.
Some devices put the buttons on one report and X/Y on another, which
was causing us to ignore button data. This change will cause
attachment of two mouse devices in this case, but wsmux and X's
handling of input devices will make this transparent.
A future change should use [IU]HIDEV_CLAIM_MULTIPLE_REPORTID and
attach just one [iu]ms device that claims multiple reports and gets
X/Y and button data from whichever report it needs to. But the
future is not today.
ok gnezdo
|
|
quirks.
Original diff from Sven M. Hallberg < pesco () khjk ! org >
Diff updated and tested by Timo Myyra
ok phessler@
|
|
ok kn@
|
|
"button type" usages, so assume some reasonable defaults rather than
failing to attach.
Fixes two Dell Latitude laptops and tested in snaps for a bit.
|
|
too many PUSH. report from Andy Nguyen @ google.
fix by jcs
This is errata 6.6/030_hid and 6.7/008_hid
|
|
|
|
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@
|
|
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
|
|
ok jcs
|
|
|
|
when looking for logical min/max of screen.
ok kettenis
|
|
Based on imt(4)
Rename HIDMT_INPUT_MODE_MT to HIDMT_INPUT_MODE_MT_TOUCHPAD
ok deraadt
|
|
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
|
|
claiming to be elantech devices
|
|
tested by a few
|
|
|
|
with hidmt_input function
|
|
ok mpi@, jcs@
|
|
From Coverity via NetBSD via miod@
ok claudio@, tedu@, deraadt@, krw@
|
|
use it.
Instead of defering every input of a USB console keyboard to a timeout
via a queue of one element, only differ entering ddb(4) once a matching
control sequenece has been typed.
This prevent loosing inputs when a USB console keyboard is "too fast".
Fix a problem reported by matthieu@, Adam McDougall and Hrvoje Popovski.
ok stsp@, dlg@
|
|
|
|
By setting "machdep.forceukbd=1" you can now use your USB keyboard in
ddb(4) even if your BIOS emulates a pckbd(4).
ok tom@, kettenis@, deraadt@
|
|
|
|
ok kettenis@
|
|
This change adds new input-processing functions to wsmouse and
adapts the touchpad drivers.
ok mpi@, shadchin@
|
|
Needed by some touchscreens.
no objection matthieu@
|
|
to the "Windows Precision Touchpad" standard. when a compatible
device is found, hidmt claims all report ids and switches the device
into multitouch packet mode.
add imt, an i2c-HID driver that sits between ihidev and hidmt
|