Manjaro Arm and KDE Plasma Mobile are Linux projects aimed at bringing security, configurability, and open-source software to mobile platforms.  The notion of configurable, user-focused mobile devices appeals to users who are eager for an alternative to iOS and Android devices.

Both Manjaro and Plasma Mobile are works in progress. By far, the most impactful bug I encountered using Manjaro Arm related to the lock screen on the PinePhone Beta Edition.  Fortunately, the problem was solved by issuing a single command to the phone’s terminal app.  I’ve documented the procedure here to give readers a realistic idea of what it’s like to use these software tools and occasionally fix unexpected behaviors.

Notice of Non-Affiliation and Disclaimer: As of the publication date, we are not affiliated with, associated with, authorized by, endorsed by, compensated by, or in any way officially connected with Pine64, Manjaro GmbH & Co KG, Arm Limited, or their owners, subsidiaries or affiliates.  The names Pine64, Pine Phone, Arm, as well as related names, marks, emblems, and images are trademarks of their respective owners. External Links: Links to external web pages have been provided as a convenience and for informational purposes only. Unboxing Tomorrow and Voxidyne Media bear no responsibility for the accuracy, legality or content of the external site or for that of subsequent links. Contact the external site for answers to questions regarding its content.

The Lock Screen Bug Summarized

Normally, if a phone sits idle for too long, it should shut off the display, and optionally not resume until the user authenticates themselves.  In Manjaro with KDE Plasma Mobile version 5.21.2, this behavior is adjustable under the Settings > Screen > Lock Screen and Sleep dialog.

And the configuration itself is stored in the phone’s filesystem as the file: ~/.config/powermanagementprofilesrc

But for this particular phone, it began to lock not after the specified time delay, but instantly any time the screen was tapped or after a button was pressed.  Unlocking the phone worked only until the next touch or button press, which locked all over again.  This happened in an endless loop.

Steps to Reproduce the Bug

The trouble started sometime after following these steps…

1. Went to Settings > Screen
2. Set Lock Screen Sleep = Never
3. Removed the phone from the charger
4. Connected to a Wi-Fi network

Shortly thereafter, the problem would happen any time the phone was not plugged into a USB charger.  Restoring the default setting did not fix the problem.

Fixing the Problem

After searching the Manjaro Arm forum for a solution, it was clear the file: ~/.config/powermanagementprofilesrc needed to be deleted or at least renamed to restore the default setting.

Fortunately, I had already connected the phone to a local Wi-Fi network. This meant that even in its locked state, the phone was still remotely accessible via secure shell (SSH).

Command Line Basics

For anyone new to the command line interface and the bash shell: there are a few things to know:

1. The command line is case-sensitive
2. File paths use the forward slash /
3. File extensions are optional. The “powermanagementprofilesrc” file has none at all.
4. If a command returns absolutely no output, that usually means it was successful
5. To exit the terminal, type “exit”

Accessing the Phone Via SSH

With the phone connected to my local Wi-Fi network (or hotspot), I opened the Windows application: PuTTY.

In PuTTY’s opening dialog:

1. Enter the IP address assigned to the phone
2. Set Port = 22
3. Click “open”

When the black and white terminal emulator appears, log into the phone using the username and password you configured into the phone.  After a short delay, the welcome message and a command prompt should appear…

Now it’s time to rename the offending file.  In the shell, use the move (mv) command to move the file from one name to another.

mv ~/.config/powermanagementprofilesrc ~/.config/powermanagementprofilesrc.old

Command explanation:

• mv means “move”
• ~/.config/powermanagementprofilesrc is the path to the original file, where ~ is the equivalent of typing the home directory (which is usually in the form: /home/your-user-name-here)
• ~/.config/powermanagementprofilesrc.old is the new name I have assigned to the file.  Adding .old to the end is a reminder that this is a renamed version of an older file.

This change fixed the problem immediately.

Inspecting powermanagementprofilesrc

The powermanagementprofilesrc file is rather short and human-readable.  Open the original by typing…

nano ~/.config/powermanagementprofilesrc.old

Or view the new version by typing…

nano ~/.config/powermanagementprofilesrc

Here is now the bugged version and the restored version compared…

ORIGINAL (Caused lock screen bug)

RESTORED (Bug-free)

[AC] icon=battery-charging [AC][DPMSControl] idleTime=60 lockBeforeTurnOff=1 [AC][DimDisplay] idleTime=300000 [AC][HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16 [Battery] icon=battery-060 [Battery][BrightnessControl] value=0.5 [Battery][DPMSControl] idleTime=60 lockBeforeTurnOff=1 [Battery][HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16 [Battery][SuspendSession] idleTime=120 suspendThenHibernate=false suspendType=32 [LowBattery] icon=battery-low [LowBattery][BrightnessControl] value=30 [LowBattery][DPMSControl] idleTime=30 lockBeforeTurnOff=1 [LowBattery][DimDisplay] idleTime=30000 [LowBattery][HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16 [LowBattery][SuspendSession] idleTime=300000 suspendType=1

[AC] icon=battery-charging [AC][DPMSControl] idleTime=60 lockBeforeTurnOff=1 [AC][DimDisplay] idleTime=300000 [AC][HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16   [Battery] icon=battery-060 [Battery][DPMSControl] idleTime=60 lockBeforeTurnOff=1 [Battery][DimDisplay] idleTime=30000 [Battery][HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16 [Battery][SuspendSession] idleTime=300000 suspendType=1 [LowBattery] icon=battery-low [LowBattery][BrightnessControl] value=30 [LowBattery][DPMSControl] idleTime=30 lockBeforeTurnOff=1   [LowBattery][DimDisplay] idleTime=30000 [LowBattery[HandleButtonEvents] lidAction=1 powerButtonAction=128 powerDownAction=16   [LowBattery[SuspendSession] idleTime=300000 suspendType=1

As the comparison shows, the bugged version has a [Battery][BrightnessControl] property that the working version doesn’t.

What’s more revealing is the [Battery][SuspendSession] property has idleTime set to “120” in the bugged version, but “300000” in the non-bugged version.  There are no units of measure to contextualize what “120” and “300000” mean.  But if the assumed units are milliseconds: the non-bugged version would correspond to 5 minutes, and the bugged version would be 0.12 seconds.  This doesn’t quite explain everything, but it’s a start.

This ambiguity in units is always why I often append a unit of measure to the end of variables that store measurements (ex: setupTime_ms, holdTime_us).

Closing Remarks

Generally, the best way to avoid technical glitches is to frequently check for an install official updates through the Discovery app.  Alternatively, the Pine Phone can boot other operating systems if the microSD card slot contains a bootable Linux image.

Important Notice: This article and its contents (the “Information”) belong to Unboxing-tomorrow.com and Voxidyne Media LLC. No license is granted for the use of it other than for information purposes. No license of any intellectual property rights is granted.  The Information is subject to change without notice. The Information supplied is believed to be accurate, but Voxidyne Media LLC assumes no responsibility for its accuracy or completeness, any error in or omission from it or for any use made of it.  Liability for loss or damage resulting from any reliance on the Information or use of it (including liability resulting from negligence or where Voxidyne Media LLC was aware of the possibility of such loss or damage arising) is excluded.