Fix up the volume status setting functions to return a non-zero value if
the control value has changed, so that the ALSA framework can correctly
generate control change notifications.
Signed-off-by: Clemens Ladisch <[email protected]>
--- linux/drivers/platform/x86/thinkpad_acpi.c
+++ linux/drivers/platform/x86/thinkpad_acpi.c
@@ -6537,8 +6537,11 @@ static int volume_set_mute_ec(const bool
n = (mute) ? s | TP_EC_AUDIO_MUTESW_MSK :
s & ~TP_EC_AUDIO_MUTESW_MSK;
- if (n != s)
+ if (n != s) {
rc = volume_set_status_ec(n);
+ if (!rc)
+ rc = 1;
+ }
unlock:
mutex_unlock(&volume_mutex);
@@ -6569,8 +6572,11 @@ static int volume_set_volume_ec(const u8
n = (s & ~TP_EC_AUDIO_LVL_MSK) | vol;
- if (n != s)
+ if (n != s) {
rc = volume_set_status_ec(n);
+ if (!rc)
+ rc = 1;
+ }
unlock:
mutex_unlock(&volume_mutex);
On Mon, 22 Feb 2010, Clemens Ladisch wrote:
> Fix up the volume status setting functions to return a non-zero value if
> the control value has changed, so that the ALSA framework can correctly
> generate control change notifications.
Please explain...
>
> Signed-off-by: Clemens Ladisch <[email protected]>
>
> --- linux/drivers/platform/x86/thinkpad_acpi.c
> +++ linux/drivers/platform/x86/thinkpad_acpi.c
> @@ -6537,8 +6537,11 @@ static int volume_set_mute_ec(const bool
> n = (mute) ? s | TP_EC_AUDIO_MUTESW_MSK :
> s & ~TP_EC_AUDIO_MUTESW_MSK;
>
> - if (n != s)
> + if (n != s) {
> rc = volume_set_status_ec(n);
> + if (!rc)
> + rc = 1;
> + }
>
> unlock:
> mutex_unlock(&volume_mutex);
> @@ -6569,8 +6572,11 @@ static int volume_set_volume_ec(const u8
>
> n = (s & ~TP_EC_AUDIO_LVL_MSK) | vol;
>
> - if (n != s)
> + if (n != s) {
> rc = volume_set_status_ec(n);
> + if (!rc)
> + rc = 1;
> + }
>
> unlock:
> mutex_unlock(&volume_mutex);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Mon, 22 Feb 2010, Clemens Ladisch wrote:
> > Fix up the volume status setting functions to return a non-zero value if
> > the control value has changed, so that the ALSA framework can correctly
> > generate control change notifications.
>
> Please explain...
ALSA sends notifications to all mixer application when the value of
any mixer control has changed. To be able to avoid sending them for
controls that did not actually change, it uses the return value of the
.put callback: 0 means the control value did not change; 1 means it has
changed (or might have changed), and a notification is to be sent.
<http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch06s05.html#control-interface-callbacks-put>
Regards,
Clemens
On Tue, 23 Feb 2010, Clemens Ladisch wrote:
> Henrique de Moraes Holschuh wrote:
> > On Mon, 22 Feb 2010, Clemens Ladisch wrote:
> > > Fix up the volume status setting functions to return a non-zero value if
> > > the control value has changed, so that the ALSA framework can correctly
> > > generate control change notifications.
> >
> > Please explain...
>
> ALSA sends notifications to all mixer application when the value of
> any mixer control has changed. To be able to avoid sending them for
> controls that did not actually change, it uses the return value of the
> .put callback: 0 means the control value did not change; 1 means it has
> changed (or might have changed), and a notification is to be sent.
> <http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch06s05.html#control-interface-callbacks-put>
I am looking at it. I think I had it like that on purpose, to trigger an
OSD when a volume-related hotkey is pressed even if it doesn't change the
state (mute when already mute, vol down when already at minimum, etc).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Henrique de Moraes Holschuh wrote:
> On Tue, 23 Feb 2010, Clemens Ladisch wrote:
> > Henrique de Moraes Holschuh wrote:
> > > On Mon, 22 Feb 2010, Clemens Ladisch wrote:
> > > > Fix up the volume status setting functions to return a non-zero value if
> > > > the control value has changed, so that the ALSA framework can correctly
> > > > generate control change notifications.
> > >
> > > Please explain...
> >
> > ALSA sends notifications to all mixer application when the value of
> > any mixer control has changed. To be able to avoid sending them for
> > controls that did not actually change, it uses the return value of the
> > .put callback: 0 means the control value did not change; 1 means it has
> > changed (or might have changed), and a notification is to be sent.
> > <http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch06s05.html#control-interface-callbacks-put>
>
> I am looking at it. I think I had it like that on purpose, to trigger an
> OSD when a volume-related hotkey is pressed even if it doesn't change the
> state (mute when already mute, vol down when already at minimum, etc).
This is not about changes initiated by key presses but changes made
through the ALSA mixer API. Or does the hardware generate a hotkey
event when software changes the volume?
Regards,
Clemens
On Fri, 26 Feb 2010, Clemens Ladisch wrote:
> > > ALSA sends notifications to all mixer application when the value of
> > > any mixer control has changed. To be able to avoid sending them for
> > > controls that did not actually change, it uses the return value of the
> > > .put callback: 0 means the control value did not change; 1 means it has
> > > changed (or might have changed), and a notification is to be sent.
> > > <http://www.alsa-project.org/~tiwai/writing-an-alsa-driver/ch06s05.html#control-interface-callbacks-put>
> >
> > I am looking at it. I think I had it like that on purpose, to trigger an
> > OSD when a volume-related hotkey is pressed even if it doesn't change the
> > state (mute when already mute, vol down when already at minimum, etc).
>
> This is not about changes initiated by key presses but changes made
> through the ALSA mixer API. Or does the hardware generate a hotkey
> event when software changes the volume?
The firmware doesn't send events for software changes, mostly because it
does not want, or, expect any. These mixers are read-only by default.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh