27;ve no other options, have we?
> > > >
> > > > AFAICS, you're fixing a concrete use-case by tweaking what already
> > > > exists, this won't make things more broken than they already are. I'm
> > > > OK with it.
> > >
> > &g
t; > >
> > > AFAICS, you're fixing a concrete use-case by tweaking what already
> > > exists, this won't make things more broken than they already are. I'm
> > > OK with it.
> >
> > Here's the complete diff including adding
OK with it.
>
> Here's the complete diff including adding a cookie argument to
> audio_attach_mi().
Is the caching necessary? device_lookup() seems cheap and there are at
most two devices in most cases. Keeping the code minimal especially on
rare and non-performace-critical code-paths would be nice.
If you choose to drop the caching, this would allow to just add a a
new "cookie" argument to wskbd_set_mixervolume(), similarly to what
you did for audio_attach_mi()
audio->cookie = NULL;
+ for (i = 0; i < audio_cd.cd_ndevs; i++) {
+ struct audio_softc *sc;
+
+ sc = (struct audio_softc *)device_lookup(&audio_cd, i);
+ if (sc == NULL)
+ contin
On Mon, Feb 07, 2022 at 06:55:21PM +0100, Anton Lindqvist wrote:
> On Mon, Feb 07, 2022 at 11:21:43AM +0100, Alexandre Ratchov wrote:
> > On Sun, Feb 06, 2022 at 08:40:35AM +0100, Anton Lindqvist wrote:
> > >
> > > Polished diff. I'm omitting a necessary refactoring commit making
> > > audio_attac
er 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
on Lindqvist
> > > >
> > > > 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. T
On Mon, Feb 07, 2022 at 11:21:43AM +0100, Alexandre Ratchov wrote:
> On Sun, Feb 06, 2022 at 08:40:35AM +0100, Anton Lindqvist wrote:
> >
> > Polished diff. I'm omitting a necessary refactoring commit making
> > audio_attach_mi() accept a new cookie argument.
> >
>
> I'm not sure to understand t
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
udio_softc *)device_lookup(&audio_cd, i);
> + if (sc == NULL)
> + continue;
> + if (sc->cookie != cookie) {
> + device_unref(&sc->dev);
> + continue;
> +
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
On Sat, Feb 05, 2022 at 09:29:42AM +0100, Anton Lindqvist wrote:
> 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_mixerv
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 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.
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.
> Date: Sat, 5 Feb 2022 09:29:42 +0100
> From: Anton Lindqvist
>
> 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_s
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
17 matches
Mail list logo
