OpenBSD cvs log

created 2021-09-05T04:49:38Z
begin 2021-08-29T00:00:00Z
end 2021-08-30T00:00:00Z
path src/sys
commits 9

date 2021-08-29T11:23:29Z
author kettenis
files src/sys/arch/arm64/dev/aplns.c log diff annotate
src/sys/dev/ic/nvme.c log diff annotate
message Reduce the number of openings for aplns(4) to 1. This isn't correct but
make NVMe on the Apple M1 stable. Hopefully we can figure out the real
issue in the future.

ok jmatthew@

date 2021-08-29T12:02:52Z
author kettenis
files src/sys/dev/ic/nvmevar.h log diff annotate
message Reduce the number of openings for aplns(4) to 1. This isn't correct but
make NVMe on the Apple M1 stable. Hopefully we can figure out the real
issue in the future.

ok jmatthew@

date 2021-08-29T18:17:51Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message 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

date 2021-08-29T18:19:09Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message 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.

date 2021-08-29T18:20:18Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message 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.

date 2021-08-29T18:21:16Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message 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.

date 2021-08-29T18:31:08Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message correct range upper bound in comment

date 2021-08-29T19:00:59Z
author anton
files src/sys/dev/usb/ucc.c log diff annotate
message 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.

date 2021-08-29T20:31:18Z
author gnezdo
files src/sys/dev/pci/if_iwm.c log diff annotate
src/sys/dev/pci/if_iwx.c log diff annotate
message iwm/iwx: propagate errors out of iw{m,x}_set_bits_mask_prph routines

This might help with troubleshooting "iwx0: acquiring device failed"
errors.

OK stsp@