I have a classic Pinephone running PMOS edge, but I've also seen this in stable on multiple installations. Whenever the phone starts either an outgoing or incoming call, it appears to lock--the screen goes black and it usually takes a few presses of the power button. Sometimes the screen comes back on, but usually the phone picks up while the screen remains black. At the moment, though, there's no screen protector on the phone.

My current solution for this is setting export SXMO_PROX_RAW_BUS=/dev/null in the SXMO profile file which seems to basically disable the proximity lock

Thanks, fofeu, that works.

Actually, this is a partial solution. I put the line above in .profile. Now, if a call comes in with the screen on, the call menu is visible as expected. But if the screen is off, it stays off, and if I push the on/off button, the call answers and the screen stays black. This also happens in suspend.

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.

I also relate proximity lock problems, sometime, randomly. Sometime it works, sometime it doesn't. The problems is that we don't receive the events from the kernel driver.

I also note that I always had and have a screen protector, so I don't think this is related.

Also, recently we change a bit of code about state switching, and how proximity lock interract with this. Now we should alway keep control over the state while screenoff (even with proximity lock on). So if the screen is off, we should just be able to power to unlock it. I hope this help us to mitigate the issue when it happen.

This should help:

https://lists.sr.ht/~mil/sxmo-devel/patches/44825