hudiy.eu

Is it possible to get a version of the Hudiy installer that will run on x86?

I want to try installing it on debian running on a surface pro.

Hello,
So far, Hudiy runs only on Raspberry Pi (ARM architecture) under Raspberry Pi OS (Bookworm or Trixie). However, we're planning to port it to x86, and this is one of the main areas we're currently focusing on.

Excellent, guess I'll just wait then.

Surface pros are really cheap on eBay, with decent specs and a 12inch screen....seems like a good platform for a head unit if I can run hudiy on it.

I'm looking forward for x86 platform. I'm thinking of using lattepanda IOTA system.

First of all, thank you to the development team for adding x86 support!

I'm using Hudiy 2.8 on an Intel Celeron J4105 (Geminilake) with Debian 13 (X11).
While Geminilake is supposedly supported, I’m experiencing a massive video delay (tens of seconds) that accumulates over time.
intel-gpu-top shows only 1.5% Video engine usage, suggesting that hardware acceleration (VA-API) isn't being fully utilized.
Is there a specific configuration for Geminilake to force low-latency hardware decoding and prevent this buffer accumulation?

viseme wrote: Mon Mar 02, 2026 12:03 am First of all, thank you to the development team for adding x86 support!

I'm using Hudiy 2.8 on an Intel Celeron J4105 (Geminilake) with Debian 13 (X11).
While Geminilake is supposedly supported, I’m experiencing a massive video delay (tens of seconds) that accumulates over time.
intel-gpu-top shows only 1.5% Video engine usage, suggesting that hardware acceleration (VA-API) isn't being fully utilized.
Is there a specific configuration for Geminilake to force low-latency hardware decoding and prevent this buffer accumulation?

Hello,
The drivers for VAAPI support in Debian are split across various packages. Could you please check if these packages are installed on your system?
Please also send the hudiy logs from $HOME/.hudiy/log directory (you can zip the entire directory and upload it to this thread as an attachment), as well as the output of the gst-inspect-1.0 and vainfo commands.

Thank you for your guidance. I have installed all three requested packages.
I am providing the requested logs and command outputs as attachments.
Please let me know if you need any further information to investigate this problem.
Thank you!

Thank you for the provided logs. The Hudiy logs show that the VAAPI decoder was selected for both useX86Drm = false and useX86Drm = true, so Hardware Acceleration is being used. Does the same problem occur on Wayland?

I’ve tested on Wayland,but unfortunately, the delay persists.
Interestingly, standalone ffmpeg uses 72% of the Video engine, while hudiy stays around 2.5%.
It seems my system supports VAAPI correctly, but hudiy might not be utilizing it fully.
I’ve attached the latest logs and intel-gpu-top outputs from the Wayland session.
Thank you for your continued help!

Based on the logs, Hudiy did its job and requested a VAAPI-compatible decoder from GStreamer, so the problem must be somewhere in the GStreamer-VAAPI-VPU-GPU pipeline. Android Auto/CarPlay are very specific video streams, where the majority are P-Frames (similar to e.g., Remote Desktops). Therefore, a VPU load of around 3% is normal.

Try temporarily disabling the GStreamer VAAPI plugin by moving it to your home directory (by sudo mv /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstva.so /home/YOUR_HOME_DIR/ command) - Hudiy will select a different decoder then. Also please set useX86Drm to false for the time of testing. Then, restart the machine and check how the projection behaves.

Please also let us know what display you are using, and what refresh rate and resolution are detected by the system.