Hi Anjan,

Thanks for diving into this. I mentioned some ideas on IRC, but I thought I'd put them down here. Just take them with grains of salt. I think we have two issues with the motivation:

(A) We have some "optional" bits of sxmo-utils that should be split out: vvm (maybe even mms?), bluetooth, userscripts (youtube-dl, etc.), maybe even our core locking mechanism. Heck, maybe even modemmanager itself (on devices without a modem). For this, I think it makes sense to have in our Makefile various options (make all; make core; make vvmd) or even split these out into separate git repositories, and in the package manager for the distro have an sxmo-vvm, sxmo-bluetooth, sxmo-etc. I'm in favor of this, since it wouldn't introduce more code, it would just introduce more places where our code is stored.

(B) Some devices will require exceptions to our defaults regardless of what we do with (A). For instance, #2 in your list. And also the pinenote only has one button and no leds, so it requires exceptions. This is a harder issue. On the one hand, the fact that SDM845 doesn't work with pipewire is more of a problem with SDM845 and not a problem for us. I take it we've been kind of waiting to see if this gets fixed "upstream" before changing anything. I'm not sure of the solution. For the pinenote, we did this with our hooks, so maybe something like that for SDM could work... Perhaps we have an sxmo-pipewire and sxmo-pulseaudio-only package? But then how to get the package manager to install sxmo-pipewire vs. sxmo-pulseaudio-only package?

I'm hesitant to try to do something inhouse since it'd be more support and more code for us to handle (like having an sxmo_manage_packages.sh or something). I'd rather figure out a way to get the package manager of the distros to deal with managing which bits of sxmo are installed and which are not.

Anyway, just some thoughts.

Looks like pmos edge just pushed a new callaudiod that fixes it for me.

On Mon, May 22, 2023 at 04:04:33PM +0000, ~aren wrote:

This might be related https://gitlab.com/postmarketOS/pmaports/-/issues/2115.

Can someone who's having trouble with callaudiod provide the output of pactl list cards? I think it's possible it's not loading the right alsa ucm file and there's no voice call profile which would cause the described output from callaudiod.

Also there's a couple secondary bugs in your report that we should probably address:

The current release is 1.14, I'm guessing you got the version from the config menu entry which is out of date.

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

We definitely need to cleanup the call files if this happens.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-239221

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Just updated today and got the problem...

On Mon, May 22, 2023 at 04:04:33PM +0000, ~aren wrote:

This might be related https://gitlab.com/postmarketOS/pmaports/-/issues/2115.

Can someone who's having trouble with callaudiod provide the output of pactl list cards? I think it's possible it's not loading the right alsa ucm file and there's no voice call profile which would cause the described output from callaudiod.

Also there's a couple secondary bugs in your report that we should probably address:

The current release is 1.14, I'm guessing you got the version from the config menu entry which is out of date.

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

We definitely need to cleanup the call files if this happens.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-239221

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Just as an FYI, running pinephone on pmos edge and I do not experience this. That said, I didn't go through the normal ugrade process so maybe a package is missing. Will dig a little deeper.

On Sat, May 20, 2023 at 12:47:43PM +0000, ~euhmeuh wrote:

Oopsie, forgot to mention that's the pinephone on postmarketos edge.

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575#event-238924

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

What device is this?

On Fri, May 19, 2023 at 04:12:19PM +0000, ~euhmeuh wrote:

Hello ! I waited quite some time before updating to 1.13 because I know for sure I get issues when updating too soon... Alas, I still got screwed up by the update T_T

sxmo is unable to switch to callaudiod, which makes calls impossible, and I can't even hang up the call because the audio crash makes the hang up script fail too.

I investigated a little and found that the call to :

dbus-send --session --print-reply --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.freedesktop.DBus.Properties.Get string:org.mobian_project.CallAudio string:"AudioMode"

returns correctly uint32 0 (which means Normal mode)

but calling :

dbus-send --session --print-reply --type=method_call --dest=org.mobian_project.CallAudio /org/mobian_project/CallAudio org.mobian_project.CallAudio.SelectMode uint32:1

returns org.freedesktop.Dbus.Error.Failed: Operation failed

without further explanation...

I tried starting callaudiod myself with debug enabled like so : killall callaudiod && G_MESSAGES_DEBUG=all callaudiod

but it keeps spamming the logs with callaudiod-pulse-CRITICAL: No suitable card found, retrying in 3s...

I can correctly switch profiles and play with the sound using pavucontrol though, but the whole calling logic in sxmo still fails because it expects the dbus call to succeed.

The sound cards are correctly shown by alsa. I also did the pactl unload-module module-suspend-on-idle trick.

Also, I uninstalled sxmo-common-bluetooth, sxmo-common-audio-pipewire and installed sxmo-common-audio-pulse.

I also checked that pipewire was not running.

Any ideas ? That's kinda important for me to find a solution because I can't have phone calls at all right now :/

-- View on the web: https://todo.sr.ht/~mil/sxmo-tickets/575

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

Another thought I just had (if our goal is to eliminate physical presses): we could rewrite the "butt wakeup" code so that it takes one power button followed by a swipe up to fully unlock the phone.

On Mon, May 08, 2023 at 07:41:20PM +0000, ~hazardchem wrote:

Might be easier to start from scratch now.

That's put a dampener on my motivation.

Sorry!

Yeah, when I think about it, we already have a pretty solid system going in sxmo_appmenu.sh, it'd be a shame to scratch it and go with something else. We just need some more consistency and the ability to go "back" up a directory level.

-- sic dicit magister P https://phartman.sites.luc.edu/ GPG keyID 0xE0DBD3D6 (CAE6 3A6F 755F 7BC3 36CA 330D B3E6 39C6 E0DB D3D6)

It means return to menu when done (or not)

Great idea. Some comments:

powerbutton_three (prox lock): we shouldn't need a button to kill it in an ideal world. Since this is a "debug thing" we can remove it. User can ssh in if things go to shit.

powerbutton_three (terminal): it's pretty easy to open a new terminal via menu -> apps -> st, so this can o

voldown_two: in dwm the layout toggle is still on the statusbar. Maybe put it there for sway too? or just stuff this within a menu item.

voldown_three seems kind of necessary --- I can't think of a gesture I'd want to kill my app.

So really only one I'd want to keep is voldown_three -> some safe (and quick) way to kill current client...

Here are some thoughts about a menu redesign.

One goal is to have a uniform UI element that allows us to (1) close menu and (2) go up to a parent menu. This UI element should work from ssh and dwm/sway.

Another goal is to split up our massive sxmo_hook_contextmenu.sh into smaller and more manageable chunks. This will save some headache if someone customizes a small bit of menu and has to run sxmo_migrate.sh all the time (as is the case now).

One idea I currently have is something like this.

1. We have a .config/sxmo/menus/ directory and the directory structure here will mirror the menu structure, e.g.

menus/main/sxmo_menu_main.sh menus/main/dialer/sxmo_menu_dialer.sh

1. We use lisgd swipe down to close menus and lisgd swipe up to go back up in the menu tree. But this won't work on ssh!

2. For ssh, we could populate the bottom two entries of every menu with "Close" and "Previous" --- a user can then use the narrow-as-you-type option in ssh to access these easily. They won't clutter up the UI for dwm/sway either since they'll be at the bottom.

Anyway, some thoughts for now. I can already think of problems.