include sys/device.h, on some architectures this gets pulled in, but others
(like sparc64) require it explicitly

Make ucc(4) the first consumer of hidcc. No intended functional change.

ok matthieu@

Revert previous commit as the bounds check was correct.

Fix bounds check in ucc_add_key(); ok anton@

Disable the recently introduced logic used to associate ucc and audio
devices. Caspar Schutijser reported on bugs@ that pressing the volume
keys on his headset causes a usb host controller interrupt

Disable the recently introduced logic used to associate ucc and audio
devices. Caspar Schutijser reported on bugs@ that pressing the volume
keys on his headset causes a usb host controller interrupt storm. I'm
trying to figure out what's going on but since we're approaching release
keep it disabled.

show more ...

also use the device name in ucc_intr() debug output

use the device name in debug output

Currently, wskbd_set_mixervolume() only adjusts the volume of the first
attached audio device, i.e. audio0. This approach does not work well
while using additional audio devices equipped with physica

Currently, wskbd_set_mixervolume() only adjusts the volume of the first
attached audio device, i.e. audio0. This approach does not work well
while using additional audio devices equipped with physical volume keys
since those would only affect the volume of audio0.

Instead, correlate audio and ucc devices attached over USB in order to
adjust the volume of the correct audio device. This is done by passing a
cookie from the common point of attachment which is later used to
correlate the audio and wskbd device.

The same approach could be adopted for audio and wskbd devices attaching
on a different bus. Keep in mind that it's of importance to make use of
and increment the same global cookie identifier to avoid collisions.

Makes the volume keys on my Logitech G435 Headset do the right thing.

ok ratchov@

show more ...

spelling
feedback and ok tb@ jmc@ ok ratchov@

ucc does not claim multiple report ids

Changing the encoding of a ucc keyboard doesn't make sense as only one
encoding is supported. Instead, silently ignore such requests. Gets rid
of the following warning emitted by kbd(8) while booting

Changing the encoding of a ucc keyboard doesn't make sense as only one
encoding is supported. Instead, silently ignore such requests. Gets rid
of the following warning emitted by kbd(8) while booting with a ucc
keyboard attached and /etc/kbdtype being present:

kbd: unsupported encoding uk on /dev/wskbd2

I ended up repurposing KB_MACHDEP as is became unused back in 2008. Note
that running a kernel with this commit applied requires kbd and
wsconsctl to be recompiled in order to show correct encodings.

Problem reported by landry@ and ok deraadt@

show more ...

Revert recent uhidev report size changes. It's reported to break fido devices
for as of now unknown reasons.

Instead of letting uhidev drivers get the report sizes, do it once in
uhidev and pass the same sizes as part of the attach arguments. Makes
the uhidev drivers a bit less repetitive.

It might look te

Instead of letting uhidev drivers get the report sizes, do it once in
uhidev and pass the same sizes as part of the attach arguments. Makes
the uhidev drivers a bit less repetitive.

It might look tempting to let uhidev assign the sizes after a driver has
attached, removing the need to repeat this logic in each driver. This
does however not work since the input size must be known while calling
uhidev_open() in order to open the interrupt pipe; and uhidev_open() is
called from several attach routines.

Note that this change only works and applies to when attaching to a
single report ID.

ok jcs@

show more ...

Explain in a comment why two wscons_keydesc structures are needed.

Add support for the more rare volume usage which differs compared to the
more common volume increment/decrement usages in which each volume
change direction is represented using a distinct usage. The

Add support for the more rare volume usage which differs compared to the
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.

show more ...

Rename ucc_bits_to_usage() to ucc_bits_to_int() as it's about to be used
in more than one context.

In enumerating mode, calculate the bit offset using the HID input
location as the product of the corresponding Report Count and Report
Size can be greater than one.

Fixes Richard Toohey's <richardjt

In enumerating mode, calculate the bit offset using the HID input
location as the product of the corresponding Report Count and Report
Size can be greater than one.

Fixes Richard Toohey's <richardjtoohey at gmail dot com> Dell keyboard.

show more ...

Protect against missing bit to key symbols in ucc_bit_to_sym(). This can
only happen if ucc_hid_parse() has a bug, better play it safe.

Pass volume related key presses as both raw and translating input to
wskbd in order to make them visible in X11. Matches what ukbd(4) already
does.

correct range upper bound in comment

Make the ucc match criteria more stringent by requiring at least one
usage greater than zero. Usage zero is defined as unassigned by the
specification and cannot be mapped to anything sensible.

Prev

Make the ucc match criteria more stringent by requiring at least one
usage greater than zero. Usage zero is defined as unassigned by the
specification and cannot be mapped to anything sensible.

Prevents ucc from attaching to bunch of odd report IDs from a Lenovo
ThinkPad USB-C Dock which only exposes the unassigned usage. This is
not a problem in practice but I think we're better attaching them as
uhid devices instead as ucc cannot provide any functionality.

Thanks to Mario Peter <mp at mpeter dot de> for reporting and testing.

show more ...

Some reports embeds multiple report IDs inside the same collection
causing ucc to only being able to attach to the last report ID. This in
turn is caused by hid_is_collection() only being able to obs

Some reports embeds multiple report IDs inside the same collection
causing ucc to only being able to attach to the last report ID. This in
turn is caused by hid_is_collection() only being able to observe an end
of collection item with the last report ID for the same collection.

Instead, change the matching of ucc to only consider report IDs with at
least one corresponding Consumer Control usage.

Fixes gnezdo@'s Google Pixel earbuds.

show more ...

An interrupt report contains the state of all items (Input, Output and
Feature) from the corresponding descriptor report for a given report ID.
The ordering of the items is identical in both the desc

An interrupt report contains the state of all items (Input, Output and
Feature) from the corresponding descriptor report for a given report ID.
The ordering of the items is identical in both the descriptor and
interrupt report. As the interrupt report can cover more than Consumer
Control related key presses, ucc must be more careful while examining
the interrupt report in order to not confuse other items as key presses.

While parsing the descriptor report, take note of the bits that
represents Consumer Control key presses and use it to slice the
interrupt report.

Thanks to florian@ gnezdo@ and Alessandro De Laurenzis <just22 at
atlantide dot mooo dot com> for testing.

show more ...

As the Consumer Control usages are well defined by the HID Usage Tables
specification ucc might as well enumerate all of them. Finding an
appropriate scan code recognized by X11 for each usage is mor

As the Consumer Control usages are well defined by the HID Usage Tables
specification ucc might as well enumerate all of them. Finding an
appropriate scan code recognized by X11 for each usage is more tricky.
I've added a few more but the majority are still unmapped. Linux has
defined a couple of more usages covered by the evdev[1] key codes but
those symbols are not picked up in an vanilla X11 configuration on
OpenBSD, according to setxkbmap(1).

This should at least lower the barrier for adding scan codes for wanted
keys.

Note that the strings are discarded unless UCC_DEBUG is enabled.

Thanks to gnezdo@ for testing.

[1] xenocara/dist/xkeyboard-config/keycodes/evdev

show more ...

Rename ucc_intr_to_usage() to ucc_bits_to_usage(), no functional change.