Need help: control master volume

[Lubos Lunak]

Dne so 13. března 2004 10:07 Mirko Boehm napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 13 March 2004 05:36 am, Lubos Lunak wrote:
> ...
>
> > > What's really needed is a nice interface between kmilo and khotkeys so
> > > you can customise any button to do whatever you want.
> >
> >  I thought we already agreed
> > (http://lists.kde.org/?t=107550649700014&r=1&w=2) that KMilo should
> > simply translate those hardware-specific keys that aren't visible as
> > normal X key events to normal X key events, so that people can bind them
> > to whatever they want, be it KMix, KMixApplet, KHotKeys or MyFoo. Is
> > there a problem with that?
>
> While this solution sounds good, it might not make sense in all cases. For
> example, there is only a volume button and a mute button here, and the
> desktop is supposed to open a window to control the volume and muting. And
> this application needs to be able to control the hardware mixer.

 I'm confused. What window? If KMilo converts the hardware keys to 
XF86VolumeUp etc., with keys configured to react on those keys (which KMix 
should have preconfigured) KMix will adjust the volume and give feedback. 
Exactly like if the user simply pressed the multimedia volume up key on 
normal multimedia keyboard, where Qt/X/kernel can recognize the keys 
directly. Where exactly should be the problem?

>
> Therefore, I would, for example, very much appreciate to see a kded
> interface to the hardware mixer(s) that is callable by kmix, khotkeys,

 KMix can already control volume on its own (it'd be bad if it couldn't ;)  ), 
KHotKeys doesn't need it, and with keys translation KMilo wouldn't either.

> kmilo-modules etc. A nice enumeration of devices and in and out channels
> and very few call with normalized parameters (retrieve/set float
> volume=[0..1] for device x, channel y) should do all tricks. Then it would
> also not matter anymore if the user starts the kmix_applet and kmix at the
> same time, and maybe even if he uses alsamixer on the console, we would be
> able to react on it. This is clearly distinctive from any sound server, and
> definitly a central piece, much more than the mixer application.
> This is why I posted this on core-devel, I think it is not a pure
> multimedia issue, but should be implemented for the whole desktop.
>
> Of course I understand that this is not a high priority issue, but maybe it
> could be tackled with KDE 4. For now, I will go with the proposed
> approaches (khotkeys and dcop-->kmix).

 The proposal from me includes neither khotkeys nor dcop-->kmix. KMilo 
converts the hardware-specific keyboard event to normal X keyboard event. 
KMix (or whatever the user runs and has configured to react on the multimedia 
keys) reacts on this keyboard event, without even knowing it comes from 
KMilo.

 Simple as that. Since I don't use or know KMilo much, in case I'm missing 
something important, please enlighten me.

-- 
 Lubos Lunak
 KDE Developer