[BUG/FIX] Cursor invisible when using Webtop (Wayland) behind HAProxy Reverse Proxy

[qwrty-ftw]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When accessing the Webtop container through an HAProxy reverse proxy (SSL Offloading), the mouse cursor is completely invisible, even though clicks are registered. The cursor is visible when bypassing the proxy (local IP access).

Expected Behavior

Root Cause:
By default, the Wayland compositor (labwc / smithay) attempts to use hardware cursor planes. When the stream is re-encoded or proxied through a WebSocket tunnel handled by a reverse proxy, the hardware layer of the cursor is not captured in the video frame, making it invisible to the client.

The Fix:
Adding the environment variable WLR_NO_HARDWARE_CURSORS=1 forces the compositor to use software-based cursor rendering, which ensures the cursor is drawn directly into the framebuffer and sent through the stream.
Without that fix, cursor was render only on Gamemode with fullscreen.

Steps To Reproduce

Setup a Webtop container with PIXELFLUX_WAYLAND=true.
Configure HAProxy to handle SSL and proxy the traffic to the container (Port 3000).
Access the Webtop via the public domain.
Observe that the mouse cursor is missing.

Environment

OS: Debian Stable
Image: lscr.io/linuxserver/webtop:latest and amd64-ubuntu-xfce
Display Protocol: Wayland (PIXELFLUX_WAYLAND=true)
Reverse Proxy: HAProxy (running on Host)
Browser: Chromium Webrowser (not tested with Firefox)

CPU architecture

x86-64

Docker creation

---
services:
  webtop:
    image: lscr.io/linuxserver/webtop:amd64-ubuntu-xfce
    container_name: webtop
    network_mode: host
    devices:
      - /dev/dri:/dev/dri
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
      - PIXELFLUX_WAYLAND=true
      - DRINODE=/dev/dri/renderD128
      - DRI_NODE=/dev/dri/renderD128
      - CUSTOM_WS_PORT=8093
      - CUSTOM_PORT=3000
      - CUSTOM_HTTPS_PORT=3001
      - TITLE=Webtop
      - DISABLE_IPV6=TRUE
      - SUBFOLDER=/
      - CUSTOM_USER=xxxxxxxxxx
      - PASSWORD=xxxxxxxxx
      - WLR_NO_HARDWARE_CURSORS=1
    volumes:
      - /opt/docker/webtop/config:/config
      - /var/run/docker.sock:/var/run/docker.sock
    shm_size: "1gb"
    restart: unless-stopped

Additional Notes for Proxy Users:
For HAProxy users, the following backend settings were also necessary to ensure smooth input/output:

backend webtop
    mode http
    timeout tunnel 1h
    option http-no-delay
    no option http-buffer-request
    http-request set-header Upgrade websocket if { hdr(Upgrade) -i WebSocket }
    http-request set-header Connection Upgrade if { hdr(Upgrade) -i WebSocket }
    server webtop 127.0.0.1:3000 check

I hope this helps others facing the same issue with Wayland-based Webtops behind proxies!

Question / Technical Inquiry:
Is this behavior expected, and is there a "cleaner" way to handle hardware cursors through a proxy?
While WLR_NO_HARDWARE_CURSORS=1 works, it disables hardware acceleration for the pointer, which might increase CPU overhead. I noticed that:

The issue only occurs when the stream is proxied (HAProxy).
Direct access to the container (IP:Port) sometimes manages to display the cursor even without this flag (depending on the browser).

Questions for the maintainers:
Is there a specific KasmVNC or Labwc configuration that could "flatten" the hardware cursor plane into the primary buffer without disabling hardware cursors entirely?

Could this be related to how selkies-gstreamer or KasmVNC captures the Wayland output?

Are there specific Permissions-Policy or Feature-Policy headers that should be passed by the reverse proxy to allow the browser to better handle the hardware pointer lock/overlay?

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[qwrty-ftw]

I finally managed to get a perfectly smooth experience with Hardware Acceleration (VAAPI) working on an Intel iGPU (i915/iHD).
If you are experiencing "cursor floating" or "VAProfile not supported" errors, here is what worked for me.

