This eases up doing additional checks on the buffer. It will also help
in the future supporting fully hardware accelerated setups, as such
setups require the usage of a common buffer type.

As a side effect, this change also avoids a crash, when a PipeWire
buffer could not be allocated. Currently, gnome-remote-desktop hits an
assertion, as the buffer type could not be determined, when dequeuing
this buffer. But now, gnome-remote-desktop avoids in such situation
dequeuing any buffers, and just closes the remote desktop session with
an error.

Instead of mapping each PipeWire buffer for every frame again and again,
simply map it once it was added.
This will not only avoid any possible overhead here, but also help a
future implementation of support for fully hardware accelerated setups,
in which case it won't be desired to do unnecessary buffer copies, but
to keep PipeWire buffers mapped as long as their content is needed.

Building gnome-remote-desktop without the RDP backend currently fails
due to running into an error that the polkit dependency could not be
found.
The respective pkgconfig is only looked up, when building
gnome-remote-desktop with the RDP backend, as it is only needed there
(for the gnome-remote-desktop-enable-service helper).

To fix this issue, only build the gnome-remote-desktop-enable-service
utility, when the RDP backend was enabled.
Also, move the toggle_systemd_unit() function into the HAVE_RDP scope,
as otherwise a compiler warning appears, that this function is unused,
when the RDP backend is disabled.

Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/207

The graphical remote login feature requires systemd, but this can be
made optional so the usual remote assistance sessions can still work.

Closes: https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/issues/190

When daemon-system disappears, keep the logout behaviour because the new
daemon-system can't communicate with the old daemon-handover.

Don't logout when handover start fails. This failure should not be
critical, this allows to keep the session.

When disconnecting from a headless user session, it will now not be
destroyed. Instead, this session is now orphan.
For that session, there's a lingering remote_client at daemon-system.

1. When on a new connection, there's a new remote_client, and a new
   RemoteDisplay (greeter) linked to it.
2. A successful authentication happens to open this orphan session.
3. GDM updates the RemoteDisplay of the orphan session with the new
   remote_client id.
4. The daemon-system receives that update. It knows that for that
   RemoteDisplay there is an old remote_client. And with this new
   remote_client id it knows there is a new remote_client.
5. The handover iface from the old remote_client is unregistered and
   the remote_client is removed.
6. A new handover is registered to communicate with the orphan session
   again, but this time from this new remote_client.
   Now the new remote_client has handover_src connected to the greeter
   session and handover_dst connected to the orphan session.
7. On handover_dst, the new signal "RestartHandover" is emitted to make
   the daemon-handover at the orphan session start again the handover
   and get the RDP client.

Now there can be an orphan/lingering headless session, with a
daemon-handover attached to it. It is possible to continue to use that
session. To do that, the daemon-system will emit on the correspondent
handover iface the "RestartHandover" signal and a new RDP client will
end up on this session again.

In headless sessions, the remote desktop client determines the monitor
configuration. If there are multiple clients, they would clash with each
other, and no one of them would be able to offer a usable session.
Hence, stop the existing session, if there is one, before handling the
new client.

There can be a situation, where the handover service is stopped and
after a while started again. In that case, the RDP client is
disconnected and when the daemon-handover is started again, a handover
will be started and that can fail.

Do not logout on that failure case. Instead, let the daemon-handover
wait for a future handover.

At the moment, every subcommand is expected to have a predefined,
fixed number of arguments.

We need to lighten this expectation a bit to support subcommands
that take data from either the command line or optionally the stdin.

That is necessary to support more securely passing credentials
(which will be implemented in a future commit).

This commit, modifies the argument processing code to support multiple
entries for the same subcommand, each entry with its separate allowed
number of arguments. In this way, e.g., "set-credentials" will be able
to support 0, 1 or 2 arguments.

Right now the VNC password and RDP username and password need
to be passed to grdctl on the command line.

That isn't ideal and it would useful to be able to pass them
directly via the terminal as well.

This commit adds some logic to do just that: read the values
from the standard input if they aren't passed in on the command line.

This new object uses the org.freedesktop.impl.portal.Access dbus
interface exposed by gnome-shell to display a dialog, basically adding a
new way to inform the user with this modal dialog. Only one dialog can
be displayed at the same time.
When calling the open() method and there is already one dialog being
displayed, it will be closed and the new one will be displayed instead.

Now when the connection is insecure, the handover daemon now tries to
display a dialog instead of a notification.

Keep using the prompt as fallback, however. This is needed for cases,
where displaying a dialog is not possible due to gnome-remote-desktop
not running inside gnome-shell (e.g. when using gnome-kiosk).

The dialog title wasn't following the HIG. Fix this by capitalizing the
title correctly.
Do the same in the notification message.

Apparently, gettext looks for such comment before a function call, so
move the translator comments right before that to ensure they are
visible in the respective .po files.

g_unix_fd_list_get() requires the file descriptor list and index to be
valid. If they are invalid (e.g. index is out of range), it returns -1
as fd, but the call does not set the error.
Thus, gnome-remote-desktop crashes, when attempting to print the error
message to the journal.

Fix this issue by simply checking the file descriptor index before
attempting to acquire the file descriptor itself.

Fixes: https://errors.ubuntu.com/problem/e7b4b4292726923600ac46a21ef9b94f868951f3

g_unix_fd_list_get() requires the file descriptor list and index to be
valid. If they are invalid (e.g. index is out of range), it returns -1
as fd, but the call does not set the error.
Thus, gnome-remote-desktop crashes, when attempting to print the error
message to the journal.

Fix this issue by simply checking the file descriptor index before
attempting to acquire the file descriptor itself.

