Control: reassign -1 gnome-shell
Control: tags -1 + moreinfo
On Tue, 31 May 2022 at 20:02:39 +0200, Claudio wrote:
> My system does not react to Volume Up/Down/Mute events, but still
> reacts to Play/Pause/Previous/Next.
dbus is not responsible for generating events or reacting to events,
only delivering messages generated by something else, so this is very
unlikely to be a dbus bug. You implied that your UI is gnome-shell,
so I'm sending the bug report there for now, but I think it might be
working as designed.
> Trying to trace the event I checked GNOME keybindings; the UI recognizes
> the Audio Raise/Lower/Mute Volume inputs when binding the keys, but
> nothing happens when I try to use them
I believe the way volume keys are meant to work in GNOME is that
gnome-shell receives the keyboard events and uses them to control the
overall volume in PulseAudio (or Pipewire if you have pipewire-pulse
installed).
The reason MPRIS is necessary is that for events like play/pause, there
is no reasonable thing that gnome-shell can do on its own: the only thing
it can usefully do is pass the event on to your active media player,
and hope it can do something useful in response. That isn't the case for
volume control, which gnome-shell can deal with in an app-independent way:
regardless of whether you are playing music through a MPRIS media player,
playing sounds from a non-MPRIS source like a game, both, or neither,
the Shell changes the volume level directly, which will result in media
players, games, system sounds and all other sound sources getting louder
or quieter as appropriate.
So I think this is probably working as designed, unless the volume is
not actually changing (in which case that would be a problem with the
interaction between gnome-shell and pulseaudio).
> xev does not recognize any
> XF86Audio* events (volume or play/pause/etc.).
If you're using gnome-shell in its default Wayland mode, any key that is
grabbed by gnome-shell is not going to be visible to the X11 emulation
provided by Xwayland, and therefore not visible to xev. That's working
as designed. For applications, the result of pressing volume up/down keys
should be indistinguishable from the result of dragging the GUI volume
slider: either way, the representation is "volume changed".
smcv
