Few ThinkPad products support features related to “Human Presence Detection”.
This feature is “Screen OFF on Leave” aka Screen “Lock on leave” .
Earlier this feature was called as “Lock on Leave” but in future, this feature will be changed to “Screen OFF” only on Leave for user convenience. This will be same as Windows also.
Add Screen-Off-On-Leave Feature to gnome-control-center
I cannot provide the source code for this for now, but basically the feature is the prototype as shown above in Nitin’s Post.
Above modifications were made on gnome-46 and Ubuntu 24.04 as of now, but will eventually update to latest versions.
However, could not fully test gsettings-desktop-schema ScreenOffOnLeave modification because of issues during install. So during testing, I am currently testing on a branch without screen-off-on-leave implementation for both the gnome-shell extension and GUI app.
How this works:
Set Screen-Off-On-Leave setting → True when Screen-Off-On-Leave Feature is enabled
(Extension is enabled) Screen-Off-On-Leave Feature will utilize HPD Proximity and Distance values for determining if Screen Blank should be triggered. Screen-Blank Sequence is triggered (by setting idle-delay to 1 sec) when person is not detected after set amount of time and distance.
Disable-lock-screen is set to True
Screen-Off-On-Leave setting is checked if it is True in the extension. If True, disable-lock-screen setting is checked. If True, then during screen blank, fade animation is disabled.
The normal idle-delay value is restored after this sequence.
The proposal might be rough around the edges, but I am very much open to any suggestions on how best to implement this feature.
@felipeborges Thanks for your comment ! No , we have not considered it as we can use sysfs directly . Also , since the functionality is GUI based and we can use it directly in GNOME . Is it recommended to check it ?
I have tried checking it today but it seems can’t see hpd sensor information … may need some support for iio_proxy_sensor maintainer, if we need to use it ,
Btw , as @Josef-Ouano has mentioned, do you have any comment regarding Screenshied and gsettings-desktop schema changes ?
I don’t know why you’re trying to “keep this thread alive”: are you willing to work on it? Are you waiting for something? Did you open a merge request?
The thread was created at the tail end of the GNOME 49 development cycle, so any change would definitely not have time to be reviewed.
We are working on it and plan to release first version via github within this year .
However, we want Screen Off without Screen Animation which seems bit complex to handle.
So we want suggestion or support whether we can get some API etc to handle this.
We do have our own modifications for handling above issue, but we are not sure if they are applicable to gnome, which is why we haven’t made any merge request yet. So to say, we are looking for suggestions/second opinions on this.
In future, if everything goes good then we can add this in GNOME settings as well.
Also for reference, we made these following modifications as detailed in my Aug 3. post
Currently we have these:
Add Screen-Off-On-Leave Feature to gnome-control-center
We are planning a github release for a separate app for this soon, but still with screen off animation.
We also have modifications ready to utilize the above 2 modifications to screenshield and gsettings schema, for removal of screen off animation, but will post it later after the github release.
@felipeborges Thanks for your comment ! No , we have not considered it as we can use sysfs directly . Also , since the functionality is GUI based and we can use it directly in GNOME . Is it recommended to check it ?
It seems iio-sensor-proxy already handles these sensors.
We likely don’t want to handle the sensors directly in the desktop side, because as the list of support devices grow, we start accumulating specific quirks and workaround for each. GNOME Shell/Settings is not the best place to start handling device specifics such as reading and parsing sysfs files.
In iio-sensor-proxy we have means to annotate, sanitize, and filter a bunch of stuff as the list of devices grow. It exposes the devices over DBus, so GNOME Settings and the Shell could support a feature depending on it easily. This also allows other tools and desktop environments to share the device detection code.
I like the use of an extension for the proof of concept, but the ultimate goal of this work should be to land it in GNOME Shell (if its maintainer accept it). We don’t want to support a gsetting schema and have a UI in GNOME Settings for something that depends on a extension. The extension is a good way to test/prototype the feature.
We are checking iio-sensor-proxy now as it seems for sensor we need some modification to handle parameter .
Also, we will raise this as feature request in GNOME shell to get feedback from maintainer , Although, we are not sure how UI will be supported in GNOME shell and also it needs to poll current settings of human presence and distance for this feature , maybe via DBUS using iio-sensor-proxy .
Although, we are not sure how UI will be supported in GNOME shell and also it needs to poll current settings of human presence and distance for this feature , maybe via DBUS using iio-sensor-proxy .
GNOME Shell/mutter already use iio-sensor-proxy for the automatic rotation of devices with accelerometer, so the dbus interface is already there and being used. So it should be easier to add this feature since you won’t be adding a new dependency (it is already there).
It seems that the iio-sensor-proxy “HasProximity” and “ProximityNear” properties might do what you need. You would use “HasProximity” to detect whether a sensor is available, and then “ProximityNear” to see if a person is near the sensor (should show or hide the shield accordingly).
iio-sensor-proxy doesn’t expose properties for configuring the distance for the proximity detection. This might be worth asking the developer. If they think this is something worth exposing rather than relying on their defaults.
The “turn off the screen time” setting would be something on the GNOME side.
Thank you for your comments and sharing information !
In sensor for HPD , we can see sysfs attribute “in_proximity0_raw” (which tells Human is detected) and “in_proximity1_raw” (which tells proximity distance) but this seems there is difference in proximity sensor of HPD and others. So , i will discuss this in iio-sensor-proxy gitlab as well .
As of now , “HasProximity“ is showing false and also there is no sysfs of “ProximityNear“ i.e “in_proximity_near_level“ on my HPD supported machine . however , data from “in_proximity0_raw” and “in_proximity1_raw” is available . I will check it further.
p.s.: I have been playing around with this feature but I have no device with proximity sensors. If anyone is interested, I’m using a simple python script to mock it iio-sensor-proxy ProximityNear DBus service mock ($7304) · Snippets · GitLab I know I could have used pydbusmock. I will probably write a cleaner version with it.
