I have this issue as well, intermittently (pinephone, pmos stable).

There is a way to stop the proximity lock when it's running by pressing the powerbutton 3 times (or long enough press to count as 3 times), but that doesn't work when a menu is open (like for an incoming call).

A better workaround than export SXMO_PROX_RAW_BUS=/dev/null is to create a file containing a number less than 50 and setting SXMO_PROX_RAW_BUS to the path of that file.
In my testing, the proximity lock then behaves as if the sensor is always uncovered, which means the phone will effectively be unlocked whenever an incoming call arrives.

Another workaround would be creating a script called sxmo_proximitylock.sh somewhere earlier in $PATH than /usr/bin, and having it just execute sxmo_hook_lock.sh (or whatever you want).

I've gone through sxmo_proximitylock.sh and checked the things it does to set up and monitor the proximity sensor.

At the times it's not working, the iio_event_monitor command does not print anything when the sensor is covered/uncovered, even though the threshold files contain the correct values.
It prints the right line when started, but it should then print lines that include 'rising' or 'falling' when relevant.
This behaviour is identical to that when the thresholds are left as their default values (0 and 6553, which I believe never occur on my device).

The raw bus behaves exactly as it should even when iio_event_monitor doesn't.

Since reading the raw bus works, when sxmo_proximitylock.sh is executed it sets the state to proximitylock/unlock depending on if the sensor is covered or not, but then won't change regardless of what the sensor reports.

I don't know why it works sometimes and not others for me.
I imagine there's either a bug in iio_event_monitor, or the threshold values are not taking affect somehow, but I have no idea how to continue investigating that.

The name of this ticket should probably be changed.

Just having a notification that an sms is being received and then carrying on as it currently is would certainly be the simplest change that would help with this issue.

In my case I'd definitely want more than that since this affects at least half of the texts I receive and I wouldn't want to have to wait a bit and manually check each one, but as you say that doesn't necessarily need to be in sxmo-utils.

Actually, if this isn't decided to be a big enough problem to fully solve in base sxmo then maybe the best answer would be creating an sxmo_hook_sms_added.sh* to be executed alongside checkfornewtexts in sxmo_modemmonitor.sh. It could either be empty by default, or notify the user if there are any sms that have been received but not processed (and deleted) by sxmo_modem.sh after a short sleep.
I can then put whatever I want in there, or anyone else with similar issues.

For what it's worth, with my method the only time it'll ever hit the sleep and loop again is if it's an sms that would have been missed with the current system. Any sms that wasn't missed when it arrived was fully received in the time it took to run "echo $line | grep -qE '^signal' && sxmo_modem.sh checkfornewtexts", after all.
What I've written can definitely be tweaked so that if the text is already fully received then as little extra code is executed as possible compared to now if it is decided to include something like this in sxmo-utils.

* Called sms_added not sms_incoming because it would be run for outgoing texts as well as incoming, unless sxmo_modemmonitor.sh was changed, which maybe it should be but that's probably a separate question.

If my phone receives a text, it's seemingly completely random whether I'll be alerted to it or not until another text arrives or I wake the phone manually later.

I've had this problem every time I've tried using SXMO on my pinephone, but only had the time/inclination to track it down recently (I use it as my actual phone and need to receive texts on time most of the time), but I have now tracked down the cause of the issue and have a solution.

I've written a standalone monitor script that I've been testing after removing the default text handling from smxo_modemmonitor.sh and it's been working really well, but I don't know how to best incorporate the method into the current SXMO code, and it needs some way to handle stuck SMS. So rather than submit a patch I've explained everything below.
I've probably given much more detail than needed.

Here's a link to my script: https://paste.sr.ht/~rgybmc/10b91ce0719977e23ebb8fb3ed8dcba2a327c170

How I understand SXMO to handle receiving texts currently:

• sxmo_modemmonitor.sh runs sxmo_modem.sh checkfornewtexts when modemmanager sends a dbus signal that a new SMS object has been added.

• sxmo_modem.sh checkfornewtexts checks for SMS objects that have state 'received', and ignores any others.

• sxmo_modem.sh checkfornewtexts is run by sxmo_run_aligned.sh every 5 minutes real time.

The cause of my problems:

• When an incoming SMS is first added (triggering checkfornewtexts) it has the state 'receiving' and this only changes to 'received' when the full SMS has finished arriving.

• If the phone is suspended when the SMS arrives and has been suspended long enough for the 5 minute check to occur then it will be run immediately upon waking.

• Whether the SMS state is 'received' at the time(s) checkfornewtexts runs the mmcli command to list the SMS objects is effectively a race condition.

• checkfornewtexts will not be run again until another SMS is added, or the next time a 5 minute check is run (likely when the phone is woken manually much later), and the incoming SMS will not be processed until then.

The solution (in my opinion):

If we know we're receiving an SMS, we should wait until it's fully received before trying to read and process it.

The dbus signal that sxmo_modemmonitor.sh monitors conveniently contains the object path of the SMS (including the ID), and whether the SMS is incoming or outgoing. The code to collect that information is simple thanks to the predictable nature of the signal.

dbus itself sends a signal when the properties of a modemmanager object are changed, and using the SMS object path we can monitor for the state to change to received. However, when testing I found that signal rather slow to be sent after the state is actually changed, and sometimes was never sent.

So, my script enters a loop to keep checking the state of the SMS (using mmcli) after a sleep until it's 'received'. It's worked really well for me for more than a week using text messages extensively.

Issues:

If an SMS becomes stuck, which still happens to me occasionally, the state will perpetually be 'receiving' until it's handled some way (normally modemmanager or the modem itself restarting, I think), meaning my method will loop indefinitely unless we put in some sort of timeout, and I have no idea how long would be reasonable, or what to do when it runs out.

As far as potentially integrating this method into SXMO goes, I don't know whether it would be better to add it to sxmo_modemmonitor.sh or to sxmo_modem.sh, and it might make sense to change checkfornewtexts either way to use the known id rather than starting from scratch looking for received texts (and presumably put that part in a seperate function for running manual/periodic checks).

Brilliant, thank you.

Updated and I can confirm it's working for me.

Hi,

When I run wofi with width=100% and orientation=horizontal (everything else default, no style.css), the wofi window is wider than my screen.

I'm using arch linux, and it happens both with wofi 1.2.4 from the repos and wofi-hg from the AUR.

Through experimenting, it appears that the extra width (~166px on my 1366x768 screen) is almost exactly the width of the input box.

I don't know C so can't check, but is the width of #scroll being set to the screen width, then #input added next to it?

Edit: Oh yeah, this is on sway 1.5.1