~mil/sxmo-tickets#519: 
mpris setup

Recently we had an user that tried to have a working mpris setup.

Mpris setup basically allow your bluetooth headset to control your audio application. The typical setup you need is

  • playerctld (daemons that track your clients)
  • clients (mpv-mpris, mpd-mpris, etc)

With those you can playerctl to list and manage your clients (play, pause, toggle, etc).

Then two possibilities :

  • By default some devices will be available to the sway compositor as typical device. By example here mine :
$ swaymsg -t get_inputs
…
Input device: JBL Charge 3 (AVRCP)
  Type: Keyboard
  Identifier: 87:35:JBL_Charge_3_(AVRCP)
  Product ID: 35
  Vendor ID: 87
  Active Keyboard Layout: English (US)
  Libinput Send Events: enabled
…

If this kind of AVRCP device is shown, then just need to configure the media keybinds :

# .config/sxmo/sway
…
bindsym XF86AudioPlay exec --no-startup-id playerctl play-pause 
bindsym XF86AudioStop exec --no-startup-id playerctl stop 
bindsym XF86AudioNext exec --no-startup-id playerctl next 
bindsym XF86AudioPrev exec --no-startup-id playerctl previous 
…

If your device isnt kind you have to disable wireplumber bluez5.dummy-avrcp-player.

doas mkdir -p /etc/wireplumber/bluetooth.lua.d/
doas cp /usr/share/wireplumber/bluetooth.lua.d/50-bluez-config.lua /etc/wireplumber/bluetooth.lua.d/50-bluez-config.lua
doas vim /etc/wireplumber/bluetooth.lua.d/50-bluez-config.lua

Uncommment and modify this line :

	["bluez5.dummy-avrcp-player"] = false,

Then you need to have the mpris-proxy daemon running. It would itself talk to your playerctl daemon and things should works.

Basically the sxmo question is :

Should we provide a default wireplumber setup that would handle the most common cases ? I think disabling this by default would suit the majority of users.

Status
REPORTED
Submitter
~stacyharper
Assigned to
No-one
Submitted
5 months ago
Updated
5 months ago
Labels
No labels applied.

~earboxer 5 months ago

Thanks so much for the info ~stacyharper; now at long last, the button on each of my headphones does what it's supposed to! (Can't wait to try it out in my car later today).

As a side note, you meant doas mkdir -p /etc/wireplumber/bluetooth.lua.d/ for the mkdir command.

What is playerctld? I think mpris is more of a protocol between controllers and players (not a server-client thing).

I think the majority of users would want the "pause" button on all their bluetooth devices and external headphones to "just work". (if their device has bluetooth and/or a headphone jack, that is). Big YES from me: SXMO should install and configure MPRIS-controlling interfaces.

(It should be up to the user to install MPRIS clients, which there are many).

(While it's true that using mpris is less simple in some ways, someone who wants could overwrite the sway config to call mpc/whatever, and write their own bluetooth whatever-proxy, and remove the mpris-proxy from the future-default start hook if they really wanted to avoid mpris)

We should also consider having a "currently playing" menu with the basic controls in it (like many desktop environments and phone UIs provide as persistent notifications).

One thing that I'll note is that the mpv-mpris client reports the ringtone as something that's being played (which of course, it is, as it's being played by mpv). It just looks funny on my PineTime (synced with itd) to see "ring.ogg" by TheZero in the media app.

~stacyharper 5 months ago*

As I think about, playerctd seems usefull mainly for the playerctl client. Which itself if necessary for accessing other players clients (from cmd lines or sway keybinds).

There is still things I dont fully understand yet. I now dont have my JBL input anymore and it continues to works as expected with my mpd client with or without this wireplumber line o_O

About making it a default I think we are moving away from the sxmo scope. Documenting this part would be way better if we finaly figure out what is going on ! :D

Register here or Log in to comment, or comment via email.