Sxmo

Content

Rename User (Arch) Lock Screen (Sway) Status Bar Battery Indicator PinePhone Keyboard Empty/Off PPKB Don’t Display Phone Battery as Charging When Only PPKB Battery is Connected Display PPKB as 200% Displaying Multiple Batteries (Sxmo 1.14)

Rename User (Arch)

This section applies to Arch only and probably works for any UI on Arch with one simple change as mentioned below. It probably also works with other distros too, but likely not on postmarketOS, and not only because it doesn’t use systemd. I’ve read it doesn’t have usermod and it has the once set username hardcoded, but I don’t use postmarketOS so I have no idea. Also see this on the Mobian Wiki for Mobian/Phosh.

Preparations

You have to log in as root either via TTY or SSH. By that I mean directly logging in as root or using ssh root@something instead of elevating to root from your user account. That is because there has to be no process running under the affected user account and the SSH session would be one such process. If you’re doing it via SSH, you likely have to set a root password first unless it already has one, and enable logging in as root via SSH. To set a root password:

Then edit /etc/ssh/sshd_config and change the line containing PermitRootLogin to this:

Lastly restart sshd with systemctl restart sshd.

Changing the Username

Once you’ve logged in as root via TTY or SSH as described above, use the following steps. If you’re using a different UI, replace the occurrences of tinydm.service with phosh.service (Phosh) or lightdm.service (Plasma Mobile). The following lines stop the service that automatically starts and restarts Sway, then kill all processes of the affected user, rename the user, change the home directory to the new name, create a link from the old home path to the new one just to be safe and finally start Sway again.

Reverting SSH/Root Changes from Preparations

If you want to revert the root password and root access via SSH, which you should unless you have a reason not to, edit /etc/ssh/sshd_config again and revert the line:

Then remove the root password:

Lock Screen (Sway)

Sxmo does not yet feature a functional lock screen, only a more or less placeholder “locked” state that disables the touchscreen and switches to the “screen off” or “suspend” state after 8 seconds of inactivity, but there is no password prompt. With the keyboard case however any regular lock screen like swaylock can be used. The following describes the basic integration of swaylock into the Sxmo states.

For those without a physical keyboard who use numerical passwords, try swaylock-mobile (instructions 1 and 2) or schlock. For both of them you should follow the linked instructions instead since they require touchscreen input in the locked state.

Integrating Swaylock

First you have to install swaylock or one of its forks. I use and recommend swaylock-effects (swaylock-effects-git on the AUR) as it gives you more options like displaying the time and date.

To have the device go to the Sxmo “unlock” state after the password has been entered, create a script (optionally also available in my pinephone-utils repository) that executes swaylock first and then transitions to the unlock state. This also means that you shouldn’t --daemonize swaylock as it would then just immediately go to the unlock state. Add the following to a file, you could call it sxmo_swaylock.sh:

Now make the desired hook call this script. To edit a hook, copy it from /usr/share/sxmo/default_hooks/pine64,pinephone-1.2/ (replace the device name in this path with yours if you use a different one) to ~/.config/sxmo/hooks/pine64,pinephone-1.2/ and then edit the copied version. Create the directory first if you don’t have it yet with mkdir -p ~/.config/sxmo/hooks/pine64,pinephone-1.2. Copy sxmo_hook_screenoff.sh and add the line sxmo_swaylock.sh & near the top after . sxmo_common.sh. Replace the script name with yours if you used a different one and use the full path to it if it’s not in your $PATH.

You can make swayconfig keyboard shortcuts work in the locked state by adding --locked after its bindsym. I did this for my media, volume, brightness, flashlight and power shortcuts. Theoretically you could also use this to accept calls with the press of a button without having to type in the password, maybe with a single button press that is only defined for the --locked state. If a bindsym has one definition with --locked and one without, they can be set to do different things. Putting nothing after exec makes it execute nothing in the defined state. You could define spacebar twice and have it accept phone calls if locked, probably with sxmo_modemcall.sh pickup/hangup. This is just an idea, I haven’t tested it.

Lastly you have to edit the sxmo_hook_inputhandler.sh script which you have to copy from and to the same directories as the state hook above. This script handles the inputs from the phone buttons. It is set to do different things depending on the Sxmo state and on the focused application, like taking a photo with the power button while using Megapixels and switching between volume buttons and Sxmo-specific keys depending on the state. Modify the file by first adding the following new function for handling state transitions before the line XPROPOUT="$(sxmo_wm.sh focusedwindow)":

lock_screen_action() {
	state="$(cat "$SXMO_STATE")"
	case "$state" in
		unlock)
			state_target=screenoff
			;;
		screenoff)
			
			state_target=lock
			;;
		lock)
			state_target=unlock
			;;
	esac
	sxmo_state.sh set $state_target
}

Then replace all (currently five) instances of sxmo_state.sh click or sxmo_state.sh click 2 with lock_screen_action. You can see the changes to this file in practice by looking at this commit to my own file, except that my function is a little different as I will explain after the next paragraph.

