Cyber Space


A banal geek, coder, cyber-space girl, linux user but cute person.

If you like my work, feel free buy me a coffee https://donate.missbanal.net/

she, her, hers

#519 mpris setup 21 hours ago

Comment by ~stacyharper on ~mil/sxmo-tickets

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

#520 Pinephone pulse audio configuration is not listing in audio menu 22 hours ago

Comment by ~stacyharper on ~mil/sxmo-tickets

Wait for alsa ucm conf to be fixed

#519 mpris setup a day ago

on ~mil/sxmo-tickets

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). EDIT: I guess I didn't know playerctld was a thing (just shows how easy it is to get this not configured exactly right, if there is a right way to do this).

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.

#519 mpris setup a day ago

Ticket created by ~stacyharper on ~mil/sxmo-tickets

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.

#502 "We failed to reset call audio" a day ago

Comment by ~stacyharper on ~mil/sxmo-tickets


#518 superd is being stopped when the phone is low in battery a day ago

Ticket created by ~stacyharper on ~mil/sxmo-tickets

It just being stopped by dunno who. It make sxmo completly unusable while in low battery (no gesture, bar, whatever)

#515 GPS 6 days ago

Comment by ~stacyharper on ~mil/sxmo-tickets

You may also need to edit the /etc/gpsd/device-hook script that was hanging the whole gpsd clients in my case

#515 GPS 6 days ago

Comment by ~stacyharper on ~mil/sxmo-tickets

You shouldnt need geoclue to have a fix. If you are using a modem device on pmos you should be able to load satelites data ootb. The command you should use through modem manager would looks like iirc

mmcli -m any --location-enable-gps-unmanaged

Also check other --location subcommands to see wich one you need.

Without satelites data having a fix can take 15 minutes while walking upside if you are very lucky.

#516 sxmo_hooksmenu.sh is broken 6 days ago

Comment by ~stacyharper on ~mil/sxmo-tickets

Inspect the PATH and you'll discover that your ~/.config/sxmo/hooks/sxmo_hook_inputhandler.sh will never be used if there is a /usr/share/sxmo/default_hooks/pine64,pinephone-1.2/sxmo_hook_inputhandler.sh

Plus you can totally have dotfiles that fits for multiple devices. And you can totally write your own "device" specific hooks for one or another device.

So yes, this hook script must handle the devices subfolder. A return I already gave before last patchs arround this menu.

#512 [SWMO] Foot Allowing Touch to highlight 21 days ago

Comment by ~stacyharper on ~mil/sxmo-tickets

For the record please remember this isnt just some kind of "emulation" we want. Interpreting a hold touch 2 seconds as a right click is only correct if the software say so. The compositor cant guess that and that isnt it's job. Plus ideally we dont want to match the pointer events workflows. Having dedicated behaviors for touches and styluses would be better.