-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DisplayServer: Don't fallback to headless #62556
DisplayServer: Don't fallback to headless #62556
Conversation
How does this PR compare to #59074? |
Ah thanks, I knew I remembered a PR that did something like this but couldn't find it again. I think my solution is more elegant, poke @RandomShaper for cross-review. |
To do a recap on how this PR compares to mine:
Regarding 1), I can't really tell which approach is better. Regarding 2), if it's still relevant for its purpose, I'd include it in whatever PR we end up merging. |
For 1., this is seems to be the intended design that headless should always be last: godot/servers/display_server.cpp Line 793 in 20d4c66
But might need double checking. I could add e.g. an assert that the name of the last index DisplayServer is headless. For 2., I had a crash but I fixed it with #62555. I think it's nicer to let Godot try to exit gracefully than doing a hard exit, so we can properly do finalize steps. |
Fair enough. If we can somehow check under |
Unless users requested the headless driver specifically, they expect to either see a window, or that the process terminates if there's an error. Currently it would fallback to headless so they'd unexpectedly get a valid headless instance if their DisplayServer failed initializing (e.g. missing Vulkan support). Fixes godotengine#58414.
11a978b
to
833c786
Compare
Added a couple |
Unless users requested the headless driver specifically, they expect to either
see a window, or that the process terminates if there's an error.
Currently it would fallback to headless so they'd unexpectedly get a valid headless
instance if their DisplayServer failed initializing (e.g. missing Vulkan support).
Depends on #62555, otherwise it's crashing on exit in the case where it couldn't initialize a DisplayServer.
With #62555, it prints an error instead (which itself is likely a bug that could be fixed independently):
The last
ERROR
here is printed using the fallback.