Running spotify-qt on a headless RPi Zero 2 W with dietpi OS

[oosias]

I want to run spotify-qt on my RPi Zero 2 W, which is connected to the ILI9341 SPI TFT Display and is running dietpi OS. I do:
$ ./spotify-qt-v4.0.4-aarch64.AppImage -platform wayland --appimage-extract-and-run
which gives me the output:
[18:46:52] [wrn] Failed to create wl_display (No such file or directory)
[18:46:52] [inf] Could not load the Qt platform plugin "wayland" in "" even though it was found.
[18:46:52] [ftl] This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb, wayland-brcm, wayland-egl, wayland.

I also tried with xcb, even linuxfb as a platform; they all give back the same error, that the Qt platform plugin wasnt found. I have very little expirience with qt, so maybe I am missing some lower level dependency or driver. My question is now is there any suggestion which graphics stack to use with spotify-qt? Maybe inside the build configuration (one or more of the CMakeLists) there is a certain stack baked into the executable and one has to have that in order to run it? Because of limitations I would like to use something lightweight (which is also why I am not running a desktop environment).

[Kxrma47]

This is a display-stack issue, not a spotify-qt CMake choice. The Wayland plugin loaded, but no compositor created a wl_display; xcb likewise needs an X server. Also, linuxfb is absent from the AppImage’s reported plugin list, so that AppImage cannot use it.

For the packaged AppImage, run a lightweight compositor (for example Weston/Cage) on a working DRM/KMS driver, then launch the client:

export XDG_RUNTIME_DIR=/run/user/$(id -u)
weston --backend=drm-backend.so

# second shell
WAYLAND_DISPLAY=wayland-0 ./spotify-qt-v4.0.4-aarch64.AppImage \
  --appimage-extract-and-run -platform wayland

If the ILI9341 exposes only /dev/fb0, you instead need a Qt build that includes linuxfb, then use software rendering:

QT_QUICK_BACKEND=software ./spotify-qt -platform linuxfb:fb=/dev/fb0

References: spotify-qt’s supported platforms/build and Qt embedded Linux platform plugins.

[oosias]

Thanks, your answer helped me progress a little bit (I think).
After having a couple issues with weston, because seatd and polkit issues I got it to run eventually with your suggested command:
weston --backend=drm-backend.so & (I start it as a background process, so my environment is exactly the same for the subsequent commands and programs)
I set a couple of environment variables, based on some research online:

QT_LOGGING_RULES=qt.qpa.*=true
XDG_RUNTIME_SESSION=wayland

WAYLAND_DISPLAY=wayland-1 <-- this makes sense because a ls on /run/user/1000 reveals that there is a socket file named "wayland-1" and a "wayland-1.lock" file after weston has been started

QT_QPA_PLATFORM=wayland
QT_DEBUG_PLUGINS=1
XDG_RUNTIME_DIR=/run/user/1000
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

That ouputs:

[11:33:00.098] Command line: weston --backend=drm-backend.so
...
[11:33:00.106] libseat: session control granted
[11:33:00.121] using /dev/dri/card0
[11:33:00.121] DRM: supports atomic modesetting
[11:33:00.121] DRM: supports GBM modifiers
[11:33:00.121] DRM: does not support Atomic async page flip
[11:33:00.121] DRM: supports picture aspect ratio
failed to open /dev/dri/renderD128: Permission denied
failed to open /dev/dri/renderD128: Permission denied
[11:33:00.321] Loading module '/usr/lib/aarch64-linux-gnu/libweston-14/gl-renderer.so'
[11:33:00.333] warning: failed to query rendering device from EGL
[11:33:00.333] EGL version: 1.5
[11:33:00.333] EGL vendor: Mesa Project
[11:33:00.333] EGL client APIs: OpenGL OpenGL_ES
[11:33:00.334] warning: Disabling render GPU timeline and explicit synchronization due to missing EGL_ANDROID_native_fence_sync extension
[11:33:00.334] EGL features:
               EGL Wayland extension: no
               context priority: no
               buffer age: yes
               partial update: no
               swap buffers with damage: no
               configless context: yes
               surfaceless context: yes
               dmabuf support: modifiers
