At Fri, 23 Nov 2007 19:36:32 +0100 (CET), Jaroslav Kysela wrote:
On Fri, 23 Nov 2007, Takashi Iwai wrote:
At Mon, 19 Nov 2007 12:13:28 +0100, I wrote:
If not, then it is better to remove it/remame to VolumeKnob
Agreed. I'd like to take a safer way if you don't insist...
Great, it is probably the best to have a virtual master volume. Just one question, it will be probably enabled for devices that don't have a master volume (or have it broken like the STAC), right?, And when you expect it to be merged?
Hopefully will be posted in this week after a small brush up.
OK, here is a series of the patch I promised.
The first one is the patch to add virtual master controls.
===
[PATCH] Add virtual master control
This patch adds the routines to create virtual master controls. A virtual master control can have multiple slave controls that are supposed to be identical type. The master volume will add the master attenuation and the master switch will add the master mute switch.
I'm really not sure if I like to see such extensions in kernel. We have now user control elements and a small daemon written in C or python will do exactly same job and will be more flexible.
I've thought that a user-space solution would be appropriate, too. But, a requirement of a daemon is a very big disadvantage (I believe many people would dislike). A plugin-based solution is another idea, but it's also complex and hard to implement consistently (because many mixer apps open "hw" device as default).
What I suggested is the implementation of a quite trivial master control. Of course, it's not so flexible but it covers most of hardwares. So much flexibility isn't needed in reality. The convenience (for user and developer) is more important.
Takashi