[BUG] Cursor rendering lost on desktop browsers after tab sleep - restored only by mobile client reconnect (Wayland/NVIDIA)

[corvidica]

Current Behavior

When using the webtop in Wayland mode (PIXELFLUX_WAYLAND=true) with NVIDIA GPU passthrough, the mouse cursor becomes invisible on all desktop browsers after the browser tab goes to sleep or is backgrounded. Cursor input continues to function correctly (clicks, hover states, interactions all work), but the cursor is not rendered visually.

The issue persists across:

• Multiple desktop browsers (Microsoft Edge, Firefox)
• Incognito/private windows
• Changing stream resolution or quality settings in the Selkies sidebar
• Opening a new browser session on the same desktop

The cursor is only restored by connecting from a mobile browser (tested: Microsoft Edge on iOS). Once the mobile client connects and disconnects, the cursor renders correctly again on all desktop browsers.

The cursor also will render and function normally while in 'Gaming Mode'. This acts as a work around, but this does not restore the cursor after exiting Gaming Mode.

Expected Behavior

The mouse cursor should remain visible after a browser tab goes to sleep or loses focus, and should be restorable without requiring a mobile client connection or full container restart.

Steps to Reproduce

1. Launch the webtop container in Wayland mode (PIXELFLUX_WAYLAND=true) with NVIDIA GPU
2. Launch webtop w
3. Connect from a desktop browser (Edge or Firefox)
4. Allow the browser tab to go to sleep / background the tab for an extended period
5. Return to the tab — cursor is invisible but input still functions
6. Open the webtop URL in a mobile browser (e.g. Edge on iOS)
7. Observe cursor is restored on the mobile session
8. Switch back to the desktop browser — cursor now renders correctly, but the cursor appearance differs from the original (e.g. changes cursor theme or type (cursor and not a pointer)), suggesting the mobile connection triggers a cursor reinitialization rather than restoring the previous cursor state.

Environment

• Image: lscr.io/linuxserver/webtop:ubuntu-kde (custom Dockerfile build)
• Host OS: Ubuntu 6.8.0-101 x86_64
• Docker version: Docker version 29.2.1
• GPU: NVIDIA (passthrough via deploy.resources.reservations.devices)
• Desktop Environment: KDE Plasma (Wayland or CPU Only)
• Streaming backend: Selkies (svc-selkies)
• Client browsers affected: Microsoft Edge (desktop), Firefox (desktop)
• Client browser NOT affected: Microsoft Edge (iOS)

Relevant Environment Variables

Wayland

PIXELFLUX_WAYLAND=true
DRINODE=/dev/dri/renderD128
DRI_NODE=/dev/dri/renderD128
NVIDIA_VISIBLE_DEVICES=all
NVIDIA_DRIVER_CAPABILITIES=all
WLR_NO_HARDWARE_CURSORS=1

CPU

PIXELFLUX_WAYLAND=true
WLR_NO_HARDWARE_CURSORS=1
WLR_RENDERER=pixman

Additional Context

• WLR_NO_HARDWARE_CURSORS=1 no change
• Enabling CSS cursors via the Selkies sidebar (use_browser_cursors) actually triggers the issue immediately rather than fixing it
• Restarting the container restores the cursor, suggesting Selkies session state is not fully reset on reconnect
• The fact that a mobile client connection restores cursor rendering for all subsequent desktop clients suggests the mobile connection triggers a cursor stream reinitialization path that desktop reconnects do not
• Cursor input (clicks, hover states) continues to function correctly throughout — this is purely a rendering issue

[corvidica]

Quick Update: Selkies 'Gaming Mode' will render the cursor correctly. Existing Gaming Mode doesn't not retain the cursor.

[corvidica]

Another update fwiw - i was able to reproduce this on a CPU only build. Seems like a simpler setup. Update description.

[ehfd]

@thelamer

[corvidica]

My two cents of this issue is that there is some race condition in in the selkies START_VIDEO that occurs when the browser is activated from a sleeping state. The server responds with a success message, but never actually starts the pipeline. In comparison between my good and bad states i see an extra entry in the browser logs for index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: true} after index-23cDh2Vf.js:271 Tab is visible again, re-acquiring Wake Lock.. That doesn't happen on the bad state. It goes directly to the next entry.

• Client sends STOP_VIDEO on tab hide — server stops pipeline correctly
• Tab becomes visible — client sends START_VIDEO
• Server sends back pipelineStatusUpdate: video: true indicating success
• Server never actually starts the pipeline — no capture loop, no encoder init in logs
• Client believes stream is active; server is silently in a broken state

the 'good' state - eg. the browser is inactive and then becomes active again.
Container Logs:

