Does this PR prevent the input leap client from blanking?

Mind the issue in #1699 is fixed by flatpak/xdg-desktop-portal#1128 which was merged to xdg-desktop-portal for 1.18.1.

Maybe this PR should be closed?

I would be against preventing blanking the screen. I do not always have input in the input leap client and displays consume a lot of energy.

This PR should be left open, and a configuration setting for inhibiting blanking.

@shymega Even when blanking the RemoteDesktop session is kept nowadays (even though from jadahl comment in #1707 (comment) I believe it is or at least was supposed not to by design).

But from whot comments to get automatic reconnect when RemoteDesktop is closed inhibiting the blanking would be required #1707 (comment) . Though I did not understand if the reconnect can happen during the screen blanking/lock screen or if one has to get the input leap client to first get out of blanking/screen locking before the code would do the auto reconnect (which in this case still requires interaction on the input leap client).

Though I did not understand if the reconnect can happen during the screen blanking/lock screen or if one has to get the input leap client to first get out of blanking/screen locking before the code would do the auto reconnect

We lose the session as soon as the screen lock/blank kicks in (doesn't matter if automatic screen lock is enabled in the Privacy settings) and we cannot create a session while the screen is locked. So right now with #1705 we can only restore the session after hitting a key on the local keyboard (and manually logging in if locking is enabled). That's with Fedora 39, GNOME 45.

@whot I am not sure I understand what you mean by "we lose the session as soon as the screen lock/blank".
Right now I can screen lock the client or have the screen of the client blank without losing my session.
When locked I can even unblank it and enter the password from the server mouse and keyboard.
This is with input leap 08d43e7,
Gnome Shell 45.3 (with the triple buffering patchset)
Mutter 45.3
libei1/libeis 1.2.0
libportal1 0.7.1 with the patch for InputCapture support (but not released with these patches so unlikely to be included in Debian until then)
xdg-desktop-portal-gnome 45.1-3
xdg-desktop-portal 1.18.2-1
All are build as Debian packages.

This might be an unwanted behavior but it works for a few months.

I mean I can even lock the screen of the server and move the mouse from the screen-locked input leap server to the input leap client.

When locked I can even unblank it and enter the password from the server mouse and keyboard.

unless this changed recently this was definitely not the behaviour when I tested - as soon as mutter locks the screen the RemoteDesktop session was closed and inputleap had to create a new session (which wasn't possible until unlocked).

I also experienced the behavior you described back in October when I reported this issue.

I believe the libportal side of the RemoteDesktop persistence might have given me the behavior I currently experience which is fine to me but might not be wanted as is (ie without this PR included to enable it from input-leap).

Out of the test code-related patches I have these patches added in the Debian package above 0.7.1:

0001-remote-Add-API-to-allow-for-persistence-on-RemoteDes.patch.txt
0002-Move-the-generic-session-declarations-to-a-separate-.patch.txt
0003-session-implement-a-generic-close-closed-handling.patch.txt
0004-Implement-support-for-the-InputCapture-portal.patch.txt

fwiw, the remote desktop persistence changes only help with getting the session back (without the permissions dialog) after unlocking, we still lose the client session and have to use a local keyboard to log back in. But once the mutter session is unlocked we can re-connect to it using the persistence tokens.

Do you have screen blank or screen lock configured? If the former but not the latter that'd explain it?

@whot I pressed Super+L to lock the client screen from the server keyboard.

I only have auto blanking, not auto-locking otherwise though it should not change the behavior if input still works when I trigger it manually.
I do not lose the client session when blanking and/or locking the screen for a few months.

I believe requesting authorization each time you start the input leap client or server defeats a lot of use cases of synergy/barrier/input-leap. If you can easily use the client input devices to ack the authorization then you probably don't need to use remote device input that much.

The multi-screen policy of Gnome is if there is an external monitor and the laptop lid is closed consider that the user does not want to suspend because the laptop is docked. This is my case, except I do not want to plug an external keyboard and mouse into the dock but use the input-leap server ones. If the laptop lid is closed there is no way to access the laptop keyboard and clickpad.
There are laptop stands that cover the laptop keyboard. If input-leap requires the use of inputs from the laptop, one will have to plug in an external keyboard and mouse ... thus I see no point in unplugging them afterward to use the ones from the input leap server desktop next to it (to have to replug them back each time the screen blank).

To me, input-leap needs a policy setting that authorizes it once and for all until this setting is turned off.
Requiring local input devices to provide the authorization (while a policy can be set via ssh) to allow to use remote inputs instead of local inputs seems weird to me (especially if we cannot remove these local inputs as we might need them at a random time to reauthorize the remote inputs when the screen blanks).
If we could authorize the remotedesktop portal via ssh that would provide a way around, though that would be cumbersome to do it each time.

I also really want to blank my screen... 50W minimum consumption while a screen is on is a lot, especially since if I stop the screen blanking for the external monitor it will also cut blanking for the internal display of the laptop).