Time ticking despite of TRACK_INACTIVE: False and locked screen

I have noticed that in my previous testing, but it is working the best it currently can :) I'll explain.

timekpr-next uses DE (gnome,kde,budgie,cinamon,...) agnostic standards / controls to work. The common thing nowadays is systemd, timekpr use it for everything related to users and sessions.
SessionIdleState You see in the logs, comes from login1 (systemd user / seat management thing) which seems to be broadly adopted. I have looked at its dbus methods a lot, there is nothing much else to check for idle state.
I guess every DE should set the state of session somewhat the same and from user perspective, screen is on or not while it's locked does not matter, it is still locked and he can not work. But as You discovered, once mouse is moved, session is not idle anymore. I do not know why exactly, but I guess techically it's not, because mouse was moved.

The only thing I imagine, is to try to connect to all possible screensaver or screenlock thing every DE provides, which frankly, is not the right way, but can be the only way currently to achieve the result at least for major players. KDE has its own thing, Gnome too, then comes the rest of multitude DEs with their own thing.
I hope I'm wrong and I'll check whether they all have something in common, maybe I can use that to improve things about locking. Previously I have checked this a little, was not on priority back then, but it seemed pretty diverse in screen locking.

I'll check, can't promise anything...

Thank you for prompt reply.

If I understood correctly, there are two different states: one for system (is Idle or not Idle), and other for user serssion (is active or not). I found (and that's in logs) that user session is active even when he locked screen. And it remains "active" until someone presses "Log as another user" button. After that, session becomes "online". I wrote this because you said that session is not idle since mouse moved -- but from perspective of my system, user session was active even when he locks the screen and it went blank; the only thing that changed is idle state of whole system. So, if no one cicks "Log as another user", the user's session is never becomes inactive, just system idle state changes (the system becomes "not idle" after mouse moved or key pressed).

So there probably is a bug in logind or other component of OS/systemd or something. It would be good to post bugreport on this (but I can't understand where to post It, and how to reproduce problem nore directly, not via timekpr; although I understand python and probably can write some test script on this). Ind even if that's not a bug, there probably will be some clarification.

Or, alternatively, there is another proper way to decide if user is active or not.

I agree that it is no good to check for different screensavers activity (but for some time it may do as workaround), especially when there is the "right" way.

Anyway, thank you, and I hope you'll find something on this case.

I have found a hackish not-a-good-but-rather-acceptable way to accomplish exactly what's needed. Yey :)

I'll see whether I can make this work in actual timekpr and let's see which DEs work. I'll let You know whether that works, but be prepared to install beta, as this will need more testing.

Good! I'll be happy to help.

Fine, it works for me, thank you!

P.S.
I absolutely agree with you on this: "screensaver detection is a client responsibility, thus can be faked by clever program user can write, but if user can write a piece of code that actually connects to timekpr DBUS, understand it's logic / verification requests, etc. and can fake results based on client / server interaction, maybe this user should not have timekpr enforced on him in the first place :)"

Thanks Eduards Bezverhijs, that solved my question.