Comment 3 for bug 1219057

This is not fixed.
per ricmm:
what it means is that the shell needs to mediate the volume keys. the shell already listens to keys in a few places in Shell.qml, regardless of Mir, the interface is independent. Mir or SF routing of events happens at a lower layer. key events are delivered to the shell, the shell decides what to do in our case it is talk out to pulseaudio via some API
<ricmm> I guess dbus, or is it a native C api?
<diwic> ricmm, native C api. indicator-sound already uses it to set the volume
<diwic> ricmm, kernel -> mir -> indicator-sound -> pulseaudio
<diwic> ricmm, that's what I've been told.
<diwic> ricmm, feel free to revise
<ricmm> unity8 is Mir, and it receives key events directly
<ricmm> it just needs to route to the correct pulseaudio interface
<ricmm> Mir doesnt do any special event processing and direct dispatch (internally to mir) to pulseaudio, it just delivers to the shell (unity8)
<diwic> ricmm, it should route the events to the sound indicator?
<ricmm> yes
<diwic> ricmm, and the sound indicator already talks to pulseaudio the right way AFAIK
<ricmm> well then its just a matter of catching the KEY_EVENT in Shell.qml as it is done now for the power button
<ricmm> theres example code there
<ricmm> and signalling the indicator
<diwic> ricmm, okay, if you say so?
<ricmm> I do