When I dial a number and have the L5 in my hand or on the desk, the screen goes black when the dial button us pressed. Later it comes up for short moments, impossible to hang up the call. It is reproducible fully. This is new since the last updates.
Update: I created an issue here: https://gitlab.gnome.org/GNOME/calls/-/issues/560
The above issue talks about a change in the kernel:
You can try going back to the old values for your device as in
https://source.puri.sm/Librem5/linux/-/merge_requests/637/diffs .
At the moment gnome-calls is not useable 
for me. Was the above change tested on a L5 with gnome-calls?
Yeah i gaming with my L5 yesterday, i tested Calls and others, yeah Calls app and modem work really UNreliable UNstable
Hello @dos ,
The issue https://source.puri.sm/Librem5/linux/-/merge_requests/637/diffs states that you are the author/origin of the merge of the proximity sensor changes which came down to my L5 on March 12. Since then my L5 is not usable anymore for phone calls, maybe already since March 2 (I checked my dial history for the day of last phone call which was still working). And now, what should be done?
Am I the only victim? 
matthias
laying alone on the table it shows 5 or 6
Is there anything covering the proximity sensor, like a screen protector? It should be about 2-3 at rest, not 5-6.
I have a 3D printed case which covers the back and sides; no screen protector. I pulled the L5 out of the case and now it is exactly as it was sent to me me and shows 5-6; see screen.
I just did some test calls to my landline phone at home and watching via SSH the value of the sensor. It is 6 when dialed and connected, and when I put my hand over the L5 it goes to 22… And the screen goes black and does not come back, even when the sensor goes down to 6 or 5. It is NOT fully reproducible.
Looks like your L5 is somewhat exceptional 
In any case, the next kernel update will have the threshold bumped up to 7 so it should stop causing problems on your phone.
@dos, could you please point me to the sources for monitor-sensor; I want to clarify something, when it says (near: 1). Thanks
In the page https://developer.puri.sm/Librem5/Development_Environment/Boards/HowTo/Proximity.html is explained, how to use/check/ask the proximity sensor. My question is: how the current value of this gets delivered after the following command? The page says only " This will cause the ProximityNear property to be updated:"
gdbus call --system --dest net.hadess.SensorProxy \
--object-path /net/hadess/SensorProxy \
--method org.freedesktop.DBus.Properties.Get \
net.hadess.SensorProxy ProximityNear
How do I read its value?
I believe you’ll see this when you run monitor-sensor
When I do run monitor-sensor without this gdbus stuff below I see:
purism@pureos:~$ monitor-sensor
Waiting for iio-sensor-proxy to appear
+++ iio-sensor-proxy appeared
=== Has accelerometer (orientation: undefined)
=== Has ambient light sensor (value: 0.000000, unit: lux)
=== Has proximity sensor (near: 0)
Light changed: 10.440000 (lux)
Proximity value changed: 1
Light changed: 10.200000 (lux)
Light changed: 10.440000 (lux)
Light changed: 9.360000 (lux)
Light changed: 10.920000 (lux)
Light changed: 9.360000 (lux)
Light changed: 9.600000 (lux)
Light changed: 0.000000 (lux)
Light changed: 10.680000 (lux)
Light changed: 10.920000 (lux)
Light changed: 11.160000 (lux)
Light changed: 0.000000 (lux)
Light changed: 11.640000 (lux)
Light changed: 11.160000 (lux)
Light changed: 11.280000 (lux)
Light changed: 11.400000 (lux)
Light changed: 10.800000 (lux)
Light changed: 10.920000 (lux)
When Light went to 0.0000 it was because I put another phone above the L5. Then I put it away again, Light came back to 11.xxx, but proximity never changes back to 0.
Running,
watch -n 1 cat /sys/bus/iio/*/*/in_proximity_raw
shows that the proximity sensor is working fine: it is 5-6, when I put the other phone above, it raises to 24++ and when I withdraw it again, it goes down to 6 again. So, the sensor is working. But monitor-sensor is not following the situation.
Oh I see, I read the article wrong, my mistake. The next thing I would try is looping that big “get” command in a different process (either another terminal window or via a short bash script) and then run monitor-sensor.
It is following the situation. The threshold value for Evergreen batch has been set to 5 in the previous kernel update, meant to improve sensor’s responsiveness against hair. Most devices report levels of 2 or 3 when at rest, your one reports higher values for some reason. The next update bumps it up to 7.
What about if watch cat /sys/bus/iio/*/*/in_proximity_raw says 4 or 5, with or without covering the screen? This is with no case and the original screen protector.
I have used the phone as a daily driver since October, and the screen does not turn black during calls. I just assumed the feature was not implemented.
The sensor is located between the earpiece speaker and selfie camera, so that’s the part you need to cover in order to test it.
Thanks for the tip. Covering the earpiece and selfie camera firmly with my thumb still gives 4 or 5.
Edit: As in covering the area between the earpiece and camera at the same time. But this sounds like I should send an email to support.
Instead of watch I do use now from a script:
purism@pureos:~$ while true ; do echo -n "$(date '+%T'): "; cat /sys/bus/iio/*/*/in_proximity_raw ; sleep 1; done
09:24:12: 6
09:24:13: 7
09:24:14: 6
09:24:15: 7
09:24:16: 14
09:24:17: 50
09:24:18: 6
09:24:19: 6
09:24:20: 6
09:24:21: 7
This gives you later a better way to match the time of dialing a call, etc, with the value of the proximity sensor. And, dimming the screen should only happen when in a call and having the L5, for example, near your ear. Not generally when you do something else on your display.
I.e. the dimming has also to do with the gnome-calls app, and not only the sensor. Can someone (@guido.gunther, @dos) shed a bit light on this to understand it better.
There is definitely something also wrong with the app gnome-calls:
I received a call in the L5 and when I wanted to answer it, the screen went black. In only saw the incoming call for a short moment but could not hit the answer button.
I had to wait until the caller hung up.
Then I tried to reproduce this problem calling my L5 from my iPhone and was connected via SSH to monitor the sensor without hitting answer, only from time to time tapping the sensor with the finger while the L5 was ringing:
purism@pureos:~$ ./wprox.sh
19:47:45: 6
19:47:46: 6
19:47:47: 4
19:47:48: 8
19:47:49: 7
19:47:50: 5
19:47:51: 7
19:47:52: 12
19:47:53: 6
19:47:54: 54
19:47:55: 56
19:47:56: 53
19:47:57: 59
19:47:58: 7
19:47:59: 6
19:48:00: 6
19:48:01: 7
19:48:02: 6
19:48:03: 5
19:48:04: 6
As you can see, the sensor was working, but the screen never went black.
maybe it needs to account for a saturation hysteresis curve where it does account for variations between covering and uncovering the sensor with different resting states and rates of change due to differences in terms of whether it is used during daylight or in a dark room, and variations in screen protectors, and sensor differences etc
Or a simple sensitivity slider could be added to mobile settings to do quick adjustments by the user.