webtop-wayland  | INFO:data_websocket:Received STOP_VIDEO for 'primary'. Stopping stream.
webtop-wayland  | INFO:data_websocket:Stopping all streams for display 'primary'...
webtop-wayland  | INFO:data_websocket:Successfully stopped all streams for display 'primary'.
webtop-wayland  | INFO:data_websocket:Video chunk sender for 'primary' cancelled.
webtop-wayland  | INFO:data_websocket:Video chunk sender for 'primary' finished.
webtop-wayland  | [Wayland] Capture loop stopped.
webtop-wayland  | INFO:data_websocket:Received START_VIDEO for 'primary'. Starting its stream.
webtop-wayland  | INFO:data_websocket:Found existing layout for 'primary'. Starting capture with: {'x': 0, 'y': 0, 'w': 2730, 'h': 1316}
webtop-wayland  | INFO:data_websocket:Preparing to start capture for display='primary': Res=2730x1316, Offset=0x0
webtop-wayland  | INFO:main:Parsed DRI node '/dev/dri/renderD128' to index 0.
webtop-wayland  | INFO:data_websocket:Registered Wayland cursor callback for 'primary'
webtop-wayland  | INFO:data_websocket:Video chunk sender started for display 'primary'.
webtop-wayland  | [Wayland] Encode Node Index: 0 | Driver: ../../../../../bus/pci/drivers/nvidia
webtop-wayland  | [Wayland] Nvidia Encoder detected. Initializing NVENC...
webtop-wayland  | [NVENC] Initializing...
webtop-wayland  | INFO:data_websocket:SUCCESS: Capture started for 'primary'.
webtop-wayland  | [NVENC] Found 1 CUDA devices:
webtop-wayland  | [NVENC]   Device 0: Tesla P4
webtop-wayland  | [NVENC] Bound to CUDA device via PCI Bus ID: 0000:06:10.0
webtop-wayland  | [NVENC] Initialized successfully (4:4:4 mode: false).
webtop-wayland  | [Wayland] NVENC Encoder initialized successfully.
webtop-wayland  | [Wayland] Decision: Zero-Copy path active.
webtop-wayland  | Stream settings active -> Res: 2730x1316 | FPS: 60.0 | Stripes: 1 | Mode: H264 (NVENC) FullFrame Streaming | CRF: 25 | PaintOver CRF: 18 (Burst: 5f) | Colorspace: I420 (Limited Range) | Damage Thresh: 10f | Damage Dur: 20f

browser console output:

Screen Wake Lock was released automatically.
index-23cDh2Vf.js:271 Tab is hidden, stopping video pipeline if active.
index-23cDh2Vf.js:271 Tab hidden: Sent STOP_VIDEO. Clearing canvas visually. Server will send PIPELINE_RESETTING for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: false}
index-23cDh2Vf.js:352 Client: Received VIDEO_STOPPED. Updating isVideoPipelineActive=false. Expecting PIPELINE_RESETTING from server for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: false}
index-23cDh2Vf.js:271 Tab is visible, requesting video pipeline start if it was inactive.
index-23cDh2Vf.js:271 Tab is visible again, re-acquiring Wake Lock.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: true}
index-23cDh2Vf.js:271 Screen Wake Lock is active.
index-23cDh2Vf.js:271 Tab visible: Sent START_VIDEO. Clearing canvas visually. Server will send PIPELINE_RESETTING for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: true}

Bad State: client browser tab is asleep then reactivated.
Container Logs:

webtop-wayland  | INFO:data_websocket:Received STOP_VIDEO for 'primary'. Stopping stream.
webtop-wayland  | INFO:data_websocket:Stopping all streams for display 'primary'...
webtop-wayland  | INFO:data_websocket:Successfully stopped all streams for display 'primary'.
webtop-wayland  | INFO:data_websocket:Video chunk sender for 'primary' cancelled.
webtop-wayland  | INFO:data_websocket:Video chunk sender for 'primary' finished.
webtop-wayland  | [Wayland] Capture loop stopped.

browser console output:

Sent small clipboard text in single message.
index-23cDh2Vf.js:271 Sent clipboard text (from binary-enabled path) on focus via sendClipboardData
index-23cDh2Vf.js:271 Screen Wake Lock was released automatically.
index-23cDh2Vf.js:271 Tab is hidden, stopping video pipeline if active.
index-23cDh2Vf.js:271 Tab hidden: Sent STOP_VIDEO. Clearing canvas visually. Server will send PIPELINE_RESETTING for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: false}
index-23cDh2Vf.js:352 Client: Received VIDEO_STOPPED. Updating isVideoPipelineActive=false. Expecting PIPELINE_RESETTING from server for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: false}
index-23cDh2Vf.js:271 Tab is visible, requesting video pipeline start if it was inactive.
index-23cDh2Vf.js:271 Tab is visible again, re-acquiring Wake Lock.
index-23cDh2Vf.js:271 Screen Wake Lock is active.
index-23cDh2Vf.js:271 Tab visible: Sent START_VIDEO. Clearing canvas visually. Server will send PIPELINE_RESETTING for full state reset.
index-23cDh2Vf.js:271 Received pipelineStatusUpdate message: {type: 'pipelineStatusUpdate', video: true}

[corvidica]

Sorry to keep spamming this thread, but double checking the linuxserver.io documentation they have added a line about Kernel Parameter for Nvidia cards. Adding this into my docker host bootloader seems to have resolved the Selkies stability issue when using the GPU and Wayland. I have not tested the other CPU only test cases, but probably not worth it.

Putting it here just in case someone else runs into this incredibly specific issue.

https://docs.linuxserver.io/images/docker-webtop/#nvidia-proprietary-drivers