Using `kdePackages.*` (Qt6) instead of `libsForQt5.*` not working under wayland

Help
1

I recently removed libsForQt5.<package> (Qt5) and replaced it by kdePackages.<package> for all packages that are available in the latter.

However, they don’t work, e.g.:

> okular
qt.qpa.plugin: Could not find the Qt platform plugin "wayland" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: minimal, vnc, vkkhrdisplay, offscreen, eglfs, linuxfb, xcb, minimalegl.

With

> QT_QPA_PLATFORM= okular

okular starts in XWayland mode.

This is the typical symptom when said packages are not compiled with qt-wayland support as I recall, but I doubt such an obvious omission for standard KDE programs could be present in nixpkgs?

I guess such things should be handled by (the new?) mkKdeDerivation, but apparently it isn’t?

I’m running Hyprland since ages (with manually set QT_QPA_PLATFORM=wayland for the entire session), and have had relatively few wayland issues, apart from some “niche” packages like FreeCAD (Qt5) for which I have submitted nixpkgs fixes because wayland was forgotten…

2

Bump… months later this still seems to be an issue, am I the only one?

For instance, adding pkgs.kdePackages.filelight to home.packages and starting it, I get a coredump with an error message as in OP.

3

https://nixos.org/manual/nixpkgs/unstable/#qt-default-nix

They’ll need qtwayland as a dep

1 Like
4

You need qt6.qtwayland in your packages. See:

(Edit: I think you can just add this to environment.systemPackages/home.packages and it’ll work? But if it has to be in the actual packages themselves then we really need to fix this yesterday.)

1 Like
5

Adding it to a package set like you suggested will work as a workaround. But ideally the packages themselves should be fixed.

6

@emily @waffle8946 Thanks for the info, it appears even nixos-unstable is too bleeding edge :stuck_out_tongue_winking_eye:

I took a quick look at #333012 suggested by @emily which seems to be a good solution at the right level. But I could not discern from mkKdeDerivation that it would per default use qt6.wrapQtAppsHook (which would probably be incorrect as-is anyway, since many/some pkgs that use mkKdeDerivation are cli-based?).

So would that mean we actually should propagate the idea of the separate “cli/gui” wrappers also to mkKdeCliDerivation and mkKdeGuiDerivation and have them use the corresponding wrappers by default? Or should we just do everything related in the packages themselves, since e.g. everything kde/gear/* seems to use mkKdeDerivation but not a wrapQtAppsHook?

7

I don’t know about that KDE wrapper specifically; probably it would have to be adjusted. I know that there is no custom mkDerivation for Qt 6 and it will stay that way, but I don’t know what the plsns are for KDE.

Anyway, I don’t think this is a nixos-unstable problem; Qt 6 programs on 24.05 would have the same issue, I think. Adding qtwayland to your system packages is probably the best remedy for now. (I’d expect that if you have Plasma enabled that happens automatically, though?)

8

No plasma here, I seem to have made a point of using non-DE’s.

Thanks for the pointer, may be enough to make it work (as a workaround). But I’m also interested in (helping) to improve nixpkgs, so I’ll probably try to fix some packages, but for that I think an understanding of the overall strategy is important.

Just for my understanding of the Qt/KDE ecosystem within nixpkgs: isn’t the point of wrap-hooks and specialised derivations to reduce boilerplate within packages? So souldn’t that mean that a certain class of packages (say e.g. “GUI KDE apps”) use their own derivation that actually works (i.e. in this case something like mkKdeDerivation that includes wayland functionality), because the needed features (in this case wayland) to make the app actually usable are non-optional.

For Qt6 I think the status quo should be ok, since just Qt6 is so broad a specialisation on that level could be pointless…

9

Yes, the hope is to either make wrapQtAppsHook propagate qtwayland automatically (my preference, as this shouldn’t be left to individual packages), or to add it to every single application. We will need a wrapQtAppsNoGuiHook or similar for non‐GUI apps if we choose the former. That is the strategy [WIP] qt6.wrapQtAppsHook: propagate qtwayland, qtbase; qt6.wrapQtAppsNoGuiHook: init by eclairevoyant · Pull Request #333012 · NixOS/nixpkgs · GitHub pursues.

2 Likes
10

I just saw the referred PR was unceremoniously closed, while the whole of kdePackages is still broken on Wayland.
Is there info on whether there is an effort underway to fix wayland support on the scope level (IMHO the only thing that makes sense) as opposed to the package level?

11

It should be fixed on the package level. We propagate way too much in the world of qt, and we should start tightening that up.

EDIT: if we’re talking about the kdePackages set specifically then sure it can be fixed there without propagating.

12

The thing is that anywhere where mkKdeDerivation is used it is reasonable to expect that it includes qtwayland as a default dependency, no?

From my understanding it is for this reason that it could happen that everything in my config I migrated from the libsForQt5 scope to kdePackages (in the hope I was going to have everything Qt6 from there on) broke at once and has remained broken for months. Why shouldn’t mkKdeDerivation be allowed, or better required, to take care of this, it seems like it should be its primary task?