The Context
The default Alpine image had issues with cursor lag/floating for me. Switching to the Ubuntu-KDE image (amd64-ubuntu-kde) significantly improved window management and overall fluidity.

Note on Performance:
Interestingly, even before I got VAAPI (Hardware Encoding) working, the Ubuntu-KDE image was already significantly more fluid than the Alpine/XFCE version.
Even with CPU encoding, the mouse responsiveness and window animations felt much smoother.
This is likely due to how KWin (KDE's compositor) handles frame delivery compared to XFCE.
So, if you're struggling with lag, switching to the KDE image is already a huge win, even before you fix the GPU drivers.

1. Custom Dockerfile
   The base Ubuntu image might lack the non-free Intel drivers required for encoding. I used this Dockerfile to bake them in:

Dockerfile

FROM lscr.io/linuxserver/webtop:amd64-ubuntu-kde
RUN apt-get update && \
    apt-get install -y intel-media-va-driver-non-free vainfo intel-gpu-tools && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*

2. Optimized Docker Compose
   The key was forcing the iHD driver and using the specific Selkies variables to fix the cursor lag.

docker-compose.yml

---
services:
  webtop:
    build:
      context: .
      network: host
    container_name: webtop
    network_mode: host
    devices:
      - /dev/dri:/dev/dri
    group_add:
      - "140" #render group
      - "44"  #video group
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Paris
      - PIXELFLUX_WAYLAND=true
      - DRINODE=/dev/dri/renderD128
      - DRI_NODE=/dev/dri/renderD128
      - CUSTOM_WS_PORT=8093
      - CUSTOM_PORT=3000
      - CUSTOM_HTTPS_PORT=3001
      - TITLE=Webtop
      - DISABLE_IPV6=TRUE
      - SUBFOLDER=/
      - CUSTOM_USER=
      - PASSWORD=
      - WLR_NO_HARDWARE_CURSORS=1
      - LIBVA_DRIVER_NAME=iHD
      - LIBVA_DRIVERS_PATH=/usr/lib/x86_64-linux-gnu/dri
      - SELKIES_USE_BROWSER_CURSORS=True
      - SELKIES_H264_STREAMING_MODE=True
      - KASMVNC_VAAPI_OPTS=low_power=1
    security_opt:
     - seccomp:unconfined
    cap_add:
      - SYS_ADMIN
      - SYS_RAWIO
    volumes:
      - /opt/docker/webtop/config:/config
      - /var/run/docker.sock:/var/run/docker.sock
      - /dev/shm:/dev/shm
    shm_size: "1gb"
    restart: unless-stopped

3. Verification
   You can verify that the GPU is actually transcoding by running this on the host:
   intel_gpu_top
   Look for activity in the Video engine section while moving windows or watching a video.
   Container logs show that the VAAPI Encoder initialized successfully

The "floating" sensation is gone thanks to SELKIES_USE_BROWSER_CURSORS=True and the VAAPI Zero-Copy path being correctly initialized.
Hope this helps!

[thelamer]

If anyone reads this thread I do not recommend using WLR_NO_HARDWARE_CURSORS=1 that is not a solution to anything.

You can render the cursor server side using the gaming mode if you want.

The cursors are sent as websockets messages specifically as base64 encoded json blobs that are pngs.

If your proxy solution blocks this whatever this is is not the solution.

Here is a base command that works great: (well outside of xfce on wayland still being beta)

Intel/AMD

docker run --rm -it \
  --shm-size=1gb \
  -p 3001:3001 \
  --device /dev/dri:/dev/dri \
  -e AUTO_GPU=true \
  -e PIXELFLU_WAYLAND=true \
  linuxserver/webtop:ubuntu-xfce bash

Nvidia

docker run --rm -it \
  --shm-size=1gb \
  -p 3001:3001 \
  --runtime nvidia \
  --gpus all \
  -e AUTO_GPU=true \
  -e PIXELFLU_WAYLAND=true \
  linuxserver/webtop:ubuntu-xfce bash

Software

docker run --rm -it \
  --shm-size=1gb \
  -p 3001:3001 \
  -e PIXELFLU_WAYLAND=true \
  linuxserver/webtop:ubuntu-xfce bash