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
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
Comment by ~stacyharper on ~mil/sxmo-tickets
Wait for alsa ucm conf to be fixed
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.
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.luaUncommment 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.
Comment by ~stacyharper on ~mil/sxmo-tickets
This should be fixed now !
REPORTED RESOLVED IMPLEMENTED
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)
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
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.
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.
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.