[11:33:00.448] GL version: OpenGL ES 3.2 Mesa 26.2.1-2~bpo13+0~rpt1
[11:33:00.448] GLSL version: OpenGL ES GLSL ES 3.20
[11:33:00.448] GL vendor: Mesa
[11:33:00.448] GL renderer: llvmpipe (LLVM 19.1.7, 128 bits)
[11:33:00.478] GL ES 3.2 - renderer features:
               read-back format: ARGB8888
               glReadPixels supports y-flip: yes
               glReadPixels supports PBO: yes
               wl_shm 10 bpc formats: yes
               wl_shm 16 bpc formats: yes
               wl_shm half-float formats: yes
               internal R and RG formats: yes
               OES_EGL_image_external: yes
[11:33:00.479] Using GL renderer
[11:33:00.521] event0  - vc4-hdmi: is tagged by udev as: Keyboard Pointingstick
[11:33:00.523] event0  - vc4-hdmi: device is a pointer
[11:33:00.523] event0  - vc4-hdmi: device is a keyboard
[11:33:00.547] libinput: configuring device "vc4-hdmi".
[11:33:00.548] DRM: head 'UNNAMED-1' found, connector 34 is connected, EDID make 'unknown', model 'unknown', serial ''
               Supported EOTF modes: SDR
               Supported colorimetry modes: default
[11:33:00.548] Registered plugin API 'weston_drm_output_api_v1' of size 40
[11:33:00.548] Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
[11:33:00.548] Color manager: no-op
                 protocol support: no
[11:33:00.548] Output 'UNNAMED-1' attempts EOTF mode SDR and colorimetry mode default.
[11:33:00.548] Output 'UNNAMED-1' using color profile: stock sRGB color profile
[11:33:00.549] Chosen EGL config details: id:  46 rgba: 8 8 8 0 buf: 24 dep:  0 stcl: 0 int: 1-1 type: win vis_id: XRGB8888 (0x34325258)
[11:33:00.549] Output UNNAMED-1 (crtc 37) video modes:
               320x240@60.0, preferred, current, 4.6 MHz
[11:33:00.550] associating input device event0 with output UNNAMED-1 (none by udev)
[11:33:00.550] Output 'UNNAMED-1' enabled with head(s) UNNAMED-1
[11:33:00.550] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               cursor planes: yes
               arbitrary resolutions: no
               view mask clipping: yes
               explicit sync: no
               color operations: yes
               presentation clock: CLOCK_MONOTONIC, id 1
               presentation clock resolution: 0.000000001 s
[11:33:00.550] Loading module '/usr/lib/aarch64-linux-gnu/weston/desktop-shell.so'
[11:33:00.551] launching '/usr/libexec/weston-keyboard'
[11:33:00.557] launching '/usr/libexec/weston-desktop-shell'

At the same time the spotifyd program is running in the background as a systemd user service (I dont know if spotifyd is important for spotify-qt to run)

After that I start the spotify-qt Appimage via:

./spotify-qt-v4.0.4-aarch64.AppImage --appimage-extract-and-run

But nothing happens (at least now the prior "[inf] Could not load the Qt platform plugin "wayland" in "" even though it was found." is gone).
The only ouput is:
[wrn] Failed to load settings: "/home/dietpi/.config/kraxarn/spotify-qt.json" not found
After that nothing is displayed on my TFT screen and nothing else is printed to terminal. This config file doesnt seem essential for spotify-qt to run, but maybe you have a default file for that? What else could be the reason that i see nothing? My display is definitely turned on.

[Kxrma47]

The missing settings file is expected on first launch; it is not the cause. When no refresh token exists, spotify-qt should open its first-run API setup dialog before creating the main window: https://github.com/kraxarn/spotify-qt/blob/stable/src/main.cpp#L64-L108

