Or would another environment variable be suitable? Such as SXMO_SERVICE_MANAGER.

But as I was trying this reply I can see having a unified hook will be a cleaner idea to support this.

This has been fixed by the following:

https://git.sr.ht/~mil/sxmo-utils/commit/54ebae73d39ca815f50970a839acbdd2de96a23f

For dwm users see the following project:

https://codeberg.org/jackc/smlock

This also requires on pmos the following patch under:

root_dir/usr/share/X11/xorg.conf.d/04-fonts.conf

Section "Files"
  FontPath "/usr/share/fonts/dejavu"
EndSection

Then you will have a screen locker that will allow svkbd to be shown over the top.

It will need a way to embed dmenu into the locker to display limited features such as incoming calls or a lockscreen functions activation such as torch.

Do you have a link for that script?

to me this would need modifying to source that script to set the env variable:

configs/appcfg/profile_template:export SXMO_BG_IMG="$(sxmo_hook_wallpaper.sh)"

I believe this is a common issue with a lot of people but when pressing the power button the behaviour of lock - unlock - screenoff is inconsistent.

For example:

• Sometimes when pressing power button in suspend state wil bring you straight to unlock, sometimes will lock
• Sometimes when locked will bring straight to screenoff again.

To me it seems like the main part of detecting presses of the button sometimes will loop twice for one button press.

This could be an issue with the button press threshold or the double press part of the script is an issue.

I have noticed different behaviour with sway and dwm.

When dwm is screenoff and dmenu appears it is still consuming physical button presses at the same time as the lock - unlock - screenoff loop is happening.

On sway this doesn't happen until the system is in unlock state.

I'd rather have one ticket per issue, that way we can use the tools that sr.ht provides to track the status.

Yeah happy to do that if thats how things work for sr.ht.

On Sun, Apr 14, 2024 at 10:39:24AM +0000, ~hazardchem wrote:

After reading a blog post by Drew DeVault (on mobile linux) and polling the sxmo irc I have come across some reliability issues that we should look at addressing

• Lock, Unlock, and Screenoff loop behaves inconsistently:
  • Single button press will sometimes bring to an unexpected state.
• Waking up when there is a call coming in, and the delay to displaying a call
  • And also trying to unlock the screen see point above
• Battery percentage update post suspend, sometimes will take 5-10 seconds to update

Yup bugs, I'll take a look at them if I can find the time.

• DWM vs Sway giving inconsistent experiences
  • Possibly the easiest way to solve this is to change dwm to i3 as they its the x11 version of sway but there could be opposition to that (myself would be opposed to that change)

The only thing to do here is file bugs / send patches and we'll try to get it fixed.

I don't think switching to i3 much as most of the difference are between xorg and wayland, and less between window manager specifics.

• Volume bar is laggier than the brightness bar to display

This is because each 5% increment requires a call from lisgd to the inputhandler to pactl / brightnessctl. IIRC the case statement in the inputhandler takes a while to execute, on top of forking several shells which will take 5ms-10ms each and pactl takes 50ms-100ms. All together I think one loop is on the range of 200ms-300ms.

There's a few things I can think of that might help:

• try moving the pactl calls straight into the lisgd commandline
• modify lisgd to print gestures to stdout instead of calling system, and keep the input handler hook always running (this saves a fork)
• batch events, e.g. if 3 volume up gestures are triggered while one is processing, instead of calling the script three times, call it with a count of 3
• (more aggressive) have some daemon that handles gestures which can keep an open connection to pulse/pipewire. pactl alone takes 50ms-100ms on my phone, and I wouldn't be surprised if a good portion of that is setting up the dbus connection.

The main goal of this bug report is to provide some focus on how to get some reliability issues sorted and visibility of them. This can be updated to follow more issues that arise as well.

Let me know your thoughts on the topic as this is the only way we are going to get progress is by talking about them.

I'd rather have one ticket per issue, that way we can use the tools that sr.ht provides to track the status.

After reading a blog post by Drew DeVault (on mobile linux) and polling the sxmo irc I have come across some reliability issues that we should look at addressing

• Lock, Unlock, and Screenoff loop behaves inconsistently:
  • Single button press will sometimes bring to an unexpected state.
• Waking up when there is a call coming in, and the delay to displaying a call
  • And also trying to unlock the screen see point above
• Battery percentage update post suspend, sometimes will take 5-10 seconds to update
• DWM vs Sway giving inconsistent experiences
  • Possibly the easiest way to solve this is to change dwm to i3 as they its the x11 version of sway but there could be opposition to that (myself would be opposed to that change)
• Volume bar is laggier than the brightness bar to display

The main goal of this bug report is to provide some focus on how to get some reliability issues sorted and visibility of them. This can be updated to follow more issues that arise as well.

Let me know your thoughts on the topic as this is the only way we are going to get progress is by talking about them.

I have noticed an issue when using a touch screen device such as the PinePhone that when touching on a text input on a website that the input is still directed to wherever the UI element is selected and not to the web page.

The only way to get the text to input is to tab until the selected UI element passes the print button and before it reaches the search box.

Using a mouse does't have this issue as the text is directed to where I have clicked on.