KDE KRDP Bug Report
Title: KRDP 6.7.0 fails to connect due to PAM privileges, FreeRDP VAAPI crashes on unsupported GPUs, and KPipeWire fallback failures

Component: krdp / kpipewire Version: Plasma 6.7.0, FreeRDP 3.27.1 OS: Arch Linux (Wayland)

Summary
A recent system update to Plasma 6.7.0 and FreeRDP 3.27.1 completely breaks KRDP on older hardware (Intel Sandy Bridge / No H.264 hardware encoding). This is a multi-layered failure spanning PAM authentication, FreeRDP hardware encoding crashes, and KPipeWire software fallback failures.

Issue 1: PAM Authentication Failure (NoNewPrivileges)
KRDP runs as a systemd user service. When connecting using System User Authentication, pam_unix attempts to read /etc/shadow but fails to drop privileges with: pam_unix(login:account): setuid failed: Operation not permitted pam_authenticate failure: Authentication service cannot retrieve authentication info Workaround: Injecting NoNewPrivileges=false into app-org.kde.krdpserver.service.d/override.conf resolves the PAM error.

Issue 2: FreeRDP VAAPI Hard Crash
After bypassing the auth bug, FreeRDP (built with WITH_VAAPI=ON) attempts to initialize a hardware H.264 encoder on a Sandy Bridge GPU that only supports decoding. Instead of gracefully falling back to software encoding, it hard-crashes the socket connection: VAAPI: Failed to initialize display VAAPI: current session render node "/dev/dri/renderD128" does not support H264 encoding BIO_should_retry returned an error: error:80000020:system library::Broken pipe Workaround: Downgrading freerdp to 3.22.0-2 prevents the hard crash and allows the connection to stay open.

Issue 3: KPipeWire Software Encoder Fallback Failure
Even with a stable FreeRDP version, the stream returns a black screen (0 FPS). The KPipeWire fallback fails to automatically provide frames. Workaround: Manually injecting Environment=KPIPEWIRE_FORCE_ENCODER=libx264 into the systemd service forces the software encoder to work correctly and stream the desktop.

Issue 4: xdg-desktop-portal-kde Locale Bug
The screen-sharing portal service fails D-Bus registration if started by systemd in a non-UTF-8 environment: Detected locale "C" with character encoding "ANSI_X3.4-1968", which is not UTF-8. Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID") Workaround: Injecting LANG=en_US.UTF-8 into the systemd environment fixes the portal negotiation.

Expected Behavior
The KRDP systemd service should have the correct privileges configured to allow pam_unix to authenticate system users.
FreeRDP/KRDP should gracefully fall back to software encoding when the VAAPI driver reports does not support H264 encoding, without dropping the TCP connection.
KPipeWire should automatically select a functional software encoder (like libx264) if hardware acceleration is physically unavailable or fails to initialize.