Re: [alsa-devel] [alsa-cvslog] alsa-kernel: Official ALSA project GIT repository for Linux 2.6 branch, master now at v2.6.31-rc8-407-gfc9e4a3
At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200 Commit: Clemens Ladisch clemens@ladisch.de CommitDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface. Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "amixer restore" that most distributions use; the renaming in this patch cures that regression by preventing amixer from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org>
Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it. I'm afraid that this patch might be regarded as another "regression".
For such an old driver, the compatibility is the most important item. If any, we must provide a way to back to the old behavior.
thanks,
Takashi
Diffstat: sound/pci/via82xx.c | 27 ++++++++++++++++++--------- 1 files changed, 18 insertions(+), 9 deletions(-)
Patch -------------- (max 1500 lines) diff --git a/sound/pci/via82xx.c b/sound/pci/via82xx.c index acfa476..91683a3 100644 --- a/sound/pci/via82xx.c +++ b/sound/pci/via82xx.c @@ -1626,7 +1626,7 @@ static int snd_via8233_dxs_volume_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct via82xx *chip = snd_kcontrol_chip(kcontrol);
- unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id);
unsigned int idx = kcontrol->id.subdevice;
ucontrol->value.integer.value[0] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][0]; ucontrol->value.integer.value[1] = VIA_DXS_MAX_VOLUME - chip->playback_volume[idx][1];
@@ -1646,7 +1646,7 @@ static int snd_via8233_dxs_volume_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct via82xx *chip = snd_kcontrol_chip(kcontrol);
- unsigned int idx = snd_ctl_get_ioff(kcontrol, &ucontrol->id);
- unsigned int idx = kcontrol->id.subdevice; unsigned long port = chip->port + 0x10 * idx; unsigned char val; int i, change = 0;
@@ -1705,11 +1705,12 @@ static struct snd_kcontrol_new snd_via8233_pcmdxs_volume_control __devinitdata = };
static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = {
- .name = "VIA DXS Playback Volume",
- .iface = SNDRV_CTL_ELEM_IFACE_MIXER,
- .iface = SNDRV_CTL_ELEM_IFACE_PCM,
- .device = 0,
- /* .subdevice set later */
- .name = "PCM Playback Volume", .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ),
- .count = 4, .info = snd_via8233_dxs_volume_info, .get = snd_via8233_dxs_volume_get, .put = snd_via8233_dxs_volume_put,
@@ -1936,10 +1937,18 @@ static int __devinit snd_via8233_init_misc(struct via82xx *chip) } else /* Using DXS when PCM emulation is enabled is really weird */ {
/* Standalone DXS controls */err = snd_ctl_add(chip->card, snd_ctl_new1(&snd_via8233_dxs_volume_control, chip));if (err < 0)return err;
for (i = 0; i < 4; ++i) {struct snd_kcontrol *kctl;kctl = snd_ctl_new1(&snd_via8233_dxs_volume_control, chip);if (!kctl)return -ENOMEM;kctl->id.subdevice = i;err = snd_ctl_add(chip->card, kctl);if (err < 0)return err;}------- End of patch
hooks/update
Git Source Code Management System hooks/update refs/heads/master \ 62f08ef9739c5cb5fff5b5bdec3bc02d522b9a12 \ fc9e4a3811567f8d1d4c263a89e27b52c90d6098
Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Alsa-cvslog mailing list Alsa-cvslog@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/alsa-cvslog
Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface.Well, this control was once removed, and then revived due to complains by users
one user
who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
Any application that looks for per-stream volume controls would find them only this way.
Since the assignment of applications to PCM substreams is more or less random, depending on how many other substreams are open, it does not make much sense to allow the user to access them by their number.
I'm afraid that this patch might be regarded as another "regression". For such an old driver, the compatibility is the most important item.
Honza, are you still using this driver?
Best regards, Clemens
At Tue, 06 Oct 2009 09:41:32 +0200, Clemens Ladisch wrote:
Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface.Well, this control was once removed, and then revived due to complains by users
one user
More. I've seen in other MLs and got personal mails, too. Just handful, though :)
who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
Any application that looks for per-stream volume controls would find them only this way.
Since the assignment of applications to PCM substreams is more or less random, depending on how many other substreams are open, it does not make much sense to allow the user to access them by their number.
This is correct. But you can't expect how users use it. Changing any existing behavior is regarded always as a regression, no matter whether it's the correct move or not. It's so especially with the old stuff.
I don't care about this so much and will likely cherry-pick your commit. Certainly it's a good fix for long term. But, we should keep it in mind that even this can be seen as a regression for some people, and we must be really carefully to judge before changing such a really old stuff.
thanks,
Takashi
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, as long as there is no application to handle PCM-interface controls, the DXS controls should not be hidden this way.
Anyway, the volume level regression can be solved by any renaming, so let's do just that. Takashi, please pick the patch below instead.
==========
sound: via82xx: rename DXS volume controls
Only some insiders know what the "VIA DXS" controls actually control, so change them to a more descriptive name.
Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "alsactl restore" that most distributions use; the renaming in this patch cures that regression by preventing alsactl from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613
Signed-off-by: Clemens Ladisch clemens@ladisch.de Cc: stable@kernel.org
--- a/sound/pci/via82xx.c +++ b/sound/pci/via82xx.c @@ -1705,7 +1705,7 @@ };
static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = { - .name = "VIA DXS Playback Volume", + .name = "PCM Stream Playback Volume", .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ),
At Thu, 08 Oct 2009 13:19:07 +0200, Clemens Ladisch wrote:
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, as long as there is no application to handle PCM-interface controls, the DXS controls should not be hidden this way.
Anyway, the volume level regression can be solved by any renaming, so let's do just that. Takashi, please pick the patch below instead.
Too late. I already picked up the older patch.
Takashi
==========
sound: via82xx: rename DXS volume controls
Only some insiders know what the "VIA DXS" controls actually control, so change them to a more descriptive name.
Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "alsactl restore" that most distributions use; the renaming in this patch cures that regression by preventing alsactl from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613
Signed-off-by: Clemens Ladisch clemens@ladisch.de Cc: stable@kernel.org
--- a/sound/pci/via82xx.c +++ b/sound/pci/via82xx.c @@ -1705,7 +1705,7 @@ };
static struct snd_kcontrol_new snd_via8233_dxs_volume_control __devinitdata = {
- .name = "VIA DXS Playback Volume",
- .name = "PCM Stream Playback Volume", .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE | SNDRV_CTL_ELEM_ACCESS_TLV_READ),
Takashi Iwai wrote:
Clemens Ladisch wrote:
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, as long as there is no application to handle PCM-interface controls, the DXS controls should not be hidden this way.
Anyway, the volume level regression can be solved by any renaming, so let's do just that. Takashi, please pick the patch below instead.
Too late. I already picked up the older patch.
Okay, I'll see if I can extend alsamixer ...
Clemens
At Thu, 08 Oct 2009 14:37:54 +0200, Clemens Ladisch wrote:
Takashi Iwai wrote:
Clemens Ladisch wrote:
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, as long as there is no application to handle PCM-interface controls, the DXS controls should not be hidden this way.
Anyway, the volume level regression can be solved by any renaming, so let's do just that. Takashi, please pick the patch below instead.
Too late. I already picked up the older patch.
Okay, I'll see if I can extend alsamixer ...
That'd be nice.
thanks,
Takashi
I wrote:
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, I'll see if I can extend alsamixer ...
Well, those controls are quite hardware-specific, and I always wanted to try out the Python wrappers, so I wrote a separate application.
Honza, if you have a new kernel and the latest released alsa-lib and alsa-python packages, please try downloading the latest alsa-tools snapshot from http://www.alsa-project.org/snapshot/ and check the hwmixvolume tool.
Regards, Clemens
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, I'll see if I can extend alsamixer ...
you can try iface_pcm_v2.c in https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1835
I only tested it with the patched au88x0 driver
2010/2/24 Clemens Ladisch clemens@ladisch.de
I wrote:
jmal8295 wrote:
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently.
Okay, I'll see if I can extend alsamixer ...
Well, those controls are quite hardware-specific, and I always wanted to try out the Python wrappers, so I wrote a separate application.
Honza, if you have a new kernel and the latest released alsa-lib and alsa-python packages, please try downloading the latest alsa-tools snapshot from http://www.alsa-project.org/snapshot/ and check the hwmixvolume tool.
Regards, Clemens
The characteristic of the VXS Volume controls are changed after the type of the controls are changed from IFACE_MIXER to IFACE_PCM
extend alsamixer seem break the definition of those IFACE_PCM PCM Playback Volume control since the driver should reset IFACE_PCM PCM playback volume to 0dB whenever the subdevice is opened since most of the alsa applications don't check whether the sound card support hardware mixing
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface.
By "moving" you mean removing them or will there appear somewhere else?
Well, this control was once removed, and then revived due to complains by users
one user
who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
Any application that looks for per-stream volume controls would find them only this way.
Since the assignment of applications to PCM substreams is more or less random, depending on how many other substreams are open, it does not make much sense to allow the user to access them by their number.
I'm afraid that this patch might be regarded as another "regression". For such an old driver, the compatibility is the most important item.
Honza, are you still using this driver?
Yes I do (there is a different driver for this codec?). And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently. On the other hand, I do change the volume only manually (not automatically by program), so if only thing which changes is the way how to modify that volume I would not see problem in that. Honza
Best regards, Clemens
jmal8295 wrote:
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=fc9e4a3811567f...
Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface.By "moving" you mean removing them or will there appear somewhere else?
Changing the interface from MIXER to PCM means that the controls will not appear in most mixer applications.
Honza, are you still using this driver?
Yes I do (there is a different driver for this codec?).
No, it's just rather old. I hoped you'd be using newer hardware by now. ;-)
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently. On the other hand, I do change the volume only manually (not automatically by program), so if only thing which changes is the way how to modify that volume I would not see problem in that.
With the new controls, the only way to change them would be on the command line: amixer cset iface=PCM,name="PCM Playback Volume",subdevice=x yy
BTW: How do you determine which of the four controls is associated with a specific application?
In any case, the main purpose of the patch was to rename the controls to prevent "alsactl restore" from restoring the old wrong volume setting, so it would suffice to just change the controls' name in some way, such as from "VIA DXS" to "DXS".
Best regards, Clemens
jmal8295 wrote:
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098
http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=fc9e4a3811567f...
Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface.By "moving" you mean removing them or will there appear somewhere else?
Changing the interface from MIXER to PCM means that the controls will not appear in most mixer applications.
Honza, are you still using this driver?
Yes I do (there is a different driver for this codec?).
No, it's just rather old. I hoped you'd be using newer hardware by now. ;-)
Its true I plan to buy new computer soon, but I will be still using this one.
And I _will_ be regarding it as regression if I lose possibility to change volume of the four streams independently. On the other hand, I do change the volume only manually (not automatically by program), so if only thing which changes is the way how to modify that volume I would not see problem in that.
With the new controls, the only way to change them would be on the command line: amixer cset iface=PCM,name="PCM Playback Volume",subdevice=x yy
Hmmm ... that is almost as cumbersome as it could be. Is it at least planed to add it to some other mixer, like alsamixer? Another view perhaps?
Still better that removing them.
BTW: How do you determine which of the four controls is associated with a specific application?
Trial and error :-). Usually I know what started first and if I get it wrong, I'll try another one. I don't suppose any change could help me with it. I mean, only syntax which I imagine would help is amixer cset iface=PCM,name="PCM Playback Volume",subdevice=pid:17345 but don't suppose someone will be adding code for examining pid 17345's descriptors in that case to amixer, much less alsamixer.
In any case, the main purpose of the patch was to rename the controls to prevent "alsactl restore" from restoring the old wrong volume setting, so it would suffice to just change the controls' name in some way, such as from "VIA DXS" to "DXS".
I would propose to use this oportunity to rename them to something more descriptive, but I have no idea what that could be (considering limited space in mixer programs). Honza
Best regards, Clemens
jmal8295 wrote:
With the new controls, the only way to change them would be on the command line: amixer cset iface=PCM,name="PCM Playback Volume",subdevice=x yy
Hmmm ... that is almost as cumbersome as it could be. Is it at least planed to add it to some other mixer, like alsamixer? Another view perhaps?
That would be useful (also for the same controls of the Emu10k1 and DS-1 drivers).
BTW: How do you determine which of the four controls is associated with a specific application?
Trial and error :-).
A mixer application/view that knows about these controls could show the program name, but that would require that ALSA gives out information about the process that has opened a substream.
In any case, the main purpose of the patch was to rename the controls to prevent "alsactl restore" from restoring the old wrong volume setting, so it would suffice to just change the controls' name in some way, such as from "VIA DXS" to "DXS".
I would propose to use this oportunity to rename them to something more descriptive, but I have no idea what that could be (considering limited space in mixer programs).
"PCM Stream"?
Best regards, Clemens
On Tue, 6 Oct 2009, Takashi Iwai wrote:
At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200 Commit: Clemens Ladisch clemens@ladisch.de CommitDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface. Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "amixer restore" that most distributions
amixer restore == alsactl restore ?
use; the renaming in this patch cures that regression by preventing amixer from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org>Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
amixer utility should handle such controls without problems. We have similar volume controls in emu10k1 driver, but having 32 PCM volume controls in mixer is not much fun.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 6 Oct 2009, Takashi Iwai wrote:
noreply-git@alsa-project.org wrote:
Author: Clemens Ladisch clemens@ladisch.de sound: via82xx: move DXS volume controls to PCM interface
Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "amixer restore" that most distributionsamixer restore == alsactl restore ?
Oops, yes.
Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
amixer utility should handle such controls without problems.
Yes, it should. I haven't yet found where the hctl functions break it.
We have similar volume controls in emu10k1 driver, but having 32 PCM volume controls in mixer is not much fun.
It might make sense to show such controls only for opened PCM substreams, together with the process name.
Best regards, Clemens
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
almost the same thing, disabling an easy way to access it.
amixer utility should handle such controls without problems.
Yes, it should. I haven't yet found where the hctl functions break it.
It does not work with amixer? The interface type should be specified, but all controls should be visible through hctl interface. Something like:
amixer cset iface=PCM,name="some name",index=1 33
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Jaroslav Kysela wrote:
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
amixer utility should handle such controls without problems.
Yes, it should. I haven't yet found where the hctl functions break it.
It does not work with amixer? The interface type should be specified, but all controls should be visible through hctl interface. Something like:
amixer cset iface=PCM,name="some name",index=1 33
iface=PCM,name="PCM Playback Volume",subdevice=xxx always results in the control for subdevice 1.
Clemens
Tue, 6 Oct 2009, Clemens Ladisch wrote:
Jaroslav Kysela wrote:
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
amixer utility should handle such controls without problems.
Yes, it should. I haven't yet found where the hctl functions break it.
It does not work with amixer? The interface type should be specified, but all controls should be visible through hctl interface. Something like:
amixer cset iface=PCM,name="some name",index=1 33
iface=PCM,name="PCM Playback Volume",subdevice=xxx always results in the control for subdevice 1.
Oops. The snd_hctl_compare_default() routine is broken for iface != MIXER. The device and subdevice values should be compared as well to get correct result in _snd_hctl_find_elem(). I'll prepare a fix ASAP.
Thanks for info, Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
Tue, 6 Oct 2009, Jaroslav Kysela wrote:
Tue, 6 Oct 2009, Clemens Ladisch wrote:
Jaroslav Kysela wrote:
On Tue, 6 Oct 2009, Clemens Ladisch wrote:
amixer utility should handle such controls without problems.
Yes, it should. I haven't yet found where the hctl functions break it.
It does not work with amixer? The interface type should be specified, but all controls should be visible through hctl interface. Something like:
amixer cset iface=PCM,name="some name",index=1 33
iface=PCM,name="PCM Playback Volume",subdevice=xxx always results in the control for subdevice 1.
Oops. The snd_hctl_compare_default() routine is broken for iface != MIXER. The device and subdevice values should be compared as well to get correct result in _snd_hctl_find_elem(). I'll prepare a fix ASAP.
The fix in in alsa-lib GIT tree now.
http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=0110d62043589f0e3...
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Tue, 6 Oct 2009 09:42:40 +0200 (CEST), Jaroslav Kysela wrote:
On Tue, 6 Oct 2009, Takashi Iwai wrote:
At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git@alsa-project.org wrote:
commit fc9e4a3811567f8d1d4c263a89e27b52c90d6098 Author: Clemens Ladisch clemens@ladisch.de AuthorDate: Tue Oct 6 08:21:04 2009 +0200 Commit: Clemens Ladisch clemens@ladisch.de CommitDate: Tue Oct 6 08:21:04 2009 +0200
sound: via82xx: move DXS volume controls to PCM interface The "VIA DXS" controls are actually volume controls that apply to the four PCM substreams, so we better indicate this connection by moving the controls to the PCM interface. Commit b452e08e73c0e3dbb0be82130217be4b7084299e in 2.6.30 broke the restoring of these volumes by "amixer restore" that most distributionsamixer restore == alsactl restore ?
Yep.
use; the renaming in this patch cures that regression by preventing amixer from applying the old, wrong volume levels to the new controls. http://bugzilla.kernel.org/show_bug.cgi?id=14151 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532613 Signed-off-by: Clemens Ladisch <clemens@ladisch.de> Cc: <stable@kernel.org>Well, this control was once removed, and then revived due to complains by users who have used it in mixer. Moving this to PCM iface does almost the same thing, disabling an easy way to access it.
amixer utility should handle such controls without problems.
Yes, but amixer is no GUI used in "normal" desktop systems as an applet :)
We have similar volume controls in emu10k1 driver, but having 32 PCM volume controls in mixer is not much fun.
In that case, this was more demand than keeping the behavior. That is, much more people became happier by that. And, the driver wasn't that old.
What I'm claiming is to be conservative to change anything for old stuff. If we need to change the behavior of the old stuff, we should think twice.
thanks,
Takashi
Takashi Iwai wrote:
At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git@alsa-project.org wrote:
*Highly offtopic*
I've searched for this commit list on google but no hope. Can you please give a hint about how to subscribe to it?
At Tue, 06 Oct 2009 12:31:33 +0300, Ozan Çağlayan wrote:
Takashi Iwai wrote:
At Tue, 6 Oct 2009 08:36:04 +0200 (CEST), noreply-git@alsa-project.org wrote:
*Highly offtopic*
I've searched for this commit list on google but no hope. Can you please give a hint about how to subscribe to it?
It's alsa-cvslog ML. http://www.alsa-project.org/main/index.php/Mailing-lists
Takashi
participants (6)
-
Clemens Ladisch -
Jaroslav Kysela -
jmal8295 -
Ozan Çağlayan -
Raymond Yau -
Takashi Iwai