You are not logged in.
Hello everyone,
A few days ago I posted on Reddit complaining that casting to a Samsung TV on Hyprland is still a nightmare in 2026.
I`ll try to write my own solution on python. firstone be on dlna with default python http.server (and ffmpeg like that stuff) and it works! but... not very good.
I had a biiiig delay. But someone explained why my 20s delay was happening (HLS chunking, buffering and more more more), and instead of just fixing that I ended up rewriting the whole thing from scratch to real Miracast.
It now actually works!!! real Miracast. Wi-Fi Direct, full RTSP handshake, ~1 second latency, video + audio. Not DLNA with a TV player buffering everything, actual WFD the way Windows does it.
github: https://github.com/IlyaP358/fluxcast
original threads: 1 https://www.reddit.com/r/archlinux/comm … nux_still/
2 https://www.reddit.com/r/archlinux/comm … client_in/
Still rough around the edges, wf-recorder only so Hyprland/Sway for now, some hardcoded Samsung stuff that needs to become proper device profiles. PipeWire backend for KDE/GNOME is in progress.
If anyone wants to test on a non-Samsung TV or non-Hyprland setup I'd really appreciate it!
Run python3 main.py --doctor first to check if your system is ready.
Thanks! =]
Offline
Miracast won't work w/o P2P right?
iw list | grep -A 10 "Supported interface modes"
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
Band 1:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabledI'm on a Realtek RTL8822CE
└─$ lspci | grep -i network
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8822CE 802.11ac PCIe Wireless Network Adapteralso it flags the hardware gaps at the bottom. It seems like for this chipset, the WFD path is a no-go.
└─$ python3 main.py --doctor
[FluxCast Doctor] System capability report
[FluxCast Doctor] Miracast/WFD is not confirmed yet; check warn/fail rows above.
Status Check Details
------ ---------------------- ------------------------------------------
ok python runtime (3.14.4 on Linux 7.0.3-arch1-2)
ok ffmpeg video/audio transcoding (/usr/bin/ffmpeg)
warn wf-recorder Wayland/wlroots screen capture (not found in PATH)
ok pactl PulseAudio/PipeWire-Pulse audio monitor detection (/usr/bin/pactl)
ok xrandr X11 monitor detection fallback (/usr/bin/xrandr)
ok nmcli NetworkManager Wi-Fi Direct control (/usr/bin/nmcli)
ok iw kernel Wi-Fi interface inspection (/usr/bin/iw)
ok wpa_cli active Wi-Fi Direct scan/control (/usr/bin/wpa_cli)
ok gdbus passive wpa_supplicant D-Bus capability checks (/usr/bin/gdbus)
ok gst-launch-1.0 optional future WFD GStreamer pipeline (/usr/bin/gst-launch-1.0)
ok gst-inspect-1.0 optional future WFD codec inspection (/usr/bin/gst-inspect-1.0)
ok ffmpeg encoders H.264 and AAC encoders are available (h264=libx264, h264_vaapi, h264_nvenc, h264_qsv, h264_v4l2m2m; aac=yes)
ok screen capture X11 capture path is available (DISPLAY=:0; xrandr=/usr/bin/xrandr)
ok audio capture default audio monitor can be derived (alsa_output.pci-0000_04_00.6.analog-stereo.monitor)
warn NetworkManager Wi-Fi is visible, but no P2P device was listed (nmcli tool, version 1.56.0-1; wlp3s0:wifi:connected | lo:loopback:connected (externally) | eno1:ethernet:unavailable)
warn iw P2P Wi-Fi interfaces exist, but no P2P-device was shown (phy#0 | Interface wlp3s0 | ifindex 3 | wdev 0x1 | addr bc:f4:d4:84:bd:87 | ssid VARASIDDHI-5g | type managed | channel 44 (5220 MHz), width: 80 MHz, center1: 5210 MHz | txpower 20.00 dBm | multicast TXQ: | qsz-byt qsz-pkt flows drops marksoverlmt hashcol tx-bytes tx-packets | 0 0 0 0 0 0 0 0 0)
warn wpa_supplicant P2P supplicant capability query failed (Error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Sender is not authorized to send message)
warn wpa_supplicant WFD WFDIE query failed; supplicant may lack CONFIG_WIFI_DISPLAY (Error: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Sender is not authorized to send message)Just wanted to share this so you have more data on which chipsets are struggling with the WFD implementation! ![]()
"Nothing matters" -a Nihilist
"Why bother thinking what matters?" -me
Offline
Thanks for the data, really useful!
You're right, without P2P in the interface modes WFD won't work, that's a hardware/driver limitation, not something FluxCast can work around.
Realtek's Linux drivers have historically had poor P2P support compared to Intel.
Your --doctor output is interesting though - X11 capture path is available but not tested very vell, so if you ever want to try DLNA fallback mode it should work:
python3 main.py --protocol dlna --transport hls
Won't be as low latency as WFD but at least gets something on the TV...I hope. Worth trying if you have a DLNA-capable TV!
Offline