Hello Alexandre, Theo,
On 21/04/2020 - 00:12, Theo de Raadt wrote:
Alexandre Ratchov <a...@caoua.org> wrote:
On Tue, Apr 21, 2020 at 03:15:58AM +0200, Erling Westenvik wrote:
> > >
> > > I'm a bit confused now... so why the previous usbhidaction configuration
> > > (which was aligned to the manpage suggestions and worked flawlessly for
> > > years) doesn't work anymore?
> >
> > Sorry, few weeks ago mixerctl was changed to use /dev/audioctlN
> > instead of /dev/mixerN (which was just removed), but the
> > usbhidaction(1) man page was not updated. Now it's fixed.
> >
> > The sample invocation line should read:
> >
> > usbhidaction -f /dev/uhid1 -c conf /dev/audioctl0
> >
> > Tested on my setup, let me know if it works for you.
>
> I'm puzzled. This is -current as of yesterday (April 20th).
>
> From /etc/rc.conf.local:
> usbhidaction_flags=-f /dev/uhid0 -c /etc/usbhidaction.conf /dev/audioctl0
>
> My /etc/usbhidaction.conf:
> Consumer:Play/Pause 1
> echo 'cycle pause' | socat - /tmp/mpvsocket
> Consumer:Volume_Decrement 1
> sndioctl output.level=-0.1
> #mixerctl outputs.master=-8
> Consumer:Volume_Increment 1
> sndioctl output.level=+0.1
> #mixerctl outputs.master=+8
> Consumer:Mute 1
> sndioctl output.mute=!
> #mixerctl outputs.master.mute=toggle
>
> But alas, nothing happens when I press the respective buttons on my
> keyboard.
> Running from command line works, but not as root/doas..
>
> Running with doas: $ doas sndioctl output.level=+0.1
> default: can't open control device
>
> Running as myself: $ sndioctl output.level=+0.1
> output.level=0.6
>
Hi,
mixerctl is still the appropriate tool here, sndioctl is not inteded
to be run as root.
usbhidaction runs as root, given /dev/uhidN permissions, it's clearly
not intended to run "high level" user commands. For instance it makes
no sense to run "audiocious -u" when Pause/Play key is hit, it's the
similar for sndioctl. The mixerctl utility remains for such "low
level" use cases.
Since all audio control methods are now available inside sndioctl, I
have a hard time seeing why mixerctl has to remain.
Any program using sndiod is intended to be used one user at a time for
obvious privacy reasons, this is quickly explained in the last
section of sndio(7).
What are the chances that isn't the user on the USB bus?
Requiring people to use doas? Honestly, I find that offensive.
This is to confirm than changing the device to /dev/audioctl0,
usbhidaction performs the mixerctl commands correctly.
I cannot comment on implementation internals, but I tend to agree with
Theo's doubt: sndioctl seems the natural candidate to be the only tool
for audio control; mixerctl coexistence would be partially confusing
from an admin perspective. Just my opinion, of course.
All the best
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis
