On Sun, Jul 14, 2024 at 08:03:22AM +0200, Anton Lindqvist wrote:
> On Fri, Jul 12, 2024 at 08:20:26PM -0600, Mark Hesselink wrote:
> > Hi,
> > 
> > jca suggested I sent the below email to tech@ instead of misc@ with ratchov@ on Cc.
> > 
> > ---
> > 
> > I recently bought a JBL USB-C wired headphones for my 2020 Apple MacBook Air to enjoy audio without disturbing my family. The headphones is exposed via uaudio(4) as audio1 to the system. The headphones come with a simple consumer control keyboard supported by ucc(4) and wskbd(4). The keyboard exposes 2 volume control keys and an unmapped key. The relevant dmesg(8) lines are:
> > 
> > uaudio0 at uhub1 port 1 configuration 1 interface 1 "KTMICRO JBL TUNE 310C USB-C" rev 2.00/0.03 addr 2
> > uaudio0: class v1, full-speed, sync, channels: 2 play, 1 rec, 5 ctls
> > audio1 at uaudio0
> > uhidev0 at uhub1 port 1 configuration 1 interface 3 "KTMICRO JBL TUNE 310C USB-C" rev 2.00/0.03 addr 2
> > uhidev0: iclass 3/0, 84 report ids
> > ucc0 at uhidev0 reportid 1: 4 usages, 3 keys, enum
> > wskbd1 at ucc0 mux 1
> > wskbd1: connecting to wsdisplay0
> > uhid0 at uhidev0 reportid 75: input=10, output=10, feature=0
> > uhid1 at uhidev0 reportid 84: input=10, output=10, feature=0
> > 
> > The volume control keys unfortunately can only control audio0 in an OpenBSD 7.5-stable system as sys/dev/hid/hidcc.c does not currently pass the audio cookie it receives from ucc(4) on to wskbd(4). The attached hidcc_c.patch is a (simple) attempt at fixing this issue. It allows me to control the volume on my headphones using the consumer control keyboard, a good quality of life improvement.
> 
> I disabled ucc audio support after caspar@ reported an interrupt storm
> after pressing the volume keys on some headset. I was never able to
> reproduce the problem with my hardware and I don't think caspar@ managed
> to root cause it either.
> 

Any reference to the discussion?