Prev: [PATCH tip/core/rcu 3/3] rcu: more fixes for accelerated GPs for last non-dynticked CPU
Next: time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
From: Henrique de Moraes Holschuh on 26 Feb 2010 20:00
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/