MediumRar
commented
11 months ago I am sorry for the weird formatting, I tried to use proper formatting for the codes and logs, but apparently I am too dumb :D
Closed MediumRar closed 10 months ago
MediumRar
commented
11 months ago I am sorry for the weird formatting, I tried to use proper formatting for the codes and logs, but apparently I am too dumb :D
kpcyrd
commented
10 months ago It's very likely related to your setup. :) The way Xorg works, keys are not "caught" by your window manager, they are broadcast events that applications can register listeners for. Spotify itself is setting up listeners for Play/Pause, Next, Previous and doesn't need further configuration. If you configure them in dwm this just means there are now two applications that are going to be notified for the key event (each application doing their own thing with the event).
spotify should usually "just work" and the keys work just fine for me on gnome 45. More relevant than your window manager is your display manager, the window manager is just positioning and decorating windows (and barely matters for the running application), but your display manager is setting up the environment all your applications run in. If you're currently using startx this is likely causing issues.
Since you're saying you're new to Arch Linux, I suggest this (this is also the configuration I use, but with i3 instead of dwm):
sudo pacman -S lightdm-gtk-greeter
sudo systemctl enable lightdm
reboot@kpcyrd You were absolutely right. It was an issue with my setup. To be more specific with my .xinitrc. In case someone runs into the same or a similar issue:
With Debian I had to add the following to my .xinitrc to get dbus to work properly:
exec dbus-launch --exit-with-session dwm
But according to the following Top-Answer this is not needed anymore with newer distros (Debian vs. Arch :D), since dbus will launch dbus via systemd: https://unix.stackexchange.com/questions/363910/dbus-launch-and-dbus-daemon-whats-happening
According to the man page this is actually quite a concern (as I have demonstrated) and provides a convenient way around that, by checking the content of the DBUS_SESSION_BUS_ADDRESS environment variable:
if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
https://man.archlinux.org/man/dbus-launch.1
I will just implement that in my .xinitrc to catch both cases :)
Thank you very much for your help !!!
Since switching from Debian to Arch I am having issues using the following media keys:
It basically results in Spotify-launcher crashing in such a manner, that I can only get it back to work by rebooting completely. When other programs are running while spotify is crashing, they will also crash (e.g. steam, firefox, but not St (simple terminal)). While I can start the other programs just fine, spotify-launcher needs a reboot of the machine. Just to clarify, no other programs crash when i press the media keys in and of itself, they just seem to get dragged down by spotify, while IT is crashing ...
I don't think it's related to my setup anymore (DWM catching keypress events -> calling custom script -> calling dbus), since I already tried removing those keybinds as well as replacing them. Replacing them with other keys, such as SUPER+F1 works as expected. Calling my custom script, as well as executing all three of its dbus commands works as expected:
Since even removing said key events from my WM resulted in the same crash I highly suspect Spotify itself is doing something with them. I don't know how or why though, since "pretty much the same setup" worked perfectly fine on Debian for me.
Following what happens in journalctl: