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

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?

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

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.

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/*

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

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!

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 \
  --device /dev/nvidia-modeset \
  -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

I do not know what Reverse Proxy is used but when I use arch and ubuntu with KDE and wayland behind ingress (Traefik) on a k3s cluster I have no problems with the mouse cursor. By the way did you tried the CSS cursor option?

This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

Closing please retest head images. Xwayland mode (wayland with the DE running under an xwayland display) has cursor support now and X11 supports zero copy encoding.

Also was never able to replicate.

This issue is locked due to inactivity

Navigation Menu

Repository navigation

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

Is there an existing issue for this?

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

CPU architecture

Docker creation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Is there an existing issue for this?

Current Behavior

Expected Behavior

Steps To Reproduce

Environment

CPU architecture

Docker creation

Activity

github-actions commented on May 5, 2026

qwrty-ftw commented on May 6, 2026

thelamer commented on May 7, 2026

hgw77 commented on May 12, 2026

LinuxServer-CI commented on Jun 12, 2026

LinuxServer-CI commented on Aug 13, 2026

thelamer commented on Sep 24, 2026

LinuxServer-CI commented on Oct 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions