Detect power events?

[chlohr]

Hello,
Is there a way (events?) to be notified when the screen is physically turned on and off?

Let's say I want to automatically activate the screen-lock when I physically turn off my screen. Is that possible? Does that make sense, or am I completely off base?

Thanks

[rockowitz]

First, let me apologize for not commenting earlier. Since your post isn't an issue (which it shouldn''t be) it was overlooked.

The answer is, unfortunately, sometimes. A lot of work on recent releases has gone into this area. Currently libddcutil has multiple algorithms for detecting display connection and disconnection ("watch-modes"). None are perfect. The primary one is watching for UDEV DRM change events. One issue is that for DVI and HDMI connected monitors power for the EDID comes from the video cable, so from UDEV's perspective nothing has changed. Even with a DP connection, UDEV does not necessarily emit a change event when the monitor is turned off, but then it emits two (for the turn on and turn off) when the monitor is turned on.

If you're up for some C programming your program could specify which watch-mode is used and register a callback function with libddcutil to be invoked when libddcutil detects a screen change event. In a script or e.g. python program, you could watch for UDEV events, or if running on KDE Plasma you could register for dbus signals from org.kde.KScreen.

[laur89]

Is there a good reason why x11 still defaults to xevents as opposed to udev?

[rockowitz]

Because watching for xevents is less imperfect than watching for UDEV events. I suspect, but have not confirmed, that X11 is more tightly integrated with the video drivers.

[laur89]

TIL. Are you aware of any user-space programs for listening said events, akin to xev is for input events?

[rockowitz]

By user-space I assume you mean command line program. xev -event randr reports screen change, i.e RRScreenChangeNotify, events. That's essentially what ddcutil does at the X11 API level.

[laur89]

Was looking into the same thing some time ago, but at least my monitors fail to trigger any udev events on power on/off.

Depending on what you want to accomplish, you might consider turning the logic around - monitor is switched off at screen-lock event. That's exactly what I ended up doing.

Right now I use xss-lock, and utilize its notifier_cmd hook to first dim the brightnesses down to 0, and upon notifier exit (either due to user input or locking command trigger), brightnesses are restored and then locking command either forces external displays to standby mode (D6 04) or switches them off (D6 05). Upon resume from lock state displays are switched on again (D6 01). All via magic of ddcutil.

And as xss is hooked also to suspend event, then all this happens also when the power button is pressed which locks the system and suspends.

This way the logic works IMHO better, as all external displays get switched off, regardless whether you have one or four of them.

And in this light it's beneficial if udev events are not emitted when displays are switched on or off. Makes it easier if drm change events are fired only on screen connections & disconnections when state reinitialization can be done. If ddcutil stopped detecting display that's still connected but merely switched off, it'd be detrimental as we might then fail to switch it back on via software.

Although it would make sense for power_supply subsystem events to be fired on power cycle, as opposed to drm.