Help Wizard

Step 1


Wayland support

Wayland support


Can you release a linux package with ozone support built so that we can use the client under Wayland? There have been posts requesting this in the past because it is highly anticipated.


It shouldn't be that complicated it seems:



78 Replies

Oh, yes please!


This almost works:

spotify --enable-features=UseOzonePlatform --ozone-platform=wayland


However, the content ends up "detached" from the main window, though the detached content is using Wayland:



I'm running on pure wayland and it simply segfaults. dmesg shows

"spotify[53433]: segfault at 0 ip 00007f0ccf1327d4 sp 00007ffdfabb6710 error 4 in[7f0ccf12f000+13000]". afaics it's making a call to libxcb which is not present in the memory, naturally.


people have mixed results tho: I guess they have xwayland which spotify resorts as a fallback.


I'm hopeful a build with latest cef would solve this. but well, it's only a hope hah!

I'm running swaywm on Arch and those chromium flags result in an empty black window. Actual chromium does run with them though, even if not perfectly yet.

Got it working by writing some stub implementations of some X11 functions spotify tries to call on launch but doesn't actually need. use `cc xstub.c -o -shared` and ` spotify --enable-features=UseOzonePlatform --ozone-platform=wayland` to launch.

#include <stdio.h>

#define X_FN(f) int f() { puts("called"); return 0; }


The X11 function stub workaround by @jane-0 works in some conditions to prevent Spotify from segfaulting on startup on Wayland, but for me it doesn't solve the problem of the window content being "detached" from the window itself (see first comment).

This makes Spotify almost unusable on Wayland, the window can't be moved or resized.
I'm on KDE neon dev with KWin Wayland.

One issue is that the Spotify client still uses an old version of Electron. The ozone Wayland back-end works really well in newer versions of Chromium, which requires only 1 flag since Chromium 97 to enable Wayland support.  An upgrade to Electron 16 or 17 would be necessary for a mature enough Wayland back-end.

Spotify doesn't use Electron, but Chromium Embedded Framework

Here's a temporary solution, since Spotify is running on CEF anyway:

Open Chrome and set 'Preferred Ozone platform' to Wayland in chrome://flags

Restart Chrome and go to

'Install Spotify' from Chrome menu.

You'll lose settings, but at least should avoid X11

Any Spotify dev work on it?

@jane-O solution doesn't seem to work for me.
Also using Spotify Web in browser isn't a solution.



As a temporary solution to annoying "detached window" problem I've traced library calls to stub the places where it were created. Here is the result:


// compile as: gcc xcbstub.c -o -fPIC -shared

#include <stddef.h>
#include <stdlib.h>
#include <stdbool.h>
#include <stdint.h>

void gtk_init(int *argc, char ***argv) { }
void* gdk_pixbuf_loader_new() { return NULL; }

typedef struct xcb_connection {
    int has_error;
} xcb_connection_t;

xcb_connect(const char *displayname, int *screenp)
    xcb_connection_t *conn = calloc(1, sizeof(xcb_connection_t));
    conn->has_error = 1;
    return conn;

int xcb_connection_has_error(xcb_connection_t *c)
    return 1;

int xcb_flush(xcb_connection_t *c)
    return 0;

uint32_t xcb_generate_id(xcb_connection_t *c)
    return 42;

void xcb_disconnect(xcb_connection_t *c)

void* cef_get_xdisplay() {
    return NULL;

void *XOpenDisplay(const char *display_name)
    return NULL;

typedef unsigned long Atom;
typedef unsigned long Window; /*?*/

int XInternAtoms(void *display, char **names, int count, bool only_if_exists, Atom *atoms_return)
    return -1;

int XChangeProperty(void *display, Window w, Atom property, Atom type, int format, int mode, const unsigned  char
        *data, int nelements)
    return  0;




After preloading this library X11 window disappears. However Spotify remains running after closing Wayland window. So you must kill the process manually.


I'd totally love to see a functional version on Debian with Wayland on Sway, too.

In Firefox the webplayer sometimes simply stops outputting music, in Chromium I can't even get behind that "browser not supported" view.


I'd love a CLI or at least TUI most, but that's just dreaming. 😉

Engineer here. Wayland support has been implemented and is being tested. It will be available in a near release, though I can't promise dates

First version of Wayland support is available for Snap/Edge (version 1.1.99)

Oh nice.
Can you put this version on the repository please ?


The last version in the official repository is

Thank you so much

I was actually going to ask the same thing a couple weeks ago. Publishing it to the Repository would be great! Especially for people like Arch users.

Presently, Spotify is the 8th most popular Arch Linux package in the AUR.

If it's still a testing version it's absolutely understandable that is currently sits only in a controlled environment (snap). If only spotify would official support the flatpak as well (: (btw we can have verification-badged now on flathub)



There's an ongoing effort by someone in Spotify to create flatpaks.
But just like everything else that involves the Linux client, it
depends on the extra time that engineers find outside of their main
tasks. So unfortunately there's no prediction on when this will be

Thanks pgomes for your work 😉

I tried this version 1.1.99.
I've downloaded the snap, mounted the snap, and executed this new version.

After testing it with no issues, I've installed manualy on my system and it is working like a charm with wayland !!!!!!

Good work and thanks to support Linux !!!! 🙂

Thanks !drop down menu and chinese/japanese input work like a charm now!. I also test with

--enable-features=UseOzonePlatform --ozone-platform=wayland

this eliminate blurry app on fractional scaling, but chinese/japanese input will not work, which is understandable since chromium doesn't implement it. Anyway, thanks for the update.

Suggested posts