g_unix_fd_list_get() requires the file descriptor list and index to be
valid. If they are invalid (e.g. index is out of range), it returns -1
as fd, but the call does not set the error.
Thus, gnome-remote-desktop crashes, when attempting to print the error
message to the journal.

Fix this issue by simply checking the file descriptor index before
attempting to acquire the file descriptor itself.

Commit [0] already deprecated the legacy graphics path and stated the
reasons for it. Almost two years ago, all major popular clients already
supported the graphics pipeline (xfreerdp, Remmina, mstsc, etc.).
With the release of gnome-remote-desktop-44, the legacy path could then
only be used, when a specific debug flag was set, and even when the
legacy graphics path was used, it could only be used for the Remote
Assistance scenario, where the primary monitor is mirrored, as it has
lots of limitations:

- The width and height of the desktop size MUST be a multiple of 4
  (making the legacy graphics path unsuitable for the usage of headless
  sessions, where arbitrary resolutions are used).
- The bitstream size of the NSC codec is unpredictable and thus it
  cannot be reliably used for graphics handling in the legacy path,
  where graphics PDUs have to be split on a higher level.
- The RFX codec in the legacy path has the best code and usability
  quality, but it is there only suitable for single-monitor scenarios.
- The raw bitmap path produces bitstreams, that are gigantic in size,
  and it is very slow (max 10-11 FPS in testing).
- Changing the desktop size is and multi-monitor config is more complex,
  as the legacy graphics path requires the usage of the
  deactivation-reactivation sequence.

Since the usage scenario for the legacy path is very limited, especially
now with the support of headless sessions, remove the already deprecated
legacy path.
This should also ease up transitioning the codebase of
gnome-remote-desktop to a fully hardware accelerated solution.

[0]: 35dfaaad

When resizing the buffers of the buffer pool fails, or resize-surface
operation of the damage detector fails, then
grd_session_rdp_notify_error() implicitly disallows any encoding
operation, because it unsets the RDP_PEER_ACTIVATED flag.
In order to be able to move any encoding operation out of session-rdp.c,
this behaviour needs to be changed.

To handle this situation outside of session-rdp.c, simply set the
dequeuing_disallowed flag in the PW stream class. This implicitly avoids
any calls to encoding operations. The reason for this is, because a PW
buffer needs to be dequeued at some point in the future, after the
format-change event happened, but this flag prevents that.

Add an API to the renderer, which simply calls
grd_rdp_graphics_pipeline_refresh_gfx(). This is necessary in order to
be able to move any rendering operations out of session-rdp.c.

This API will later be used by the surface renderer.

With all helpers in place now, remove any last rendering handling from
session-rdp.c.
The surface renderer is the "driving force" behind the rendering
operations for a surface. So, move the related bits there.

Semantically, this change clears session-rdp.c a little bit from any
unrelated parts and makes its code more readable.

The surface renderer already handles the case, where a render operation
fails, so there is no need to do it in the calls, that the surface
renderer initiates.

This increases utils modularity. A different binary can now use the
utils without pulling in the RDP/VNC server dependencies.

This allows a future ctl-dbus binary to use that functionality too.

Also, update unit_is_active function to get the unit active status
instead. This keeps the style with other similar functions with respect
to the returned handle and errors.

grd-configuration allows to inspect and configure the RDP server of the
system daemon. This is done through the dbus interface
"org.gnome.RemoteDesktop.Configuration.Rdp.Server", at the
"org.gnome.RemoteDesktop.Configuration" name.

Instead of the "org.gnome.RemoteDesktop.Rdp.Server" iface, use the
"org.gnome.RemoteDesktop.Configuration.Rdp.Server" iface to configure
the system daemon.

Move for this the methods "Enable", "Disable", "GetCredentials",
"SetCredentials" and "ImportCertificate" to the respective iface.
Also, move the polkit authentication as well.
The required properties are now also available on this interface too.

gnome-remote-desktop-configuration is a systemd system service running
as the gnome-remote-desktop user.
It can be autostarted on dbus on demand. Do not autostart the system
daemon on demand anymore.

This allows to get the systemd unit proxy independently, allowing to do
other things apart from getting the active state.

This will later be used to connect to the proxy signal to know when the
active state property changes.

Previously the rdp-enabled property was only in sync through the
settings iface, but if the systemd unit was changed it wouldn't get
updated.

Update the rdp-enabled property, when the systemd units status changes,
to fix this issue.

The control-center only updates the remote login config info when
setting or getting the config through the dbus iface of the
gnome-remote-desktop-configuration-daemon.

The gnome-remote-desktop-configuration-daemon is stopped after a
timeout. If any configuration was done without the
configuration daemon (e.g. grdctl), the configuration daemon isn't
autostarted, not updating control-center.

To fix this, when the configuration happens through systemd or grdctl,
let the system daemon simply start the configuration daemon. As a
consequence, it updates control-center.

prompt_for_input() is required for both backends, not just the RDP
backend.

In RDP, every Client X.224 Connection Request PDU MUST contain an X.224
Class 0 Connection Request transport protocol data unit (TPDU).
This is also usually the case, but a malicious client could also simply
omit it, in which case gnome-remote-desktop currently crashes, because
Stream_New() requires a valid passed length value (> 0) and thus hits an
assertion.
Without the assertion, gnome-remote-desktop would do an out-of-bounds
buffer read.

To fix these issues, simply check the x224Crq TPDU length before trying
to allocate memory for the peek operation.

https://errors.ubuntu.com/problem/8d010a6d70c7f77f763c787bcb99372c942fc1c8