It crossed my mind. But the sensor doesn’t seem to be used yet, so maybe the control over its activation will be tightened up when it is put into use. It would probably be slightly more energy efficient if it was only activated when its input is actually required, rather than every time the screen lights up.
According to the schematic, it’s a VNCL4040 Fully Integrated Proximity and Ambient Light Sensor, so it’s a self-contained module with very little direct control over the IR emitter from the outside. You give it power and configuration data, and it gives you data about proximity or ambient light levels.
It’s the right wavelength for an IR remote (940nm) but you also need to be able to modulate the output at tens of kHz if you want to send IR remote commands. Skim reading the datasheet, it looks like it might be possible to do something like that, because it does accept some commands that affect the IR emitter, but it’s not really designed for sending IR signals so it might not come to anything. You’d have to do some experiments and see what you can hack it to achieve.
Looking more closely at mine, I notice the VNCL4040 is at a jaunty angle. It’s probably about 5 degrees off level. I wonder if that’s by design or if they are just not very accurately aligned. (I’m assuming it is supposed to be like that and it’s not a manufacturing defect.)
I wiped the fingerprints off the screen and then held the phone under a bright desk lamp. The sensor and its little stadium-shaped window become visible under those conditions.
I did that because, on first glance, I thought the sensor had a circular window, but after looking at the datasheet for the sensor, I realised I had only been looking at half of it.
I just realised: this sensor probably explains the random screen blanking I was experiencing while using the phone. If I put my finger over the sensor and hold it there for a few seconds, the screen fades to black. I wasn’t conscious of doing that before, but it just happened to me again and I suddenly realised where my fingers were resting and made the connection.
I was planning to eventually report the random screen blanking as a bug, but now I think it’s actually by design: that’s what the proximity sensor is for. But it’s not when it’s for, because it hasn’t been narrowed down to only work during calls yet. It would still be a bug, because that’s a confusing behaviour, but it looks like it will be changed if the merge request linked by @spaetz above comes to anything.
Yes, accidentally covering the proximity sensor makes the screen go black. I was going to mention it months ago, but I thought it was maybe too obvious to create a forum entry. Then again, you’re right that with normal design, it should only happen when you’re on a call. I hadn’t thought of that point.
Oh, so it does have that feature! That’s something I would find quite useful, but I assumed that since it wasn’t doing it by default the feature did not exist. (Apparently I didn’t look very closely at the Power settings.)
Having said that, automatic brightness seems a bit over-sensitive at the moment, so I’ll probably leave it off for now. I don’t want the brightness visibly changing just because I lean forward two centimetres. That’s really annoying. It probably needs to take the average of the ambient light level over a longer period.
Yes, that’s the expected behaviour at the moment. We’re talking about two distinct features here. The screen blanking is separate from the automatic brightness.
The screen blanking (and touch input rejection) is primarily meant for when you are holding the phone against your ear, but as we’ve seen it is easy to accidentally trigger it using your fingers. The changes mentioned in the merge request linked by spaetz above should limit the scope of when the screen blanking can occur.
That’s not the same thing as the automatic brightness feature. Automatic brightness just dims the screen slightly if you go somewhere dark and brightens it if you go somewhere light, so you don’t have to keep manually adjusting it. But you always need at least some light from the screen, even if you are deep underground in a coal mine at night with all the lights off, so it shouldn’t ever dim it to the point where it is off completely.
Edit: The forum automatically edited out my quote of the previous post. Just to be clear, this was a reply to @beltrandroid’s post immediately above.
The current, always-on, proximity detection is actually quite useful for preventing unwanted touch input if you want to put the phone in your pocket without locking it. Given that this feature will be narrowed down to only work during phone calls and similar, it would be quite good to leave open the possibility of an app that can effectively re-enable always-on proximity detection, on demand.
I suppose the proximity sensor could also be used to avoid pocket-dialling the emergency services or repeatedly entering incorrect PINs. (Currently, pocket dialling the emergency services is not really an issue, since the emergency call feature hasn’t yet been added to the lock screen.)
(I’d comment these points on the issue tracker, but I don’t have an account.)
Then click: “Sign in / Register” then “Register now” …
For clarity, your involvement with Purism will give you three different online accounts: ordering account (for ordering products and services), forum account (for this forum), GitLab account (for editing the community wiki and reporting issues). Three accounts is both a good thing and a bad thing.
I concur about the auto brightness being too aggressive. It pretty much keeps my screen slightly too dim for whatever the lighting is, and tilting it towards my face makes it dim even more.
I would love to be able to adjust the brightness while in auto mode and have it remember the offset, that way it can still be in auto mode but with a personal offset to my liking. I think Android does something like this.
Ah, I already tried that a couple of weeks ago. It told me my account needed to be approved by the GitLab administrator. It is currently still pending approval “and hence blocked”. It sounds like yours just went through without that.
I perceived that it was possible to adjust the brightness level in auto mode, although I suppose it might not have been having an effect. My complaint is not that it dims too much, but that it dims too readily.
If I compare it to a tablet computer from an established brand, you have to cover the sensor on the tablet for several seconds before it decides to dim the screen, and even then it takes several more seconds to gradually dim it. The Librem 5 leaves practically no delay, and dims not at all gradually enough for my liking.
If I were sat in a moving vehicle, with street lights flashing past through the windows in that slightly annoying way they do, the Librem 5 in auto brightness mode would be a disco of bright-dim-bright-dim-bright-dim-bright-dim flashing, brightening up every time we passed a street light and dimming again immediately afterwards, before brightening again at the next one. The tablet would not do that. I’m not sure precisely what the tablet would do. Perhaps it would take a moving average of the light level over the past 30 seconds or so and adjust to suit that average. Or perhaps it would apply a more sophisticated algorithm. It would certainly not raise and lower the brightness for every brief change in ambient light level, like the Librem 5 currently does.
I suppose the instant changing method could work if the phone responded quickly enough, but it’s always going to lag a bit and the brightness level is never going to be exactly perfect for the conditions, so it just gets annoying. Even if the electronics and software could react instantly, the sensor is only at one side of the screen, so if the light is sweeping across the device, the sensor will not see the light at the same time as most of the screen sees it. Better to change it gradually, then the precise level of brightness doesn’t matter so much either (but should still be adjustable).
Yes that too, it does change too fast. But also changing the brightness in auto mode only temporarily takes effect before it reverts back to the auto value.
