# NVENC never engages on physical-desktop session (Linux, 9.8.2) — nxcodec.bin stays on software encoding

## Summary

On two Fedora 44 machines with NVENC-capable NVIDIA GPUs, NoMachine 9.8.2 never uses the
hardware encoder for physical-desktop connections. `nvidia-smi` reports the encoder engine at
**0% and 0 encoder sessions** at all times, while `nxcodec.bin` consistently burns 15-32% of a
CPU core doing software encoding.

NVENC on the same machine is verifiably functional — `ffmpeg` drives the encoder engine to 88%
on demand. This appears to contradict KB article AR01T01151, which states GPU-accelerated video
encoding is "always used, where available, when connecting to the physical display... This is the
typical case of connections to the Enterprise Desktop or to the free edition of NoMachine."

## Environment

| | |
|---|---|
| NoMachine (server) | 9.8.2-2 x86_64, built Wed Jul 8 2026 |
| Subscription | type S, id None, period Unlimited |
| OS | Fedora Linux 44 (KDE Plasma Desktop Edition) |
| Kernel | 7.1.4-204.fc44.x86_64 |
| GPU | NVIDIA GeForce RTX 3050 6GB (GA107, 7th-gen NVENC) |
| NVIDIA driver | 610.43.03 |
| X server | xorg-x11-server-Xorg 21.1.24-1.fc44 |
| Desktop | KDE Plasma on X11 (SDDM autologin) |
| Session type | `physical-desktop` (shadow of X `:0`) |
| Client | NoMachine 9.8.2 on Linux, LAN connection |

Server config (defaults, verified):

```
EnableHardwareEncoding 1
EnableDisplayServerVideoCodec 1
EnableEGLCapture 1
```

Client: "Use hardware encoding" is enabled, codec set to H.264, frame rate 30.

## Observed behaviour

During an active, actively-repainting physical-desktop session:

```
$ nvidia-smi dmon -s u
# gpu     sm    mem    enc    dec    jpg    ofa
# Idx      %      %      %      %      %      %
    0     41     31      0      0      0      0
    0     40     27      0      0      0      0
    0     39     26      0      0      0      0

$ nvidia-smi --query-gpu=utilization.encoder,encoder.stats.sessionCount --format=csv
utilization.encoder [%], encoder.stats.sessionCount
0 %, 0
```

The `sm`/`mem` load is normal desktop rendering (compositing, browser, editor) — that part is
GPU-accelerated and healthy. Only the **`enc` engine is idle**.

Meanwhile CPU, at 3840x1080:

```
  PID USER      PR  NI    %CPU  COMMAND
20117 user       0 -20    34.2  nxnode.bin
22467 user       0 -20    32.3  nxcodec.bin
 1822 user      20   0    11.4  Xorg
```

`nxcodec.bin` at ~32% of a core is consistent with software encoding.

`xrestop` confirms `nxnode.bin` is the dominant X client, holding three full-screen buffers:

```
nxnode.bin (PID 20117):
  pixmap bytes : 49766400      (= 3840 x 1080 x 4 bytes x 3)
  shm segments : 1
```

## Proof that NVENC itself works

Same machine, same session, NVENC driven directly:

```
$ ffmpeg -f lavfi -i testsrc=size=1920x1080:rate=60 -frames:v 900 \
         -c:v h264_nvenc -preset p4 -f null -

frame=900 fps=293 q=30.0 speed=4.87x     (exit code 0)
```

Encoder engine during that run:

```
# gpu     sm    mem    enc    dec
    0     45     18     88      0     <- NVENC at 88%
    0     44     18     87      0
    0     10      3      0      0     <- back to 0 when ffmpeg exits
```

So the GPU, driver 610.43.03, `libnvidia-encode.so.1`, and the NVENC hardware are all fully
functional and reachable. `ldconfig -p` resolves `libnvidia-encode.so.1` and `libnvcuvid.so.1`
in `/lib64`, and `nxcodec.bin`'s `LD_LIBRARY_PATH` (`/usr/NX/lib:/usr/NX/lib/perl`) does not
suppress the system library cache.

## Configurations tested — `enc` was 0 in every one

Each was tested with a full session disconnect/reconnect so parameters would renegotiate:

1. Defaults (`DisplayServerVideoFrameRate 60`)
2. `DisplayServerVideoFrameRate 30`
3. `DisplayServerVideoCodec h264` pinned server-side (with `EnableDisplayServerVideoCodec 1`)
4. `EnableEGLCapture 0`
5. Client-side H.264 + 30 fps, after a full client reboot
6. Single monitor at exactly **1920x1080** (below the resolution threshold mentioned in AR10K00696)

Case 6 is worth highlighting: dropping from 3840x1080 to a single 1920x1080 head roughly halved
the CPU cost (`nxcodec.bin` 32.3% -> 15.6%, `nxnode.bin` 34.2% -> 14.9%), exactly proportional to
pixel count — but **NVENC still did not engage**. The session log confirmed
`Info: Using screen size 1920x1080.` So this is not the >1920x1080 VP8 fallback described in
AR10K00696.

A full `nxserver --restart` with `SessionLogLevel 7` in both `node.cfg` and `server.cfg` produced
**no encoder-related log lines at all** — no "hardware encoding enabled/disabled", no NVENC probe
result, no fallback message. That made local diagnosis impossible.

## Reproduced on a second machine

A second Fedora 44 box (also NVIDIA, also dual 1920x1080 = 3840x1080, also `physical-desktop`)
shows the same thing: `enc` 0, comparable `Xorg`/`nxcodec` CPU.

## Questions

1. Is hardware encoding expected to work for `physical-desktop` sessions on Linux in 9.8.2? KB
   AR01T01151 suggests yes, including for the free edition.
2. Is there a known incompatibility with NVIDIA driver branch 610.x?
3. Is there any way to make NoMachine log its encoder-selection decision (which encoder it probed,
   what it chose, and why)? `SessionLogLevel 7` logged nothing on this topic, which is the single
   biggest obstacle to diagnosing this locally.

Happy to provide full session logs, `nvidia-bug-report.sh` output, or run any diagnostic build.