On Mon, Nov 26, 2012 at 12:21:03PM +0100, Alexandre Ratchov wrote:
> On Mon, Nov 26, 2012 at 11:55:15AM +0100, Matthieu Herrb wrote:
> > On Sun, Nov 25, 2012 at 08:17:06PM +0100, Alexandre Ratchov wrote:
> > > Currently audio hotkeys keys invoke the audio driver code to
> > > raise/lower the volume. The hot key is not consumed, and is send to
> > > X which generates XF86XK_Audio{Lower,Raise}Volume, which in turn
> > > are consumed by programs, which in turn change the volume a second
> > > time, and we end up with a messed volume. Furthermore hot keys are
> > > auto-repeated in X but on in the wskbd layer, which makes the
> > > volume changes even more confusing.
> > >
> > > IMO, we have to chose: either hot keys are consumed by the kernel
> > > to adjust the volume or they are passed to X.
> > >
> > > The diff below, is to make hot keys adjust the volume without
> > > propagating events to X.
> > >
> > > This can be tested on non-thinkpad and non-asus laptops. For
> > > instance start a video in mplayer and press the hot-keys; with this
> > > diff hot keys should adjust the hardware volume only instead of
> > > both the hardware volume and the mplayer softvol.
> >
> > That sounds generally sounds like a bad idea to me, altough I've no
> > idea how to solve that easily without a complex notification mechanism
> > and tons of policy... so it's probably ok for now.
>
> could you elaborate more; I'm not very aware of how X handles this;
> how are volume keys supposed to work to your opinion?
It's not specifically about X, and I'm not sure if generating X
keypress events is the best solution either.
I think it should behave like you describe it below, basically...
>
> >
> > will sio_onvol(3) be notified of changes done with the volume keys ?
>
> Not yet; the long term plan is make hotkeys (not necessarily the
> 174/176 keys which most keyboards lack) generate master volume MIDI
> events that sndiod could use (this way hotkeys work for the default
> device rather than the first one). This requires some thinking and
> I'm still not convinced it's the right thing to do.
yes, instead of handling the keys blindly inside the kernel, let them
generate some kind of event, that any daemon or application interested
in audio can receive and handle (or not). the "tons of policy" that
I'm referring to, is there to decide which of the event consumers will
actually change the volume, and may specify a fallback to in-kernel
processing if none is interested, or to generate keypress/release
events for X.
A sane default policy could of course be sending the events to
sndiod. But unless all ports doing audio are patched to use sndiod, we
should let some of them be able to get the events too.
Also some USB audio devices have volume control buttons that attach as
HID devices. Some attach as a HID keyboard and end up beeing handled
like the keyboard keys on the main keyboard, other attach as generic
HID and are thus left alone...
Now whith multiple devices, you may want to see the buttons on a USB
device control only the volume of that device too. That means that if
the devices attaches as HID keyboard, we should not allow it to attach
to the ws multiplexer, so that it's possible to match the input device
with the audio device... Again, policy...
--
Matthieu Herrb