You should now have a functional lock screen! I’ve been using this setup since 2022 without issues. Should you experience issues with the screen not turning on, you should still be able to type your password blindly while the device is not suspended, and unlock the session that way. If it then also does not automatically turn the screen on, open a terminal with a keyboard or button shortcut and again blindly execute sxmo_state.sh set unlock. SSH or TTY access being available is also recommended, use them to execute killall swaylock; sxmo_state.sh set unlock to remotely unlock. As a last resort you can of course still reboot the device with a long power button press. Removing or renaming the sxmo_swaylock.sh script you created also entirely and easily disables the password prompt should you wish to do so.

Alternatively, instead of locking the screen every time you turn it off, you can only lock the screen when the device suspends. This allows you to listen to music with the screen off without having to enter a password every time you turn the screen back on, for example. That’s what I do, I only want the password prompt to appear when I’m actually done using the device, meaning when it suspends and not just when I turn the screen off while still using it. To do this, add sxmo_swaylock.sh & not to sxmo_hook_screenoff.sh but instead to either sxmo_hook_presuspend.sh or sxmo_hook_postwake.sh. The presuspend hook has been removed from Sxmo with version 1.14, so the most comfortable way is adding the line to the sxmo_hook_postwake.sh hook which then locks the screen right after resuming from suspend. If that doesn’t sound good to you, the only other way currently is to edit the /usr/bin/sxmo_suspend.sh script and adding the line there, but since Sxmo updates reset this script without asking, you’ll have to manually re-add the line after updates (which might not be that much of extra work since updates might rework the state behaviours and then you’ll have to re-do everything in a new way anyway). In addition to the previously mentioned change in sxmo_hook_inputhandler.sh, you also have to entirely replace the line after screenoff) with the following if statement that either transitions to the lock state if the screen is locked, or to the unlock state if not. This makes sure that the power button switches between on and off when you’re using the device and the password prompt is inactive, and it switches between off and locked when the screen is locked.

lock_screen_action() {
	state="$(cat "$SXMO_STATE")"
	case "$state" in
		unlock)
			state_target=screenoff
			;;
		screenoff)
			if [ -n "$(pidof swaylock)" ]; then
				state_target=lock
			else
				state_target=unlock
			fi
			;;
		lock)
			state_target=screenoff
			;;
	esac
	sxmo_state.sh set $state_target
}

To customise swaylock, take a look at man swaylock and create a config file. I suggest using clock to display the date and time as well as indicator to always display it.

Status Bar

Battery Indicator

PinePhone Keyboard

Empty/Off PPKB

By the current default, when the PPKB is empty or switched off with the side button, “ERR” is displayed. To make it look a little nicer, I replaced it with a battery icon containing a question mark, which is appropriate because the PPKB could either be off or empty, its actual state is unknown.

If you haven’t already, copy the default hook to your home directory with cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks. Then edit ~/.config/sxmo/hooks/sxmo_hook_statusbar.sh and go to the line containing set_battery(). Go down a bit to the line if [ -z "$PCT" ]; then and replace ERR in the next line with 󰂑. Its the question mark battery icon. You can just copy it even if the icon is not being displayed here on this website. You can of course use any other icon you want, too.

Don’t Display Phone Battery as Charging When Only PPKB Battery is Connected

As explained here, the phone battery indicator will display that the phone is charging whenever the keyboard battery is not empty and was not shut off since it is a power source to the phone. But I assume I’m not the only one who would prefer it to only display as charging when an actual external power supply is connected.

If you haven’t already, copy the default hook to your home directory with cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks. Then edit ~/.config/sxmo/hooks/sxmo_hook_statusbar.sh and go to the line containing set_battery(). A bit below that is the line BATCMP="ERR" (that you might have changed in the previous section). Replace the elif line below that with the following line:

If you’re using the PinePhone Pro instead of the regular PinePhone, replace axp20x in this line with rk818.

Display PPKB as 200%

The PPKB battery’s total capacity is twice as high as the PinePhone’s. Displaying both battery capacities on a scale of 0-100% makes one of these two values go down twice as fast as the other. To make both numbers mean and feel the same, I simply doubled the PPKB’s value, making 100% show up as 200%, 50% as 100% and so on.

If you haven’t already, copy the default hook to your home directory with cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks. Then edit ~/.config/sxmo/hooks/sxmo_hook_statusbar.sh and go to the line containing if [ -z "$SXMO_BAR_SHOW_BAT_PER" ]; then . Go down a few lines to the else line. Add a new line after that line and paste the following code block into it:

Displaying Multiple Batteries (Sxmo 1.14)

Sxmo 1.14 removed the ability to show multiple batteries at once, but you can easily add it back in. If you haven’t already, copy the default hook to your home directory with cp /usr/share/sxmo/default_hooks/sxmo_hook_statusbar.sh ~/.config/sxmo/hooks. Then edit ~/.config/sxmo/hooks/sxmo_hook_statusbar.sh and go to the line containing set_battery(). A few lines below, multiple variables are defined. Paste battery_name=$(echo ${power_supply#*supply/}) into a new line after BATCMP=. Then go to the line containing battery-icon and replace the line with battery-icon-$battery_name 60-$count-a "$BATCMP". Go down a few lines to sxmobar -d battery-status and replace that line with sxmobar -d battery-status-$battery_name. Lastly, go down again to the next sxmobar line and replace it with sxmobar -a battery-status-$battery_name 60-$count-b "$PCT%". After the next statusbar update, you should see multiple batteries.