Change:
rapidxml = callPackage ../development/libraries/rapidxml { }; <ins> rapidyaml = callPackage ../development/libraries/rapidyaml {}; </ins> raul = callPackage ../development/libraries/audio/raul { }; raylib = callPackage ../development/libraries/raylib { };

Discussion:
Hi! Latest released version: 1.7.4524 <!-- Search your package here: --- Current version on the unstable channel: 1.7.0-0 Current version on the stable/release channel: 1.7.0-0
cc

Describe the bug When running PCSX2 on Sway/Wayland under XWayland, the GUI performs terribly laggy and freezes consistently. Additionally, my GTK theme does not behave as expected; highlights, etc do not appear properly. After a relatively small amount of time interacting with the menus, I have to to escape. This likely has to do something with the following series of errors when running , leading me to believe this is a nixpkgs issue rather than one with PCSX2 or Sway. It could be an issue with GTK+ under XWayland, in which case this report should be closed. To Reproduce Steps to reproduce the behavior: Sway bad Expected behavior For the GUI to not lag and for me to be able to load a game. Screenshots ! Note the failures in the logs. Notify maintainers Metadata
I run sway myself. PCSX2 currently does not run in a wayland environment, try to rerun it with , this should fix your issues.
I think this issue is actually related to GTK2, this also happened on my Plasma X11 install. Getting pcsx2 from the unstable channel fixes the issue for me.
Further PCSX2 is x86 (32bit) only. It looks like your GTK theme is using the Adwaita and Murrine engine which are only available in x86 64bit. Also try the current PCSX2 version from master. This one links against GTK3 instead of 2.
PCSX2 actually compiles to x86_64 too since .
Oh, my bad, thanks for pointing that out. I guess switching to the current version on master/unstable will resolve all your problems. Your version is still 32bit () and using GTK2.
Actually no, the 64 bit port of PCSX2 on upstream isn't finished yet, and several parts of the JIT are missing(eg the software renderer will crash) thus 64bit isn't currently supported. PCSX2 OpenGL window will crash on wayland iirc, so wayland is out of the question too. The issues are mostly related to wxGTK, master has a long term plan to switch away from WxWidgets but things like this takes an unfathomable amount of time.
Running with doesn't help.

I think it does by default, as well, since tracks into a PCSX2 window. I'll try from unstable.
I guess it would be best then to revert the 64bit build and maybe add it as a separate derivation?
This would probably be wise for the time being, yes.
Using unstable worked fine. Sorry for not responding to this, I was busy with Life Stuff(tm). If you want to close this, go right on ahead. I'd rather not since I don't know if there's still work to be done here.
Thanks for testing and reporting back :+1: Glad to hear that everything worked out, enjoy gaming :) for going forward I suggest to add another derivation. Since full x8664 support is coming I am in favor of adding as another derivation and keep as is. This should also be included in the backport in Replacing the 32bit build on stable when it actually is not ready without any replacement does not feel right to me. What are your thoughts on this?
The current standard derivation is x8664, which is not finalized yet. I'm more in favor of renaming the current derivation to and then making the 32 bit one the default.
My reasoning is the following: There is no 64 bit Nix derivation. Our “64bit” version is just the normal derivation without any constraint. This does mean it is the same architecture as the underlying OS. In this case it is x86 with or without the 64bit extension. So on a 32bit system wont install a 64bit pcsx2 but rather a 32bit one. On the other side is forced to i686 and will always be built for this architecture. Further the constraint free package is the one to stay. If we name the default package it will go away once it is ready, which implies that we either need to add an alias or remove it which breaks stuff. On the other hand might be valuable for people and could stay for a while.
Hmm that works for me, but why in this case don't we keep this derivation and users can explicitely ask in their nix config for an x86 version?
yeah, I also thought about that. But this would not change much. We could either: Do nothing and rely on users overriding the derivation on their own.

This would mean that we are still shipping a broken package by default. This is a doable approach but with something as big as the software renderer not working, this is not acceptable. Add a config option. This is might sound less intrusive than another package but it actually is not. It is more complex, easier to miss, has less features (does not allow to install both versions at once) and is not that clear. Once we remove the option we would still have the same problem of supporting it, with the downside that removing a derivation will be immediately noticed and understood by a user which does not hold true for the config option.
Well I'll trust your judgement on that one, this is a pretty finicky situation :/
I think making the 32bit version the default and having users override it if they want the 64bit version would be the best solution. With that approach we would be shipping a working package by default and don't need to deal with deprecating a config option or package later. Having a working package in nixpkgs is more important than having it be 64bit. Thoughts?
I marked this as stale due to inactivity. &rarr;