On Mon, May 26, 2014 at 02:19:28PM +0200, Mark Kettenis wrote:
>
> But as I said before, the problem is that this breaks the visual
> feedback feature in desktop environments and applications like Gnome.
The diff is to make pckbd keys behave like all other volume keys
(thinkpad, asus, macppc). For gnome this means all buttons models
work the same way.
Anyway, to answer the gnome question (applies to any X program):
(1) either the program is reading the mixer control to produce the
visual feedback, in which case the diff doesn't break it.
(2) or the program uses volume keys as hot-keys, in which case
visual feedback is not properly working.
> We really need a discussion about the desired behaviour of the volume
> keys that involves porters as well as a broader range of users. It is
> impossible to judge diffs like this one without having a clear picture
> of the desired end result.
>
> That said, I think that:
>
> 1. We need a kernel interface for toggling between the volume keys
> only directly manipulating the mixer and having them only generate
> events. This doesn't necessarily have to be a user knob; it could
> be something that applications that want to see events and manage
> the sound volume themselve would flip.
I've included such a diff for completeness (see my "part 2"
e-mail), for those who want to experiment with the concept.
> 2. Mixer control needs to be integrated with sndio, such that
> applications that elect to receive events can act upon them by
> using a consistent API.
100% agree, we've a almost working diff for this. But once the
mixer is handled by sndio, we'll still need the pckbd fix discussed
here.
Without the fix volume keys would trigger two possibly inconsistent
actions. Example, the user presses press the "toggle mute" button,
the kernel/pckbd toggles the speakers mute control, then
gnome/kde/whatever sees the hot-key, toggles the mute control again
(through sndio), resulting in speakers not being muted.
-- Alexandre