Your Weston log shows that the DRM output was enabled at 320x240, so test the compositor separately first:

XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-1 weston-terminal

If that terminal does not appear on the TFT, the problem is still Weston/output mapping rather than spotify-qt.

If it does appear, launch spotify-qt with the variables attached to the same command. This avoids the common case where shell variables were assigned but not exported:

env \
  XDG_RUNTIME_DIR=/run/user/1000 \
  WAYLAND_DISPLAY=wayland-1 \
  QT_QPA_PLATFORM=wayland \
  QT_LOGGING_RULES='qt.qpa.*=true' \
  WAYLAND_DEBUG=1 \
  ./spotify-qt-v4.0.4-aarch64.AppImage \
  --appimage-extract-and-run -platform wayland

Then check whether the process remains alive:

pgrep -af spotify-qt

The renderD128: Permission denied messages are also worth fixing or testing around. Check id and ls -l /dev/dri/renderD128; the user normally needs access through the device's render group, followed by a new login session. Weston fell back to llvmpipe, so this may be slow but should not by itself suppress the setup dialog.

spotifyd is only the playback backend and is not needed for the GUI to become visible. spotify-qt still needs its first-run Spotify Web API setup. Its README confirms that a separate playback client is required for playback, while the current source also marks integrated spotifyd support as deprecated: https://github.com/kraxarn/spotify-qt#readme

Please report whether weston-terminal appears and include the last 30 or so lines from the WAYLAND_DEBUG=1 launch. That will distinguish a Wayland surface/mapping failure from an oversized first-run dialog on the 320x240 output.

[oosias]

I recreated your steps.
First i ssh into my RPi and do:
weston --backend=drm-backend.so --shell=kiosk-shell.so
Observations:

...
[13:21:11.822] Compositor capabilities:
               arbitrary surface rotation: yes
               screen capture uses y-flip: yes
               cursor planes: yes
               arbitrary resolutions: no
               view mask clipping: yes
               explicit sync: yes
               color operations: no
               presentation clock: CLOCK_MONOTONIC, id 1
               presentation clock resolution: 0.000000001 s
[13:21:11.824] Loading module '/usr/lib/aarch64-linux-gnu/weston/kiosk-shell.so'

Weston seems to get stuck at loading kiosk-shell as there is nothing printed afterwards.

Then I ssh into my RPi from another Powershell instance and do:
XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-1 weston-terminal
Observations:

could not load cursor 'dnd-move'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
Unknown parameter: ?2004

Thats it, nothing else happens.

[Kxrma47]

Thanks for testing. Weston remaining open after Loading ... kiosk-shell.so does not by itself mean it is stuck; a compositor normally keeps running. The cursor warnings and ?2004 message also do not establish why the TFT stays grey. Your earlier log showed a connected 320×240 DRM output, so the next clean test is a client that uses neither Qt nor the terminal:

XDG_RUNTIME_DIR=/run/user/1000 WAYLAND_DISPLAY=wayland-1 weston-simple-shm

If that command is unavailable, please say what command -v weston-simple-shm returns. Does the TFT change at all, and does the client remain running? If it is still grey, please share the Weston log lines produced while this client starts. That will tell us whether to investigate Weston/DRM presentation before returning to spotify-qt. Weston documentation.

[oosias]

Here is the output of the Weston-Server after I start the weston-simple-shm program in another ssh-session (The first line is the Loading line i mentioned earlier):

