On Mon, Feb 07, 2022 at 11:43:43AM +0100, Alexandre Ratchov wrote: > On Sat, Feb 05, 2022 at 06:30:43PM +0100, Claudio Jeker wrote: > > On Sat, Feb 05, 2022 at 12:28:08PM +0100, Mark Kettenis wrote: > > > > Date: Sat, 5 Feb 2022 09:29:42 +0100 > > > > From: Anton Lindqvist <[email protected]> > > > > > > > > Hi, > > > > I recently got a USB headset with physical volume buttons, handled by > > > > ucc(4). However, after enabling the device in sndiod the volume buttons > > > > does not cause the volume to change. Turns out wskbd_set_mixervolume() > > > > is only propagating volume changes to first attached audio device. Is > > > > their any good not to consider all attached audio devices? > > > > > > I think this is tricky. The mixer values of different audio devices > > > may start out differently and may have different granularity and > > > probably operate on a different scale. This may lead to situations > > > where as you turn the volume up and down, the relative output volume > > > between devices changes considerably. I also think that your > > > implementation will unmute all audio devices as soon as you touch the > > > volume control buttons, which is probably not desirable. > > > > > > Thinking about other ways to do this, we could: > > > > > > - Add a knob that allows the user to control which audio device is > > > controlled by the volume control buttons. The choice could include > > > "none" and "all" as well as the individual devices. > > > > > > - Add infrastructure to bind specific keyboards to specific audio > > > devices, a bit like how we support binding specific wskbd devices to > > > specific wsdisplay devices. > > > > > > The first suggestion is probably relatively easy to achieve. The > > > implementation of the latter would defenitely need more thought and > > > discussion. > > > > > > The "none" choice above would (partly) solve another issue where > > > userland applications see the key presses and act upon them even > > > though the kernel already did the volume adjustment. > > > > There is a 3rd option of passing the information to sndiod and let it do > > the volume scaling. > > > > Here's a small WIP program to do so. It also adds a key to cycle > through audio devices. > > https://github.com/ratchov/sndiokeys > > By default it uses Ctrl+Alt+{plus,minus,0} because multimedia keys are > already used. > > Anton, I've no headphones with buttons to test, does this work for > yours?
Interesting! I cannot get to run under X, it fails in XGetKeyboardMapping: (gdb) r Starting program: /tmp/sndiokeys/sndiokeys X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 33 (X_GrabKey) Serial number of failed request: 12 Current serial number in output stream: 76 Breakpoint 1, _libc_exit (status=1) at /home/src2/lib/libc/stdlib/exit.c:54 54 /home/src2/lib/libc/stdlib/exit.c: No such file or directory. (gdb) bt #0 _libc_exit (status=1) at /home/src2/lib/libc/stdlib/exit.c:54 #1 0x00000cfba76512b1 in _XDefaultError () from /usr/X11R6/lib/libX11.so.17.1 #2 0x00000cfba76514a9 in _XError () from /usr/X11R6/lib/libX11.so.17.1 #3 0x00000cfba764d47a in handle_response () from /usr/X11R6/lib/libX11.so.17.1 #4 0x00000cfba764dd50 in _XReply () from /usr/X11R6/lib/libX11.so.17.1 #5 0x00000cfba762d8ba in XGetKeyboardMapping () from /usr/X11R6/lib/libX11.so.17.1 #6 0x00000cf94a4778f7 in grab_keys () at sndiokeys.c:318 #7 0x00000cf94a477279 in main (argc=0, argv=0x7f7ffffdd760) at sndiokeys.c:529
