rpcs3
rpcs3 copied to clipboard
RPCS3
Qt6 port
Not concidered for merge. Missing at least one feature (windows taskbar stuff).
Just testing CI etc.
TODO:
- [x] Test music handler
- [x] Test play sound
- [ ] Add taskbar stuff when available
Will break compatibility with older Windows systems and might break AppImages for some distros at first. Some heads up is needed before the merge to adjust minimum requirements if there are no other solutions. We're dropping bionic next April as it reaches EOL and switching the AppImage base to focal so that might help with compatibility on the Linux side.
Will break compatibility with older Windows systems
What about supporting both Qt5 and Qt6?
What about qt6 is so important that it'd justify the maintenance burden and added complexity? Qt5 seems to work just fine right now, I don't see why we would need to rush with this
What about qt6 is so important that it'd justify the maintenance burden and added complexity? Qt5 seems to work just fine right now, I don't see why we would need to rush with this
That's reasonable as long as the main reason isn't to keep support for irrelevant OSes like Windows 7/8(.1): 
https://store.steampowered.com/hwsurvey/Steam-Hardware-Software-Survey-Welcome-to-Steam?platform=pc
I'll show ya about "irrelevant" OS! Somebody hold my beer for a momemnt...
Qt6 port would be great appreciated because the last QT 5 LTS(Long Term Support) version is supported until May 2023, after that QT 5 will be almost completely dead and deprecated...
I think this has to wait before we move away from Ubuntu 18.04 LTS to generate AppImages regardless
Many projects still use old GTK2 and they work fine. QT is really only for GUI(+sound) and it just works. No need for "support" regarding that? Unless its sound backend become issue which I could then understand, why switch to QT6 and cut older Windows base(however small), only due to GUI backend? Yuzu at least had a reason, they changed memory handling, Ryujinx too yet that one actually still works(it automatically switch to older, slower memory handling). Please, if you ever make RPCS3 incompatible with Windows 7 one day, at least make it for a good reason, like an actual desirable core/memory code change(or if sound become an issue), not just for a GUI backend switch for gods sake!
Many projects still use old GTK2 and they work fine. QT is really only for GUI(+sound) and it just works. No need for "support" regarding that? Unless its sound backend become issue which I could then understand, why switch to QT6 and cut older Windows base(however small), only due to GUI backend? Yuzu at least had a reason, they changed memory handling, Ryujinx too yet that one actually still works(it automatically switch to older, slower memory handling). Please, if you ever make RPCS3 incompatible with Windows 7 one day, at least make it for a good reason, like an actual desirable core/memory code change(or if sound become an issue), not just for a GUI backend switch for gods sake!
On Windows you can run an outdated Qt version, it's okay, but on Linux, no you can't. On Linux a library is usually get from a package on a repository with a package manager, if the library isn't in your repo, good luck to use and/or compile stuff that use this lib, Qt 5.15 LTS(the last Qt 5 version) will be deprecated in May 2023, so, soon after this deprecation(especially on rolling release distro) all distro maintainers will start to remove Qt 5 from their repositories because it's obsolete/deprecated.
And I want to be able to compile & run the latest git version of RPCS3, even after May/June 2023.
I know that Linux is a minority of people, but if RPCS3 support Linux they should try to not break itself on Linux, that's it.
@yann-boyer If an application is relevant(and RPCS3 is), they will always ship it, along with required dependencies. You still find python 2, GTK 2, SDL 1 and so many others in repos because there are apps that are considered important to have that use them. So I wouldn't worry about that. If they can keep old GTK, I don't see why they couldn't keep old QT.
May need a rebase after 681a6ef73ca1:
rpcs3/rpcs3qt/gs_frame.cpp:358:5: error: use of undeclared identifier 'QSound'
QSound::play(qstr(sound_path));
^
Was able to build and package AppImage using gcc-11 and clang-14 with the latest commit https://github.com/RPCS3/rpcs3/pull/12471/commits/9a0490114383403f00f53dabf0373b75f132685e on Ubuntu-18.04
Qt 6.5.0 was built from source and packaged to speedup build time.
Edit:
MacOS clang-14 using Qt 6.4.2
$QT_VER_MAINand$QT_VERshould be global variables or passed to linux and mac tasks in .cirrus.yml
Thanks. that seems to work.
This is just a tangentially relevant comment, but thanks to both Chrome and Steam announcing the end of support for Windows 7 and 8.1, the negative effects of dropping Qt5 (and Windows 7+8.1) should be largely mitigated now.
This PR fixes a long-standing issue I have had (which only seems to affect me...) That has caused me grief for a year and a half.
In QT5 I intermittently got a major scaling bug. Reinstalling/DDUing drivers, reinstalling Windows 10 22H2, Updating to Windows 11, manually setting QT Config files to work with DPI Scaling, using a fresh RPCS3 Install/Folder with no configs, going back to RPCS3 builds from years ago that used to work fine for me... you name it, I tried it. The issue was clearly somewhere on my system, or with some other program I used causing a conflict with QT causing it to break. Most annoyingly, the issue was intermittent and would usually fix itself after a reboot. I tried uninstalling all my other applications that use QT. But nothing fixed it.
Whenever I was affected by this bug, it would remain until I rebooted, closing and re-opening RPCS3 or changing DPI Scaling to 100% then back to 200% etc wouldn't help. And that's why this screenshot of me showing RPCS3 on QT5 (Left) and RPCS3 on QT6 (Right) running at the same time confirms that the issue is resolved:
You have no idea how happy this makes me.
Is this PR ready to be compiled and tested on Linux? I'd like to try it out on Fedora 38 to see if Wayland support is in better shape compared to Qt5 where I always have to specify QT_QPA_PLATFORM=xcb in order to not have it crashing on me.
Alright from my initial testing, it seems to behave the same as qt5. The same bugs still exist though. I'm running Fedora 38 (default Genome desktop on wayland) which ships qt6 version 6.5.2. First of all, rpcs3 still segfaults when closing the emulator, just by opening and closing the emulator without running any games. It happens both on QT_QPA_PLATFORM=xcb and wayland. I've reported this one here: https://github.com/RPCS3/rpcs3/issues/13981
Secondly when running QT_QPA_PLATFORM=wayland, the dedicated nvidia GPU cannot be used and will segfault the emulator when starting a game. Since wayland seems to be the default QPA platform on Fedora, I have to explicitly specify QT_QPA_PLATFORM=xcb so I can use the nvidia GPU instead of the intel integrated one for the Vulkan renderer.
As of this update, RPCS3 only opens on my secondary monitor. If I move the main app window the the main monitor, the dropdown menus open on the edge of the secondary monitor. Reverting to 15417 fixes it, and every build after is broken again.
As of this update, RPCS3 only opens on my secondary monitor. If I move the main app window the the main monitor, the dropdown menus open on the edge of the secondary monitor. Reverting to 15417 fixes it, and every build after is broken again.
Create a regression report with all the required information don't comment under already merged commits.