[10:15:22.837] Loading module '/usr/lib/aarch64-linux-gnu/weston/kiosk-shell.so'
[3370351.370] wl_display#1.get_registry(new id wl_registry#2)
[3370351.506]  -> wl_registry#2.global(1, "wl_compositor", 5)
[3370351.556]  -> wl_registry#2.global(2, "wl_subcompositor", 1)
[3370351.598]  -> wl_registry#2.global(3, "wp_viewporter", 1)
[3370351.634]  -> wl_registry#2.global(4, "zxdg_output_manager_v1", 2)
[3370351.670]  -> wl_registry#2.global(5, "wp_presentation", 1)
[3370351.705]  -> wl_registry#2.global(6, "wp_single_pixel_buffer_manager_v1", 1)
[3370351.741]  -> wl_registry#2.global(7, "wp_tearing_control_manager_v1", 1)
[3370351.777]  -> wl_registry#2.global(8, "zwp_relative_pointer_manager_v1", 1)
[3370351.839]  -> wl_registry#2.global(9, "zwp_pointer_constraints_v1", 1)
[3370351.891]  -> wl_registry#2.global(10, "zwp_input_timestamps_manager_v1", 1)
[3370351.927]  -> wl_registry#2.global(11, "weston_capture_v1", 1)
[3370351.991]  -> wl_registry#2.global(12, "wl_data_device_manager", 3)
[3370352.023]  -> wl_registry#2.global(13, "wl_shm", 2)
[3370352.054]  -> wl_registry#2.global(14, "wl_drm", 2)
[3370352.085]  -> wl_registry#2.global(15, "zwp_linux_dmabuf_v1", 5)
[3370352.129]  -> wl_registry#2.global(16, "wl_seat", 7)
[3370352.160]  -> wl_registry#2.global(17, "weston_direct_display_v1", 1)
[3370352.191]  -> wl_registry#2.global(18, "zwp_linux_explicit_synchronization_v1", 2)
[3370352.221]  -> wl_registry#2.global(19, "weston_content_protection", 1)
[3370352.252]  -> wl_registry#2.global(20, "wl_output", 4)
[3370352.281]  -> wl_registry#2.global(21, "xdg_wm_base", 5)
[3370352.331] wl_display#1.sync(new id wl_callback#3)
[3370352.371]  -> wl_callback#3.done(1)
[3370352.415]  -> wl_display#1.delete_id(3)
[3370352.838] wl_registry#2.bind(1, "wl_compositor", 1, new id [unknown]#4)
[3370352.905] wl_registry#2.bind(13, "wl_shm", 1, new id [unknown]#5)
[3370352.998]  -> wl_shm#5.format(0)
[3370353.035]  -> wl_shm#5.format(1)

...

After a short while the output is only a periodic:

...
[3376968.339] wl_surface#3.attach(wl_buffer#14, 0, 0)
[3376968.440] wl_surface#3.damage(20, 20, 280, 200)
[3376968.497] wl_surface#3.frame(new id wl_callback#13)
[3376968.549] wl_surface#3.commit()
[3377073.653]  -> wl_buffer#14.release()
[3377076.106]  -> wl_callback#13.done(241150)
[3377076.204]  -> wl_display#1.delete_id(13)
[3377078.474] wl_surface#3.attach(wl_buffer#14, 0, 0)
[3377078.607] wl_surface#3.damage(20, 20, 280, 200)
[3377078.666] wl_surface#3.frame(new id wl_callback#13)
[3377078.716] wl_surface#3.commit()
[3377183.532]  -> wl_buffer#14.release()
[3377185.969]  -> wl_callback#13.done(241260)
[3377186.090]  -> wl_display#1.delete_id(13)
...

That seems to be the normal output while rendering the image of the weston-simple-shm program.
The display is still grey.
I think the next steps I will take will be to check my display driver to see why the display turns grey in the first place.
I remember that I used linufb before (following this tutorial: https://www.wetransco.de/2025/01/ili9341-display-on-raspberry-pi-zero-2w-new-control-method/) and there the screen did not turn that color. It seems to me that every backlight-LED is at full brightness and therefore not able to display a proper image.

[oosias]

I finally got it by just taking a look at my config.txt and comparing it to my physical pin-connections...
In my config.txt I specified the "backlight-gpio" to be on GPIO 23, while I physically connected the displays backlight-pin to GPIO 24.
Now everything works and when I run the appimage the display shows the "Welcome to spotify-qt" prompt.
My apologies for taking your time when the problem was something so simple.
Thank you for your help!