[GH-ISSUE #1045] Stuck on black screen no matter what game i try #317

Closed
opened 2026-02-27 21:05:41 +03:00 by kerem · 29 comments
Owner

Originally created by @powerpuffboysz on GitHub (Sep 23, 2024).
Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1045

Game Name
Bloodborne

Game code
CUSA00900

Game version
1.09

Used emulator's version (only released versions are acceptable)
0.3.0

Current status
Boots

Error
black screen on startup with 0 fps

Description
this game is reported as able to get ingame but this and any other game get stuck on a black screen

OS: EndeavourOS
Kernel: 6.10.10-arch1-1
Desktop: KDE Plasma 6.1.5
Session: Wayland
CPU: Ryzen 9 5900X
RAM: 32GB
GPU: NVIDIA 1080 TI Founders Edition
GPU Driver: Proprietary 560.35.03-6
Executable: Linux-QT AppImage

nvidia-drm.modeset=1 is set if that matters

mangohud reports as Gpu using anywhere from 10 to 17% and cpu as anywhere from 4 to 8% on any given launch with 0fps

shad_log.txt

Originally created by @powerpuffboysz on GitHub (Sep 23, 2024). Original GitHub issue: https://github.com/shadps4-emu/shadPS4/issues/1045 Game Name Bloodborne Game code CUSA00900 Game version 1.09 Used emulator's version (only released versions are acceptable) 0.3.0 Current status Boots Error black screen on startup with 0 fps Description this game is reported as able to get ingame but this and any other game get stuck on a black screen OS: EndeavourOS Kernel: 6.10.10-arch1-1 Desktop: KDE Plasma 6.1.5 Session: Wayland CPU: Ryzen 9 5900X RAM: 32GB GPU: NVIDIA 1080 TI Founders Edition GPU Driver: Proprietary 560.35.03-6 Executable: Linux-QT AppImage nvidia-drm.modeset=1 is set if that matters mangohud reports as Gpu using anywhere from 10 to 17% and cpu as anywhere from 4 to 8% on any given launch with 0fps [shad_log.txt](https://github.com/user-attachments/files/17103519/shad_log.txt)
kerem 2026-02-27 21:05:41 +03:00
Author
Owner

@fhilipecrash commented on GitHub (Sep 23, 2024):

The same thing is happening to me using the same version of Bloodborne on shadps4 0.3.0, nvidia-drm.modeset=1 is also set. When I tested it on Windows 11 it worked normally. I thought it might be because of using Nvidia + Wayland but it didn't work on X11 either.

OS: Arch Linux
Kernel: 6.10.10-arch1-1
Desktop: GNOME 47
Session: Wayland
CPU: Intel Core i3-9100F
RAM: 16GB
GPU: NVIDIA GeForce GTX 1650
GPU Driver: Open 560.35.03
Executable: Linux-QT AppImage

output.txt

<!-- gh-comment-id:2369413750 --> @fhilipecrash commented on GitHub (Sep 23, 2024): The same thing is happening to me using the same version of Bloodborne on shadps4 0.3.0, nvidia-drm.modeset=1 is also set. When I tested it on Windows 11 it worked normally. I thought it might be because of using Nvidia + Wayland but it didn't work on X11 either. OS: Arch Linux Kernel: 6.10.10-arch1-1 Desktop: GNOME 47 Session: Wayland CPU: Intel Core i3-9100F RAM: 16GB GPU: NVIDIA GeForce GTX 1650 GPU Driver: Open 560.35.03 Executable: Linux-QT AppImage [output.txt](https://github.com/user-attachments/files/17104331/output.txt)
Author
Owner

@ngoquang2708 commented on GitHub (Sep 24, 2024):

Use gamescope as a workaround.

<!-- gh-comment-id:2370036517 --> @ngoquang2708 commented on GitHub (Sep 24, 2024): Use gamescope as a workaround.
Author
Owner

@powerpuffboysz commented on GitHub (Sep 24, 2024):

Use gamescope as a workaround.

Ah yes, gamescope. The compositor famous for working on nvidia gpus, especially using the proprietary driver.

<!-- gh-comment-id:2370395968 --> @powerpuffboysz commented on GitHub (Sep 24, 2024): > Use gamescope as a workaround. Ah yes, gamescope. The compositor famous for working on nvidia gpus, especially using the proprietary driver.
Author
Owner

@ngoquang2708 commented on GitHub (Sep 24, 2024):

Ah yes, gamescope. The compositor famous for working on nvidia gpus, especially using the proprietary driver.

It works with latest driver now

<!-- gh-comment-id:2370408503 --> @ngoquang2708 commented on GitHub (Sep 24, 2024): > Ah yes, gamescope. The compositor famous for working on nvidia gpus, especially using the proprietary driver. It works with latest driver now
Author
Owner

@7oxicshadow commented on GitHub (Sep 24, 2024):

Same here. Looking at the logs people have posted in this thread, we all seem to get stuck at the same place. Not sure of the significance of the [Kernal.Vmm] area but I assume its some sort of memory management issue. Oh i tried gamescope as well, made no difference.

The only thing i can add is that my main PC is a 12700k, 32gb ram, GTX 3070ti running Fedora 40 KDE (Wayland) and it doesn't work..... But i have a laptop also running Fedora 40 KDE / 8GB ram / Intel Integrated Graphics (Nouveau) and it does boot fine on that.... Maybe an Nvidia driver issue? Anyone here using Nouveau drivers on NVIDIA?

<!-- gh-comment-id:2370854192 --> @7oxicshadow commented on GitHub (Sep 24, 2024): Same here. Looking at the logs people have posted in this thread, we all seem to get stuck at the same place. Not sure of the significance of the [Kernal.Vmm] area but I assume its some sort of memory management issue. Oh i tried gamescope as well, made no difference. The only thing i can add is that my main PC is a 12700k, 32gb ram, GTX 3070ti running Fedora 40 KDE (Wayland) and it doesn't work..... But i have a laptop also running Fedora 40 KDE / 8GB ram / Intel Integrated Graphics (Nouveau) and it does boot fine on that.... Maybe an Nvidia driver issue? Anyone here using Nouveau drivers on NVIDIA?
Author
Owner

@srrobo92 commented on GitHub (Sep 24, 2024):

Also same issue for me, tried using gamescope as well and still black screen

<!-- gh-comment-id:2370968738 --> @srrobo92 commented on GitHub (Sep 24, 2024): Also same issue for me, tried using gamescope as well and still black screen
Author
Owner

@Oroborius commented on GitHub (Oct 2, 2024):

Yeah only specific builds seem to launch games under Wayland even with gamescope using XWayland env.

<!-- gh-comment-id:2389558034 --> @Oroborius commented on GitHub (Oct 2, 2024): Yeah only specific builds seem to launch games under Wayland even with gamescope using XWayland env.
Author
Owner

@ngoquang2708 commented on GitHub (Oct 3, 2024):

All games is black screen under native Wayland because because the emulator uses XWayland.
BB requires a Linux hack to boot even in X11.
My PR https://github.com/shadps4-emu/shadPS4/pull/1184 aim to enable the support to run the emulator in native Wayland without the need of Gamescope. But you have to force the emulator to use Wayland for now.
Under Wayland, run it with:

env -u DISPLAY ./Shadps4.qt.AppImage

Please try it and report to the PR.

For BB, I have a build which includes Wayland support and the Linux hack for BB so you guy can try: https://github.com/ngoquang2708/shadPS4/actions.

<!-- gh-comment-id:2390474193 --> @ngoquang2708 commented on GitHub (Oct 3, 2024): All games is black screen under native Wayland because because the emulator uses XWayland. BB requires a Linux hack to boot even in X11. My PR https://github.com/shadps4-emu/shadPS4/pull/1184 aim to enable the support to run the emulator in native Wayland without the need of Gamescope. But you have to force the emulator to use Wayland for now. Under Wayland, run it with: ``` env -u DISPLAY ./Shadps4.qt.AppImage ``` Please try it and report to the PR. For BB, I have a build which includes Wayland support and the Linux hack for BB so you guy can try: https://github.com/ngoquang2708/shadPS4/actions.
Author
Owner

@Oroborius commented on GitHub (Oct 4, 2024):

@ngoquang2708 Unfortunately this does not fix the issue for many different builds and versions including the latest version when running it on Wayland DE including forcing it to run X11 with gamescope.

In fact the only actual solution I found was from an issue somewhere that I can't actually find but editing the thread_management.cpp to this actually entirely resolves the issue and allows games to boot.

ScePthread PThreadPool::Create(const char* name) {
    std::scoped_lock lock{m_mutex};

    for (auto* p : m_threads) {
        if (p->is_free && name != nullptr && p->name == name) {
            p->is_free = false;
            return p;
        }
    }

    #ifdef _WIN64
        auto* ret = new PthreadInternal{};
    #else
        // TODO: Linux Specific Hack
        static u8* hint_address = reinterpret_cast<u8*>(0x7FFFFC000ULL);
        auto* ret = reinterpret_cast<PthreadInternal*>(
            mmap(hint_address, sizeof(PthreadInternal), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0));
        hint_address += Common::AlignUp(sizeof(PthreadInternal), 4_KB);
    #endif
    ret->is_free = false;
    ret->is_detached = false;
    ret->is_almost_done = false;
    ret->attr = nullptr;

    m_threads.push_back(ret);

    return ret;
}

Bless the soul who found it out because it causes builds to run just fine. Unfortunately it also means I need to build manually every time I want to update shadps4.

Also to clarify, this allows latest build to boot into the game for me as well as from any version I had a repository saved of.

For reference:
Fully up to date
KDE Plasma
Wayland
Arch
Also Nvidia proprietary dkms if that matters.

<!-- gh-comment-id:2392948167 --> @Oroborius commented on GitHub (Oct 4, 2024): @ngoquang2708 Unfortunately this does not fix the issue for **many** different builds and versions including the latest version when running it on Wayland DE **including** forcing it to run X11 with gamescope. In fact the only actual solution I found was from an issue somewhere that I can't actually find but editing the `thread_management.cpp` to this actually entirely resolves the issue and allows games to boot. ```cpp ScePthread PThreadPool::Create(const char* name) { std::scoped_lock lock{m_mutex}; for (auto* p : m_threads) { if (p->is_free && name != nullptr && p->name == name) { p->is_free = false; return p; } } #ifdef _WIN64 auto* ret = new PthreadInternal{}; #else // TODO: Linux Specific Hack static u8* hint_address = reinterpret_cast<u8*>(0x7FFFFC000ULL); auto* ret = reinterpret_cast<PthreadInternal*>( mmap(hint_address, sizeof(PthreadInternal), PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0)); hint_address += Common::AlignUp(sizeof(PthreadInternal), 4_KB); #endif ret->is_free = false; ret->is_detached = false; ret->is_almost_done = false; ret->attr = nullptr; m_threads.push_back(ret); return ret; } ``` Bless the soul who found it out because it causes builds to run just fine. Unfortunately it also means I need to build manually every time I want to update shadps4. Also to clarify, this allows latest build to boot into the game for me as well as from any version I had a repository saved of. For reference: Fully up to date KDE Plasma Wayland Arch Also Nvidia proprietary dkms if that matters.
Author
Owner

@ngoquang2708 commented on GitHub (Oct 4, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

<!-- gh-comment-id:2393023469 --> @ngoquang2708 commented on GitHub (Oct 4, 2024): @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with ```env -u DISPLAY ./Shadps4.qt.AppImage```. It also included your patch.
Author
Owner

@Oroborius commented on GitHub (Oct 4, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

Can confirm these do run and do not need to be ran under X11 through arguments and run about the same as the scissor rect patch. They actually suffer the same performance impact in many places due to an obscure bug that causes the framerate to tank to 10FPS. The pull request from here actually grants a significant performance uplift in areas where this bug occurs and allows me to run the game at a stable 1440p60 with no issue beside odd polygon tearing post-death.

<!-- gh-comment-id:2394416770 --> @Oroborius commented on GitHub (Oct 4, 2024): > @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with `env -u DISPLAY ./Shadps4.qt.AppImage`. It also included your patch. Can confirm these do run and do not need to be ran under X11 through arguments ~~and run about the same as the scissor rect patch.~~ They actually suffer the same performance impact in many places due to an obscure bug that causes the framerate to tank to 10FPS. The pull request from [here](https://github.com/shadps4-emu/shadPS4/pull/1146) actually grants a significant performance uplift in areas where this bug occurs and allows me to run the game at a stable 1440p60 with no issue beside odd polygon tearing post-death.
Author
Owner

@LionHeartP commented on GitHub (Oct 4, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

Sadly none of your builds work for me.
fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)

And when I try with bash I just get a coredump

Nobara 40
Kernel 6.11.2
GPU 7900XTX

<!-- gh-comment-id:2394420453 --> @LionHeartP commented on GitHub (Oct 4, 2024): > @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with `env -u DISPLAY ./Shadps4.qt.AppImage`. It also included your patch. Sadly none of your builds work for me. `fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)` And when I try with bash I just get a coredump Nobara 40 Kernel 6.11.2 GPU 7900XTX
Author
Owner

@Oroborius commented on GitHub (Oct 4, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

Sadly none of your builds work for me. fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)

And when I try with bash I just get a coredump

Nobara 40 Kernel 6.11.2 GPU 7900XTX

I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using this build and patching the thread_management.cpp with the patch above and running with the command env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4 as it grants more performance and fixes the performance tanking bug.

<!-- gh-comment-id:2394462831 --> @Oroborius commented on GitHub (Oct 4, 2024): > > @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with `env -u DISPLAY ./Shadps4.qt.AppImage`. It also included your patch. > > Sadly none of your builds work for me. `fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)` > > And when I try with bash I just get a coredump > > Nobara 40 Kernel 6.11.2 GPU 7900XTX I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using [this](https://github.com/shadps4-emu/shadPS4/pull/1146) build and patching the `thread_management.cpp` with the patch above and running with the command `env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4` as it grants more performance and fixes the performance tanking bug.
Author
Owner

@LionHeartP commented on GitHub (Oct 5, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

Sadly none of your builds work for me. fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)
And when I try with bash I just get a coredump
Nobara 40 Kernel 6.11.2 GPU 7900XTX

I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using this build and patching the thread_management.cpp with the patch above and running with the command env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4 as it grants more performance and fixes the performance tanking bug.

Got it running following these instructions, sadly radv can't render Bloodborne properly yet.

<!-- gh-comment-id:2395112577 --> @LionHeartP commented on GitHub (Oct 5, 2024): > > > @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with `env -u DISPLAY ./Shadps4.qt.AppImage`. It also included your patch. > > > > > > Sadly none of your builds work for me. `fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)` > > And when I try with bash I just get a coredump > > Nobara 40 Kernel 6.11.2 GPU 7900XTX > > I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using [this](https://github.com/shadps4-emu/shadPS4/pull/1146) build and patching the `thread_management.cpp` with the patch above and running with the command `env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4` as it grants more performance and fixes the performance tanking bug. Got it running following these instructions, sadly radv can't render Bloodborne properly yet.
Author
Owner

@LV99VIVI commented on GitHub (Oct 5, 2024):

thx i was able to get past black screen on latest linux mint cinnamon using quangs build with just doubleclicking. pretty sure i dont have wayland

<!-- gh-comment-id:2395139234 --> @LV99VIVI commented on GitHub (Oct 5, 2024): thx i was able to get past black screen on latest linux mint cinnamon using quangs build with just doubleclicking. pretty sure i dont have wayland
Author
Owner

@Oroborius commented on GitHub (Oct 8, 2024):

@Oroborius If you use my builds, it don't need Gamescope to run under Wayland, just need to run with env -u DISPLAY ./Shadps4.qt.AppImage. It also included your patch.

Sadly none of your builds work for me. fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)
And when I try with bash I just get a coredump
Nobara 40 Kernel 6.11.2 GPU 7900XTX

I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using this build and patching the thread_management.cpp with the patch above and running with the command env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4 as it grants more performance and fixes the performance tanking bug.

Latest pre-release actually appears to fully address the random lag issue for the most part, however I believe the lag issue is more prone to uncleared resources on the system due to the nature of how shadps4 closes/crashes when ran through the terminal like this, possibly due to the XDG environment. However crashes seem to be effectively gone from the latest pre-releases so I don't think this pull request is needed anymore as everything in pre-release has the fixes from this PR in some form or another. However the same patch to thread_management.cpp is required to boot under Wayland (or at least Arch KDE Wayland) from my testing. Hope they start including this patch or at least a form of it in the AppImages soon.

<!-- gh-comment-id:2400947258 --> @Oroborius commented on GitHub (Oct 8, 2024): > > > @Oroborius If you use my [builds](https://github.com/ngoquang2708/shadPS4/actions), it don't need Gamescope to run under Wayland, just need to run with `env -u DISPLAY ./Shadps4.qt.AppImage`. It also included your patch. > > > > > > Sadly none of your builds work for me. `fish: Job 1, 'env -u DISPLAY ./Shadps4-qt.App…' terminated by signal SIGSEGV (Address boundary error)` > > And when I try with bash I just get a coredump > > Nobara 40 Kernel 6.11.2 GPU 7900XTX > > I actually just did some further testing and actually found this build has the same issues as main branch and other older builds. You're better off using [this](https://github.com/shadps4-emu/shadPS4/pull/1146) build and patching the `thread_management.cpp` with the patch above and running with the command `env -u WAYLAND_DISPLAY env XDG_SESSION_TYPE=x11 gamescope ./path/to/shadps4` as it grants more performance and fixes the performance tanking bug. Latest pre-release actually appears to fully address the random lag issue for the most part, however I believe the lag issue is more prone to uncleared resources on the system due to the nature of how shadps4 closes/crashes when ran through the terminal like this, possibly due to the XDG environment. However crashes seem to be effectively gone from the latest pre-releases so I don't think this pull request is needed anymore as everything in pre-release has the fixes from this PR in some form or another. However the same patch to `thread_management.cpp` is required to boot under Wayland (or at least Arch KDE Wayland) from my testing. Hope they start including this patch or at least a form of it in the AppImages soon.
Author
Owner

@ngoquang2708 commented on GitHub (Oct 9, 2024):

@Oroborius Do you mean you can boot BB on Wayland, via XWayland, using "main + thread_management patch"?

<!-- gh-comment-id:2401188189 --> @ngoquang2708 commented on GitHub (Oct 9, 2024): @Oroborius Do you mean you can boot BB on Wayland, via XWayland, using "main + thread_management patch"?
Author
Owner

@Oroborius commented on GitHub (Oct 9, 2024):

@Oroborius Do you mean you can boot BB on Wayland, via XWayland, using "main + thread_management patch"?

Yes, thread_management patch is required for Linux or at least arch wayland. Then we use a Wayland display in an XWayland xdg environment with gamescope to properly boot. Even if we have the thread_management patch it wont boot unless we have the gamescope/XDG environment

Even works for latest pre-release.

<!-- gh-comment-id:2403581403 --> @Oroborius commented on GitHub (Oct 9, 2024): > @Oroborius Do you mean you can boot BB on Wayland, via XWayland, using "main + thread_management patch"? Yes, thread_management patch is required for Linux or at least arch wayland. Then we use a Wayland display in an XWayland xdg environment with gamescope to properly boot. Even if we have the thread_management patch it wont boot unless we have the gamescope/XDG environment Even works for latest pre-release.
Author
Owner

@C0rn3j commented on GitHub (Dec 7, 2024):

Bloodborne CUSA00900 1.09 black screen on Arch Linux with Plasma Wayland session with Nvidia on github.com/shadps4-emu/shadPS4@dad5953e8c built from AUR/shadps4-git.

The pthread patches mentioned above should no longer be needed after https://github.com/shadps4-emu/shadPS4/pull/1440

shad_log.txt

EDIT: Judging by the log, I am missing some modules, will retry later...

EDIT2: Still a black screen, new log with all the required modules -
shad_log.txt

EDIT3: With CUSA03173 1.00 I instead get in a 100% CPU on one thread loop that spams 100MB of logs in a minute -
shad_log.txt

<!-- gh-comment-id:2525340259 --> @C0rn3j commented on GitHub (Dec 7, 2024): Bloodborne CUSA00900 1.09 black screen on Arch Linux with Plasma Wayland session with Nvidia on https://github.com/shadps4-emu/shadPS4/commit/dad5953e8c3cca86152d85a92b6415a3c8f8e80f built from AUR/shadps4-git. The pthread patches mentioned above should no longer be needed after https://github.com/shadps4-emu/shadPS4/pull/1440 [shad_log.txt](https://github.com/user-attachments/files/18050180/shad_log.txt) EDIT: Judging by the log, I am [missing some modules](https://github.com/shadps4-emu/shadps4-game-compatibility/blob/main/README.md#info), will retry later... EDIT2: Still a black screen, new log with all the required modules - [shad_log.txt](https://github.com/user-attachments/files/18051601/shad_log.txt) EDIT3: With CUSA03173 1.00 I instead get in a 100% CPU on one thread loop that spams 100MB of logs in a minute - [shad_log.txt](https://github.com/user-attachments/files/18051640/shad_log.txt)
Author
Owner

@7oxicshadow commented on GitHub (Dec 8, 2024):

Bloodborne CUSA00900 1.09 black screen on Arch Linux with Plasma Wayland session with Nvidia on dad5953 built from AUR/shadps4-git.

The pthread patches mentioned above should no longer be needed after #1440

shad_log.txt

EDIT: Judging by the log, I am missing some modules, will retry later...

EDIT2: Still a black screen, new log with all the required modules - shad_log.txt

EDIT3: With CUSA03173 1.00 I instead get in a 100% CPU on one thread loop that spams 100MB of logs in a minute - shad_log.txt

Have you tried launching using the following command:

env -u DISPLAY ./name of binary here

<!-- gh-comment-id:2526272232 --> @7oxicshadow commented on GitHub (Dec 8, 2024): > Bloodborne CUSA00900 1.09 black screen on Arch Linux with Plasma Wayland session with Nvidia on [dad5953](https://github.com/shadps4-emu/shadPS4/commit/dad5953e8c3cca86152d85a92b6415a3c8f8e80f) built from AUR/shadps4-git. > > The pthread patches mentioned above should no longer be needed after #1440 > > [shad_log.txt](https://github.com/user-attachments/files/18050180/shad_log.txt) > > EDIT: Judging by the log, I am [missing some modules](https://github.com/shadps4-emu/shadps4-game-compatibility/blob/main/README.md#info), will retry later... > > EDIT2: Still a black screen, new log with all the required modules - [shad_log.txt](https://github.com/user-attachments/files/18051601/shad_log.txt) > > EDIT3: With CUSA03173 1.00 I instead get in a 100% CPU on one thread loop that spams 100MB of logs in a minute - [shad_log.txt](https://github.com/user-attachments/files/18051640/shad_log.txt) Have you tried launching using the following command: env -u DISPLAY ./name of binary here
Author
Owner

@C0rn3j commented on GitHub (Dec 8, 2024):

unset DISPLAY; shadps4

Awesome, unsetting DISPLAY does work!
I did see it mentioned here but to be frank my brain just skipped it as an AppImage solution.

The sound gets looped like an early 2000s techno music at times(most of the time except cutscenes pretty much), but it does run, thanks again!

image

<!-- gh-comment-id:2526281589 --> @C0rn3j commented on GitHub (Dec 8, 2024): `unset DISPLAY; shadps4` Awesome, unsetting DISPLAY does work! I did see it mentioned here but to be frank my brain just skipped it as an AppImage solution. The sound gets looped like an early 2000s techno music at times(most of the time except cutscenes pretty much), but it does run, thanks again! ![image](https://github.com/user-attachments/assets/57e358df-4bab-41fe-b9f8-cc77bd3d8ec3)
Author
Owner

@ngoquang2708 commented on GitHub (Dec 8, 2024):

@C0rn3j Are your GPU Nvidia?

<!-- gh-comment-id:2526291473 --> @ngoquang2708 commented on GitHub (Dec 8, 2024): @C0rn3j Are your GPU Nvidia?
Author
Owner

@C0rn3j commented on GitHub (Dec 8, 2024):

@ngoquang2708 yup, you can get my system specifics from the logs I posted above or from any of my recently opened issues i.e. https://github.com/shadps4-emu/shadPS4/issues/1703

<!-- gh-comment-id:2526292037 --> @C0rn3j commented on GitHub (Dec 8, 2024): @ngoquang2708 yup, you can get my system specifics from the logs I posted above or from any of my recently opened issues i.e. https://github.com/shadps4-emu/shadPS4/issues/1703
Author
Owner

@ngoquang2708 commented on GitHub (Dec 8, 2024):

Seem like NVidia specific issue.

<!-- gh-comment-id:2526292799 --> @ngoquang2708 commented on GitHub (Dec 8, 2024): Seem like NVidia specific issue.
Author
Owner

@C0rn3j commented on GitHub (Dec 8, 2024):

Tried on github.com/shadps4-emu/shadPS4@fea2593ab4, game freezes when first cutscene finishes playing, I am able to get a couple lagged frames in before it freezes for sure.

shad_log.txt

Should I open a new bug report for the freeze and possibly for the audio being buggy, since it's not exactly this black screen issue with DISPLAY anymore?

Couldn't find a relevant one.

<!-- gh-comment-id:2526304983 --> @C0rn3j commented on GitHub (Dec 8, 2024): Tried on https://github.com/shadps4-emu/shadPS4/commit/fea2593ab4be8638426e4f608ebbe2314d83d9f6, game freezes when first cutscene finishes playing, I am able to get a couple lagged frames in before it freezes for sure. [shad_log.txt](https://github.com/user-attachments/files/18053488/shad_log.txt) Should I open a new bug report for the freeze and possibly for the audio being buggy, since it's not exactly this black screen issue with DISPLAY anymore? Couldn't find a relevant one.
Author
Owner

@7oxicshadow commented on GitHub (Dec 8, 2024):

Tried on fea2593, game freezes when first cutscene finishes playing, I am able to get a couple lagged frames in before it freezes for sure.

shad_log.txt

Should I open a new bug report for the freeze and possibly for the audio being buggy, since it's not exactly this black screen issue with DISPLAY anymore?

Couldn't find a relevant one.

noticed you have already posted in #1704 but it is worth rebuilding with the flag mentioned in that bug disabled to see if it solves your issue

<!-- gh-comment-id:2526320674 --> @7oxicshadow commented on GitHub (Dec 8, 2024): > Tried on [fea2593](https://github.com/shadps4-emu/shadPS4/commit/fea2593ab4be8638426e4f608ebbe2314d83d9f6), game freezes when first cutscene finishes playing, I am able to get a couple lagged frames in before it freezes for sure. > > [shad_log.txt](https://github.com/user-attachments/files/18053488/shad_log.txt) > > Should I open a new bug report for the freeze and possibly for the audio being buggy, since it's not exactly this black screen issue with DISPLAY anymore? > > Couldn't find a relevant one. noticed you have already posted in #1704 but it is worth rebuilding with the flag mentioned in that bug disabled to see if it solves your issue
Author
Owner

@C0rn3j commented on GitHub (Dec 8, 2024):

@7oxicshadow good guess, I get past the character creator now.

Audio is still buggy as hell.

I wanted to just do this through the PKGBUILD so I ended up saving this as cmake.patch

From 7276853b029a816e253da351694eeda09812de74 Mon Sep 17 00:00:00 2001
From: IndecisiveTurtle <geoster3d@gmail.com>
Date: Sun, 1 Dec 2024 16:19:50 +0200
Subject: [PATCH 1/4] page_manager: Enable userfaultfd by default

* Much faster than page faults and causes less problems
---
 CMakeLists.txt                  | 4 ++++
 src/video_core/page_manager.cpp | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 378b8f78d5..ae6d1d74e0 100755
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -875,6 +875,10 @@ target_link_libraries(shadps4 PRIVATE Boost::headers GPUOpen::VulkanMemoryAlloca
 target_compile_definitions(shadps4 PRIVATE IMGUI_USER_CONFIG="imgui/imgui_config.h")
 target_compile_definitions(Dear_ImGui PRIVATE IMGUI_USER_CONFIG="${PROJECT_SOURCE_DIR}/src/imgui/imgui_config.h")

+if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux")
+    target_compile_definitions(shadps4 PRIVATE ENABLE_USERFAULTFD)
+endif()
+
 if (APPLE)
   option(USE_SYSTEM_VULKAN_LOADER "Enables using the system Vulkan loader instead of directly linking with MoltenVK. Useful for loading validation layers." OFF)
   if (USE_SYSTEM_VULKAN_LOADER)

Adding "cmake.patch" to sources in the PKGBUILD

An extra 'SKIP' to theb2sums array.

And adding patch -Rp1 -i "${srcdir}"/cmake.patch to prepare() to reverse patch it in.

<!-- gh-comment-id:2526333749 --> @C0rn3j commented on GitHub (Dec 8, 2024): @7oxicshadow good guess, I get past the character creator now. Audio is still buggy as hell. I wanted to just do this through the PKGBUILD so I ended up saving this as `cmake.patch` ```diff From 7276853b029a816e253da351694eeda09812de74 Mon Sep 17 00:00:00 2001 From: IndecisiveTurtle <geoster3d@gmail.com> Date: Sun, 1 Dec 2024 16:19:50 +0200 Subject: [PATCH 1/4] page_manager: Enable userfaultfd by default * Much faster than page faults and causes less problems --- CMakeLists.txt | 4 ++++ src/video_core/page_manager.cpp | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 378b8f78d5..ae6d1d74e0 100755 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -875,6 +875,10 @@ target_link_libraries(shadps4 PRIVATE Boost::headers GPUOpen::VulkanMemoryAlloca target_compile_definitions(shadps4 PRIVATE IMGUI_USER_CONFIG="imgui/imgui_config.h") target_compile_definitions(Dear_ImGui PRIVATE IMGUI_USER_CONFIG="${PROJECT_SOURCE_DIR}/src/imgui/imgui_config.h") +if (${CMAKE_SYSTEM_NAME} STREQUAL "Linux") + target_compile_definitions(shadps4 PRIVATE ENABLE_USERFAULTFD) +endif() + if (APPLE) option(USE_SYSTEM_VULKAN_LOADER "Enables using the system Vulkan loader instead of directly linking with MoltenVK. Useful for loading validation layers." OFF) if (USE_SYSTEM_VULKAN_LOADER) ``` Adding `"cmake.patch"` to sources in the PKGBUILD An extra `'SKIP'` to theb2sums array. And adding `patch -Rp1 -i "${srcdir}"/cmake.patch` to prepare() to reverse patch it in.
Author
Owner

@Hermiten commented on GitHub (Dec 14, 2024):

This issue is outdated.
To answer the first post, many games don't work on Linux, especially before version 0.4, which is why you were stuck on black screen.

<!-- gh-comment-id:2543108916 --> @Hermiten commented on GitHub (Dec 14, 2024): This issue is outdated. To answer the first post, many games don't work on Linux, especially before version 0.4, which is why you were stuck on black screen.
Author
Owner

@C0rn3j commented on GitHub (Dec 14, 2024):

I've opened #1781 to track the Wayland blackscreen issue when DISPLAY is set then.

<!-- gh-comment-id:2543121284 --> @C0rn3j commented on GitHub (Dec 14, 2024): I've opened #1781 to track the Wayland blackscreen issue when DISPLAY is set then.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/shadPS4#317
No description provided.