godot
godot copied to clipboard
godotengine
[WIP] Implement a Wayland DisplayServer
Resolves godotengine/godot-proposals#990.
Depends on #68944.
(This post will be updated over time to reflect the current status of the project. I hope it won't feel weird whenever that happens.)
Wayland specific issues
-
The cursor is blurry on HiDPI. This is a known issue but it's not a huge priority.
-
At least on sway borderless windows don't work anymore. I'm aware of this issue and a fix is planned.
-
Tablet support(ed) very basic setups (I don't have fancy tablets), failing to properly handle multiple tools. Untested and probably not working after the refactoring
-
DRI_PRIMEdetection is not yet implemented (gotta find a way to test it) -
There have been multiple reports of corrupted graphics with this backend and the Vulkan driver. The cause of this is yet unknown, but seems to happen only in iGPU + dGPU scenarios. This issue has been confirmed with other Wayland + Vulkan programs, hinting at a more generic issue, perhaps with mesa. Update: It looks like this issue might be fixed in a later mesa update. Currently waiting for further confirmation.
-
All processing stops once the window is hidden. Currently there's no way of preventing this state. See: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/199 and https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/38
-
On Sway, resizing the window through
window_set_sizeacts weirdly, as if it were set only temporarily. This might be a compositor bug (could also be improper use of the API, don't remember if I tested). This method got disabled as I don't think we're supposed to resize toplevels non-interactively. -
On Sway, DnD doesn't update the cursor properly. This may be a compositor bug.
Miscellaneous notes
-
Scrolling on a touchpad is a little bit too fast. This is a generic issue (see #49873), but gesture support, already implemented through the pointer gestures protocol, alleviates it.
-
The splash doesn't resize. This means that tiling WMs will have a wrongly sized window until the end of loading. There's no clean way of improving this and, while hacks are definitely possible, I'm not sure that it's currently worth it.
The aim of this PR is to eventually implement a fully working DisplayServer compatible with the Wayland protocol on Godot 4.x, which had architectural changes that led to the closing of #27463.
This backend is available only in single-window mode due to incompatibilities with Wayland's and Godot's windowing API.
It is currently beta quality. It's definitely usable, albeit with some features missing. The main focus of this phase is testing, fixing bugs, matching the behaviour to the documentation or the X11 implementation and implementing the few stubs left.
Virtual keyboard support is possible and planned.
Animated cursors could be implemented (perhaps even easily) but they're extremely low priority.
Someone proposed xdg-desktop-portal, but that is out of scope regarding this implementation and should be implemented separately.
I've added some simple SCons builders that generate protocol wrappers through wayland-scanner.
Wayland and X11 are both enabled by default in the build system and the first that works will be selected at runtime, although expect errors in the log for now as they have to literally fail to fallback to either one.
The client library gets loaded through some dlopen wrappers and all Wayland stuff (except currently libdecor) is embedded into thirdparty/linux_headers/wayland, allowing dependency-free building (but not running).
Note that wayland-scanner is still required for now at build time. I guess we could do some build-and-run trickery, dunno.
Some methods aren't implemented yet (left as stubs). Namely:
-
window_set_mouse_passthrough(Wayland doesn't support polygonal regions, only rect regions.) -
window_set_ime_active(requires implementing text-input-unstable-v3; it can and will be done) -
window_set_ime_position(same as above) -
screen_get_usable_rect(could be implemented throughconfigure_bounds, but it'd come from the window's perspective, as there's no way to ask the free area for a particular screen.)
Thanks to:
- @ddevault and @toger5, from which I initially took the key mapping code.
- @dos1 for helping me with many, long, headache inducing things.
- @smohantty for some very small build fixes.
- @vmedea for a bunch of very useful fixes.
I'm always open to external contributions (especially as I've never worked on anything like this before) be it patches, testing, reviews, general technical help or even just moral support, they're all very appreciated!
@Riteo , I am working on adding a wayland backend to linuxbsd platform for platyform. Good that you already have a working prototype with vulkan . Would love to contribute to avoid duplication of effort.
@smohantty if you want to contribute for now I guess that you could wait for the new, asynchronous prototype (I'm working on it right now, I'm free pretty much only on late fridays and the weekend, sorry about that) and maybe review it then? Or I guess you could also share any findings you had or say what you think of the proposed new architecture in the PR.
OK, I moved everything into another thread, but it looks like call_deferred, used for window callbacks, can't be always used. For example when running a scene it prints ERROR: Do not use progress dialog (task) while flushing the message queue or using call_deferred()!. At least now it doesn't crash anymore when you move the pointer too much though.
Update on that: the issue is not only caused by window rect changes but also by inputs in general, as the input dispatching function uses call_deferred and it's called by the event thread too. I might have to add some sort of event queue in the main thread and dispatch it there if I don't find a better solution.
Following the recent issue with call_deferred and ProgressDialog, I've decided that I'll try implementing an actual event queue, maybe even just wrapping wayland events for handling in the main thread. I previously discarded this idea since I was sure that everything could've been done off-thread and didn't like the idea of adding yet another event queue when we already got Input and MessageQueue, but I've got to pick it back up due to these assumptions being wrong.
@smohantty if you want to contribute for now I guess that you could wait for the new, asynchronous prototype (I'm working on it right now, I'm free pretty much only on late fridays and the weekend, sorry about that) and maybe review it then? Or I guess you could also share any findings you had or say what you think of the proposed new architecture in the PR.
Currently, I am looking at kWayland(https://github.com/KDE/kwayland) and qtWayland(https://github.com/qt/qtwayland) for reference as they have implemented all the features ( multi-window , server and client-side decoration async event etc) will be helpful in designing wayland integration in godot.
@smohantty are you sure we can reference them? They look to be mostly GPL code, a license incompatible with Godot's MIT license. Also, I'm not sure if QT's architecture might be comparable with Godot's. As you can see, there are quite a few shortcomings and limitation to take in considerations that are quite unique.
@smohantty are you sure we can reference them? They look to be mostly GPL code, a license incompatible with Godot's MIT license. Also, I'm not sure if QT's architecture might be comparable with Godot's. As you can see, there are quite a few shortcomings and limitation to take in considerations that are quite unique.
The reference is just to understand the full feature set we have to provide not to copy the implementation. The most of the wayland integration i have went through provides a logical window concept as well as some kind of parent-child window relationship to support multiple windows. If we can code a wayland client in isolation which provides interface that play nicely with the DisplayServer interface then it will be good as it will not bloat the wayland Displayserver class. The Server will use the logical window concept and adds hook for the events .
one more wayland integration for reference (https://github.com/Enlightenment/efl/tree/master/src/lib/ecore_wl2)
So am just going through all different implementations to come up with all the building blocks required to provide all the features we need and at the same time easy to maintain as well as extend in the future.
My rough idea is to develop the Wayland support as a separate module/library which can be consumed by the DisplayServer. Would love to hear your thoughts about it.
@smohantty mhh, what you're proposing is actually kind of done in other parts of the engine, look in the drivers folder of the source code for some examples. I thought of doing something similar but in the end doing what you're proposing would risk making all methods of DisplayServerWayland just one or two calls to this hypothetical class, which for something as specialized as a Wayland display server would just add needless complexity. X11DisplayServer, for example, does all X11 stuff inside of it, without a specialized driver.
At most, in my opinion, we could do just a WaylandEventQueue class, or something like that, that implements all wrapped events (which after some thinking seems like the safest thing to do at this point IMO) and gives a convenient interface for consuming Wayland events only, but that could be split at the end if considered too bulky.
For now, I'd make everything in the DisplayServerWayland, see if it works in the first place, because as you can see, things that could've sounded good enough weren't due to unexpected constraints in Godot's architecture, and then clean-up/optimize/split/whatever, because we might spend a lot of time polishing something, plugging it into WaylandDisplayServer and see it fail gloriously as it did with me twice.
Maybe it could be me that I'm always too afraid of over-engineering things, but I think that at this point this is the best route to take IMO.
Ok, new update: I've implemented a very basic message queue and it looks like it works. The commit message should contain some info on roughly what I did, still in the usual brain dump format used by this update too.
As usual, after some other thinking, I changed the way things will go, understanding that if I were to wrap all Wayland events I would've reimplemented wl_display_dispatch, which is not very useful. :p
That's why I'll be just implementing the basic messages that the editor needs to know about in the main thread, which is pretty much stuff with callbacks (window changes, input events, etc), so that on the Wayland layer we can do everything that has to be immediate as soon as possible (especially to avoid filling up the oh-so-precious and limited Wayland event buffer), leaving the main thread all the time it needs to do whatever it pleases, and to let all of the scene tree and whatever know that these things happened, while the List used for the queue keeps growing without any issue (just like X does, AFAIK).
Right now the only message implemented and working is the window rect change message, which makes the DisplayServer rescale the buffer on window resize.
I've still not tested this queue extensively, I've pretty much just rescaled the window a bunch of times and called it a day, as input dispatching is currently temporarily #if 0'ed out. I'll probably implement it tomorrow (read: later in the day, I'm well past 0:00 AM), "it shouldn't take long(tm)", but as usual it's very, very, late and I'm pretty tired.
Synchronization is still pretty sketchy, but we've still got time to polish it and make absolutely sure that there won't be race conditions or stalls, also looking where to use the right mutexes at the right place, instead of one monolithic WaylandState mutex, which, very superficially, I don't think would be the right solution.
Closing up, I feel like I've finally gone out of the loop of thinking a lot about how to do something "the right way", implementing it and seeing it fail gloriously, which was pretty frustrating and took a lot of time. Instead, I found that concentrating first on making it work and eventually polishing seems to work pretty nicely for now, especially for my mental health. So there's the possibility that I might make certain choices in the moment without thinking about it too much just to make something work, and only then then try to improve/clean/refactor it.
I've implemented scroll and modifier support. There's just this weird issue where non physical shortcuts get registered as lowercase. It may be something very stupid that I did, but for now I'll go to sleep.
Although the running game window is kinda broken (on sway its buffer is offset for some reason), we're slowly getting closer to actually getting something that can be tried by more people!
Edit: Fixed both of those issues.
I've just added double click and keyboard support, so technically the editor should be just enough usable to do something. There's still a lot missing, but we're slowly getting there.
I'm adding window event support too, but if on sway the window gets tabbed out, its focus out event isn't handled until it is shown again. Probably process_events doesn't get called and the message queue isn't read.
For some reason context_vulkan->window_resize() breaks everything when the renderer is set in multithreaded mode. I can see that the X11 display server did nothing in particular regarding renderer synchronization, but I have to do RenderingServerDefault::get_singleton()->sync() before resizing the window to avoid a race condition.
I avoided implementing the above mentioned fix for now, as I'm uncertain whether it's actually the right solution.
After attempting to implement other things, I think that the prototype (read: "messy code") stage is currently over. Everything else that has to be implemented depends either on some external library or is complex enough to deserve some more well structured code.
So for now, while trying to add more complex features, I'll try to refactor/cleanup/fix some things and slowly refine the whole implementation. I might also take more into consideration the older codebases, since I've built an idea of how Wayland works and stuff like clipboard support and advanced pointer features should be the same.
The only big problem left is, IMO, multiple window support. The difference between popups and toplevels in XDG shell imposes some weird restrictions that will be interesting to fix.
@smohantty I noticed that you've been making some changes by yourself on your fork of my branch (namely, cursor support). I have no idea if you want to keep these for yourself, but in any case if you're interested in adding support for something in this PR let me know, in order to avoid stepping on our shoes. Also, sorry for the rebase! I did not expect you making other changes as you went silent.
Welp, I tried making the CI work with this PR for fun by adding the relevant dependencies, but it somehow messes up. I guess that the code generated on my machine uses functions not available on the older wayland-client library that Ubuntu provides.
This is the same error I get if I try to compile on Fedora 35 where the 1.19.0 version of libwayland-client is installed. I know Ubuntu jammy have the 1.20.0 version of libwayland-client, but I don't know how to setup in this CI.
@roberti42 I guess that this should be fixed once dynamic code generation is added. It isn't high in my todo list, but if that does improve testing, I can try to add it ASAP. I think that @ddevault made a scons module for that.
@Riteo what is dynamic code generation? Of course I can compile it using wayland 1.20.0, but I can't run because my system runs on 1.19.0
@roberti42 I should've explained it before, sorry.
Wayland protocols are defined in an XML file. The actual API is generated using wayland-scanner, a program made just for that. It looks like it's pretty common to run it during the build process, and is a practice also done in the older PRs too. I always wondered why it was so common and I never looked into it, but I think this is the reason, as those C files are generated by it.
@Riteo ok now I see, thank you for the explanation. Then you need to ensure that generate-api.sh will use wayland-scanner version 1.19.0, I suppose.
This is how I've done it my system. Because I have version 1.19.0 in /usr/bin and 1.20.0 in /usr/local/bin, I put /usr/bin before everything else in PATH:
cd thirdparty/wayland-protocols/xdg-shell
export PATH=/usr/bin:${PATH}
generate-api.sh
And now it compiles and runs (both tools and editor), although the fonts are pixelated.
@Riteo yes. I have a 4k monitor, but when I start Godot with --display-driver wayland it seems like it is running at 96 DPI.
@roberti42 makes sense, I haven't implemented HiDPI support yet as I don't have a HiDPI monitor. If you wish I can do it and let you test the implementation.
Quick warning for anyone wanting to try this PR right now: currently the program crashes with more than one screen. The reason for the crash is an accidental preservation of the assumption that the screen list's elements have a constant address after I ported the code from using a List to a LocalVector for the screen list. I'll probably push a fix tomorrow. In the meanwhile, disconnect any extra screen if you really want to try it right now.
Update: the program does not crash anymore with more than one screen.
Also, on a different note, I'm sure I can improve a lot the window screen detection algorithm, which left me really unsatisfied. To not base myself on assumptions I'm working on a way of working with a 2x2 grid of virtual displays. I know that the current implementation of the algorithm's kinda floppy, I'm sorry.
Update: I've stubbed out window_get_current_screen as it would be too complex for very little usefulness, as we can only know if the window entered or leaved a screen, thus making it very hard if not impossible to know the screen on which it is on. I'll look on possible workarounds or partial solutions later, in the meanwhile I'll work on other features, especially now that we have a popup flag for windows.
Update on output scale support: Wayland seems to implement it by basically dividing the logical screen size by the scale factor (eg. 1920x1080 screen, 960x540 logical size), thus making windows smaller, and allowing to attach bigger buffers achieving some sort of supersampling. I think that to implement this correctly it would be more elegant to implement it in the core, perhaps reading the new screen_get_scale, otherwise I might need to do some nasty conversions eg. for pointer positions, as a window's size currently depends on the buffer. Thus, I'm postponing output scaling support in order to work on other things, only later looking for a good way of handling it.
What are you planning to do concerning window decorations? will there be a native window header? Or are you going to rely on the xdg-decoration protocol?
Regarding CSD and SSD - I recommend supporting the xdg-decoration spec, which allows compositors that support server side decorations to have them, while compositors that don't (notably Mutter/GNOME) get client side decorations. This seems to be the way to go, considering the community is almost split down the middle. The xdg-decoration spec mandates CSD anyway, as long as the compositor does not support SSD.
Thank you for all your work by the way, it is highly appreciated! I would love to help with this effort. I have two monitors, one 4K and one 1440p. Although I am a seasoned developer, I suspect I'm a bit too green on the technicalities of the engine to be of much help in that regard.
@Lampomaniac I'll probably do that then, thanks for the tip!
@smohantty just to be sure, will you ever make a PR for that cursor commit or are you gonna keep it for yourself? That can absolutely be the case, mind you, I just want avoid doing the same stuff that someone else is doing. Since it's been a while I'm gonna merge the latest changes and then work on something, if that messes up your work, please let me know.
Oh, sorry for the double post, I forgot to answer to the second part of your message @Lampomaniac: if you don't want to help with the implementation (which is totally understandable), even just testing is appreciated! Just one thing, by "seasoned developer", do you mean that you're experienced with the Wayland protocol? If yes (if you want), would you tell me if you know whether it's possible, at least with a separate protocol I missed, to detect which screen a window covers the most?
I added partial mouse mode support in the form of pointer confinement and capturing, although the latter is pretty useless without relative pointer support, which I'll add next. For some reason, floating pointer confinement is broken on sway, and I think that it might be related to the issue I linked in 90dd228d6361e65db96331b752c2375ab0fd9c87's description, although I'm not 100% sure. Do other window managers (especially floating ones) have this issue too?
would you tell me if you know whether it's possible, at least with a separate protocol I missed, to detect which screen a window covers the most?
There's no spec that does that for you, to my knowledge anyway. It is doable using some math of and the xdg-output spec, although I am unsure of how well supported this spec is. The reason (I believe) you have to use this spec instead of wl_output is that it gives you logical sizes and positions.
@Lampomaniac are you sure that logical sizes and positions are enough to understand which screen is covered the most by a particular window? The only events we've got at our disposal are output enter/leave events, so unless there's a window covering a grid of screens (thus, surely covering fully at least one screen), I don't think its possible to gain useful information from them alone.
@smohantty a while ago I've asked you whether you were going to add cursor support yourself, since I noticed that you committed something concerning such feature in your fork. You've not answered since then, and I've got to a point where the next logical step is implementing it. Sorry if I do something you were willing to do.
As anticipated, I've implemented cursor theme and hiding support. This is a really big step forward, making not only the editor but a lot of games more usable too! I actually wanted to push this commit this morning after a quick post-sleep review, but I'm feeling quite happy with how it has come, so I'm taking the risk!
Although I've tried to keep my implementation reasonably compatible with DisplayServerX11's (heavily adapting some code too), I'm sure that somebody will find issues with their theme. For me, for example, there are two cursors missing even though I use Adwaita and the code uses DisplayServerX11's names and fallbacks. As we're getting more and more feature complete, testing is more and more encouraged!
Also, although I'm trying to not get the usual vicious cycle of refactoring, I'm aware of there being some (relatively) major issues here and there in the general structure of the program, such as dumping everything in platforms/linuxbsd without making separate subfolders for both the two DisplayServers, having some very sketchy threading, leaking somehow some input events and having either very long variable names or very short ones. The latter issue is also exacerbated by the leftovers of the old design, where there are long chains of structures which were meant to be passed to each Wayland event listener in order to have them work on their own isolated state, approach which resulted too limiting. I'm still finding the time and the right moment to clean up everything.
Hi Riteo,
Thank you very much for the time already spent, I (and I'm sure others) am (are) following you work with great interest 👍.
As you say you'd be interested for some people to test your current implementation, could you sketch a bit what your are willing to see in action? I mean, what to test, what is the most important and what did you struggle to implement?
A kind of check-list would be optimal, and/or a list of steps on how to test the relevant parts. If you can't describe what you want, maybe you can record your screen "clicking & dragging windows" so that I and others can reproduce the exact same test bench? As we have different setups this could be the best way to make sure no corner case is left out and outline some known bug.
Reproducible testcases would, in my opinion, be the best way to measure progress. Oh, and I almost forget, what kind of debug information would be of interest when observing a crash 😉.
Hi @dvergeylen, I've thought about it for a while and I think that for now I think that a more "random" testing might be better, since I'm not actually entirely sure on what to test, and a video wouldn't allow for random enough tests.
There are just a few things to take into consideration, namely the only known issue of some leaked references on exit and the list of unimplemented features I wrote into the OP: multiple windows, custom cursors, clipboard handling, HiDPI, keep screen on, DnD, touch input and client side decorations. If there's something I left out in this list, please let me know.
Update: The leaking references issue has been fixed.
Tip: since multiple windows support is broken, and navigating to the editor settings is kinda difficult, one might want to enable it by adding this to their editor settings file (usually located at ~/.config/godot/editor_settings-4.tres) under [resource]:
interface/editor/single_window_mode = true
Oh right, @dvergeylen, btw, regarding what debug information to send in case of a crash, all I usually need are reproduction steps and a backtrace of a debug build, usually dumped when the engine crashes.
are you sure that logical sizes and positions are enough to understand which screen is covered the most by a particular window? The only events we've got at our disposal are output enter/leave events, so unless there's a window covering a grid of screens (thus, surely covering fully at least one screen), I don't think its possible to gain useful information from them alone.
You might be right. You should be able to get an educated guess on which screen has the most coverage though, but I suspect another solution is preferrable. Many applications lazy out and always fullscreen on the first index display, if that is what you are trying to accomplish!
I am tempted to give client side decorations a go, by basically finding an MIT-licensed implementation and "pasting" it in. Foot for example (the terminal emulator that is) is a good candidate. I'll come back if I make some progress, but don't hold your breath!
@Lampomaniac don't worry, even just an attempt is highly appreciated! Anyways, what would be the external implmementation for? Wouldn't it enough to "just" add some buttons from our side, or is there more going on? Perhaps, based on my limited understanding, it could be better to add our own client decorations, as it would allow to potentially integrate it better with the engine, even just graphically. I'm gonna really throw a random guess, but I was thinking about putting the main viewport under a container with the status bar and buttons as regular Controls, but, again, I'm not sure.
@Riteo I think that might not be a good idea. It's important (in my opinion) to keep the CSD simple and recognizable. The plan isn't to literally copy someone else's CSDs, but rather use a proven, efficient and standards compliant implementation that we can then style as we please. The more I've though about it, the more important it is to support the xdg-decoration spec as well. I'll see if I can't do both at the same time.
As I've said, I have practically no knowledge of the engine internals so I also might be shooting entirely in the dark. Guess we'll find out! 😁
After some thinking I'm pretty sure that I should properly handle multiple seats and that whatever worked before (if it even works anymore) worked by pure chance.
For the (understandably) unititiated, Wayland handles multiple input devices in one session through the concept of seats, comprising of an optional pointer, keyboard and touchscreen each. These seats are used by compositors like sway to effectively implement collaborative multi pointer support (you read that right).
I'm not sure on what behaviour to give it though, but I think that, in high level terms, it should revolve around the concept of a current seat: when the editor detects an interaction from a pointer, keyboard or (eventually) touch screen that is not the current one, it cleans up the current state (for example it unconstrains the pointer if applicable), looks for the seat from which this new pointer/keyboard came from, makes it the new current seat and sets its state like the previous one (like pointer constraint status etc), so that for whatever reason one might switch from one seat to the other cleanly and easily.
What do you guys think?
I've added a note about the state of the screens variable, probably the result of some excessive premature optimization which I thought would be trivial to do. I'll try to get the gist of profiling stuff and I'm thinking about the possibility of profiling my whole work before making sure that I consider it actually done.
I'm announcing it here in general to update the idea of when this will be considered done, as I want to push the best code possible. If I'm exaggerating and perhaps certain improvements might be done in a separate PR, please let me know.
I should've implemented popups and popup menus fully, with the exception of proper window manager side closing (eg. forced closing on unfocus) which causes a segfault or other stalls due to a sudden invalidation of the popup surface and some issues with the rendering device, among some more obscure bugs. Once they'll become stable enough I'll mark them as implemented in the OP.
I would've liked to update you before about what's going on but I was pretty busy (and by that I mean that I had very little contiguous free time at hand). But here we go, describing what's happened before, what is happening now what's going to happen in the future:
It all started with the popups. Apparently when closed they liked to fail in two different epic ways on sway and on Weston by crashing the client on the latter and by segfaulting the whole compositor on the former. I went trough a bunch of hoops talking to the guys over at #[email protected] and then to the guys at #[email protected], got told that I had to write a bunch of tests so that they could fix it and then I got real busy with real life.
Fastforward to now and the issue is seemingly gone. I literally opened my laptop to do some Godot/Wayland stuff for the first time in like a month and popups close flawlessly both on sway and on Weston. I updated a bunch of software but not Weston nor Sway and I'm not sure what was the cause, perhaps mesa or even the kernel? I'll try look into it further but now I can complete this port I guess.
Now that I can finally continue working on this I'll cleanup some of the mess I made debugging this weird issue, see what's left to implement and perhaps really finish this project on which I'm working on since the start of this year pretty much.
Thank you all for your patience.
Update: I slept and realized that I'm a dumbass.
I ran the editor in single-window mode because I'm dumb. The issue is still there.
I'll build the required mesa test and fix this mess.
Sorry again.
Please don't apologize, we are all super thankful for you to donate your time to work on this. Thank you for contributing.
New update: popups work very well on Weston, even better than sway... Except when they don't and stall any drawing to their buffer in the case of progress indicators, which for some reason work on sway.
Since beta is coming, I'm thinking of putting popups aside and polishing the rest of the single-window implementation (expecially with synchronization) in order to at least push some sort of wayland support for 4.0 which from my light testing on sway worked very well and was more than usable.
In that case the priorities would become: GLES3, code cleanup and accomodating wayland properly in the build system.
I already asked a bit on the developer chat and some people seemed favourable.
Any thoughts?
In that case the priorities would become: GLES3, code cleanup and accomodating wayland properly in the build system.
I already asked a bit on the developer chat and some people seemed favourable.
Any thoughts?
That sounds really good. It would be great to just have it in the code base. Other contributors then also have an easier time helping out with the popups if the main wayland code is on main. I am really excited to see the first wayland pr beeing merged!
Touch input (Postponed; I must find a way to emulate a touch screen as I don't have one)
You can simply use any wlroots-based compositor (Sway, phoc, Cage etc.) with X11 backend and this patch applied to wlroots. This will turn mouse events into (single) touch.
I just compiled your (@Riteo) branch. I am getting the following issue when running:
[UserName@fedora godot]$ ./bin/godot.linuxbsd.tools.64
Godot Engine v4.0.alpha.custom_build.d7893a031 - https://godotengine.org
wl_registry@2: error 0: invalid version for global wl_output (4): have 2, wanted 3
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0
Vulkan API 1.2.0 - Using Vulkan Device #0: Intel - Intel(R) Iris(R) Graphics 6100 (BDW GT3)
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _initialize_queues (drivers/vulkan/vulkan_context.cpp:1267)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
at: _window_create (drivers/vulkan/vulkan_context.cpp:1377)
ERROR: Can't show a Vulkan window.
at: show_window (platform/linuxbsd/display_server_wayland.cpp:1667)
ERROR: Condition "format == DATA_FORMAT_MAX" is true. Returning: INVALID_ID
at: screen_get_framebuffer_format (drivers/vulkan/rendering_device_vulkan.cpp:6801)
ERROR: Mismatch fragment shader output mask (1) and framebuffer color output mask (0) when binding both in render pipeline.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6265)
ERROR: Condition "format == DATA_FORMAT_MAX" is true. Returning: INVALID_ID
at: screen_get_framebuffer_format (drivers/vulkan/rendering_device_vulkan.cpp:6801)
ERROR: Mismatch fragment shader output mask (1) and framebuffer color output mask (0) when binding both in render pipeline.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6265)
ERROR: Condition "format == DATA_FORMAT_MAX" is true. Returning: INVALID_ID
at: screen_get_framebuffer_format (drivers/vulkan/rendering_device_vulkan.cpp:6801)
ERROR: Mismatch fragment shader output mask (1) and framebuffer color output mask (0) when binding both in render pipeline.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6265)
ERROR: Condition "format == DATA_FORMAT_MAX" is true. Returning: INVALID_ID
at: screen_get_framebuffer_format (drivers/vulkan/rendering_device_vulkan.cpp:6801)
ERROR: Mismatch fragment shader output mask (1) and framebuffer color output mask (0) when binding both in render pipeline.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6265)
ERROR: Condition "!windows.has(p_window)" is true. Returning: false
at: window_is_valid_swapchain (drivers/vulkan/vulkan_context.cpp:1421)
ERROR: Condition "!dl" is true.
at: draw_list_bind_render_pipeline (drivers/vulkan/rendering_device_vulkan.cpp:7330)
ERROR: Condition "!dl" is true.
at: draw_list_bind_index_array (drivers/vulkan/rendering_device_vulkan.cpp:7477)
ERROR: Condition "!dl" is true.
at: draw_list_bind_uniform_set (drivers/vulkan/rendering_device_vulkan.cpp:7404)
ERROR: Condition "!dl" is true.
at: draw_list_set_push_constant (drivers/vulkan/rendering_device_vulkan.cpp:7511)
ERROR: Condition "!dl" is true.
at: draw_list_draw (drivers/vulkan/rendering_device_vulkan.cpp:7529)
ERROR: Immediate draw list is already inactive.
at: draw_list_end (drivers/vulkan/rendering_device_vulkan.cpp:7838)
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (d7893a031f9e40feb51a28fb83f9613308ee9e60)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[1] /lib64/libc.so.6(+0x3ea70) [0x7ff298ab2a70] (??:0)
[2] /usr/lib64/libvulkan_intel.so(+0x1e0513) [0x7ff289e61513] (??:0)
[3] /usr/lib64/libvulkan_intel.so(+0x1e1036) [0x7ff289e62036] (??:0)
[4] /usr/lib64/libvulkan_intel.so(+0x1e7369) [0x7ff289e68369] (??:0)
[5] VulkanContext::flush(bool, bool) (/home/UserName/Projects/godot/drivers/vulkan/vulkan_context.cpp:1897 (discriminator 4))
[6] RenderingDeviceVulkan::_flush(bool) (/home/UserName/Projects/godot/drivers/vulkan/rendering_device_vulkan.cpp:8967)
[7] RenderingDeviceVulkan::texture_get_data(RID, unsigned int) (/home/UserName/Projects/godot/drivers/vulkan/rendering_device_vulkan.cpp:2792)
[8] RendererRD::TextureStorage::texture_2d_get(RID) const (/home/UserName/Projects/godot/servers/rendering/renderer_rd/storage_rd/texture_storage.cpp:1084)
[9] RenderingServerDefault::texture_2d_get(RID) const (/home/UserName/Projects/godot/servers/rendering/rendering_server_default.h:195 (discriminator 2))
[10] ImageTexture::get_image() const (/home/UserName/Projects/godot/scene/resources/texture.cpp:214)
[11] ./bin/godot.linuxbsd.tools.64() [0x3871d1d] (/home/UserName/Projects/godot/editor/editor_themes.cpp:102)
[12] create_editor_theme(Ref<Theme>) (/home/UserName/Projects/godot/editor/editor_themes.cpp:1510 (discriminator 4))
[13] create_custom_theme(Ref<Theme>) (/home/UserName/Projects/godot/editor/editor_themes.cpp:1790 (discriminator 4))
[14] ProjectManager::ProjectManager() (/home/UserName/Projects/godot/editor/project_manager.cpp:2568 (discriminator 4))
[15] Main::start() (/home/UserName/Projects/godot/main/main.cpp:2689 (discriminator 1))
[16] ./bin/godot.linuxbsd.tools.64(main+0x133) [0x23b3e09] (/home/UserName/Projects/godot/platform/linuxbsd/godot_linuxbsd.cpp:71)
[17] /lib64/libc.so.6(+0x29550) [0x7ff298a9d550] (??:0)
[18] /lib64/libc.so.6(__libc_start_main+0x89) [0x7ff298a9d609] (??:0)
[19] ./bin/godot.linuxbsd.tools.64(_start+0x25) [0x23b3c15] (??:?)
-- END OF BACKTRACE --
================================================================
Aborted (core dumped)
[UserName@fedora godot]$
Could be related to the PR:
ERROR: Can't show a Vulkan window. at: show_window (platform/linuxbsd/display_server_wayland.cpp:1667)
@toger5
Try with line 503 in display_server_wayland.cpp changed this way:
- sd->wl_output = (struct wl_output *)wl_registry_bind(wl_registry, name, &wl_output_interface, 3);
+ sd->wl_output = (struct wl_output *)wl_registry_bind(wl_registry, name, &wl_output_interface, 2);
Out of curiosity, which compositor are you using?
Mhhh, from my side surely there is a protocol version issue like @dos1 noted, the most I've tested are pretty recent sway and weston but I'll see how to handle older compositors and whether we need certain features of newer protocol versions.
From toger's log:
wl_registry@2: error 0: invalid version for global wl_output (4): have 2, wanted 3
I'm not sure though how a wrongly registered output might interfere with vulkan in such a way but we'll see:
ERROR: Condition "format == DATA_FORMAT_MAX" is true. Returning: INVALID_ID
at: screen_get_framebuffer_format (drivers/vulkan/rendering_device_vulkan.cpp:6801)
ERROR: Mismatch fragment shader output mask (1) and framebuffer color output mask (0) when binding both in render pipeline.
at: render_pipeline_create (drivers/vulkan/rendering_device_vulkan.cpp:6265)
@toger5 could you please tell me more about your configuration?
Using Nvidia 970, 415 drivers with Ubuntu 22.04 Gnome GNOME Shell 42.2 I don't have a crash, but exactly same error message at start
Godot Engine v4.0.alpha.custom_build.d7893a031 - https://godotengine.org
wl_registry@2: error 0: invalid version for global wl_output (5): have 2, wanted 3
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 970
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _update_swap_chain (drivers/vulkan/vulkan_context.cpp:1663)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
at: _window_create (drivers/vulkan/vulkan_context.cpp:1386)
ERROR: Can't show a Vulkan window.
at: show_window (platform/linuxbsd/display_server_wayland.cpp:1667)
ERROR: Condition "!windows.has(p_window)" is true. Returning: false
at: window_is_valid_swapchain (drivers/vulkan/vulkan_context.cpp:1421)
ERROR: Condition "!dl" is true.
at: draw_list_bind_render_pipeline (drivers/vulkan/rendering_device_vulkan.cpp:7330)
ERROR: Condition "!dl" is true.
at: draw_list_bind_index_array (drivers/vulkan/rendering_device_vulkan.cpp:7477)
ERROR: Condition "!dl" is true.
at: draw_list_bind_uniform_set (drivers/vulkan/rendering_device_vulkan.cpp:7404)
ERROR: Condition "!dl" is true.
at: draw_list_set_push_constant (drivers/vulkan/rendering_device_vulkan.cpp:7511)
ERROR: Condition "!dl" is true.
at: draw_list_draw (drivers/vulkan/rendering_device_vulkan.cpp:7529)
ERROR: Immediate draw list is already inactive.
at: draw_list_end (drivers/vulkan/rendering_device_vulkan.cpp:7838)
and later error spam of
Wayland protocol error 0 on interface wl_registry@2
using patch from above, doesn't help, I just got a little different error:
wl_registry@2: error 0: invalid version for global wl_seat (18): have 5, wanted 7
and later still error spam about wayland protocol error
@qarmin well it looks like I took for granted way newer protocols than what are actually used in most compositors. That patch made Godot request an older wl_output (which I think would still require some extra steps to work properly) but it looks like that also wl_seats are too old compared to what Godot's expecting.
Could you run Godot with the environment variable WAYLAND_DEBUG=1 and send me the log?
@qarmin thanks, later I'll downgrade the expected version where I can.
I think this shouldn't be that big of a problem since from what I read most version bumps are... Coordinated? That should mean that I can just cap at the latest useful version (which should coincide with yours) with minimal changes.
If you don't require features added in later versions for your code to actually work, you should pass something like MIN(3, version) or MAX(5, MIN(7, version)) to wl_registry_bind, where version is what you get from wl_registry.global handler. This way you always request a correct version as long as there's an overlap between what you expect and what the compositor supports, and you can still implement new features added in later versions.
@dos1 thanks, great tip! I should see how much it's worth though as I can see this getting messy very quickly.
You can simply use any wlroots-based compositor (Sway, phoc, Cage etc.) with X11 backend and this patch applied to wlroots. This will turn mouse events into (single) touch.
@dos1, sorry, I forgot to answer to this post. When I'll work on basic touch support I'll try with this, thanks!
@toger5 and @qarmin could you please try again on mutter to see if the latest patch I pushed is enough?
Still I have this errors
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _update_swap_chain (drivers/vulkan/vulkan_context.cpp:1663)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
at: _window_create (drivers/vulkan/vulkan_context.cpp:1386)
ERROR: Can't show a Vulkan window.
at: show_window (platform/linuxbsd/display_server_wayland.cpp:1667)
ERROR: Condition "!windows.has(p_window)" is true. Returning: false
at: window_is_valid_swapchain (drivers/vulkan/vulkan_context.cpp:1421)
ERROR: Condition "!dl" is true.
at: draw_list_bind_render_pipeline (drivers/vulkan/rendering_device_vulkan.cpp:7330)
ERROR: Condition "!dl" is true.
at: draw_list_bind_index_array (drivers/vulkan/rendering_device_vulkan.cpp:7477)
ERROR: Condition "!dl" is true.
at: draw_list_bind_uniform_set (drivers/vulkan/rendering_device_vulkan.cpp:7404)
ERROR: Condition "!dl" is true.
at: draw_list_set_push_constant (drivers/vulkan/rendering_device_vulkan.cpp:7511)
ERROR: Condition "!dl" is true.
at: draw_list_draw (drivers/vulkan/rendering_device_vulkan.cpp:7529)
ERROR: Immediate draw list is already inactive.
at: draw_list_end (drivers/vulkan/rendering_device_vulkan.cpp:7838)
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _update_swap_chain (drivers/vulkan/vulkan_context.cpp:1663)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
at: _window_create (drivers/vulkan/vulkan_context.cpp:1386)
ERROR: Can't show a Vulkan window.
at: show_window (platform/linuxbsd/display_server_wayland.cpp:1667)
ERROR: Condition "!windows.has(p_window)" is true. Returning: false
at: window_is_valid_swapchain (drivers/vulkan/vulkan_context.cpp:1421)
ERROR: Condition "!windows.has(p_window)" is true. Returning: false
at: window_is_valid_swapchain (drivers/vulkan/vulkan_context.cpp:1421)
--single-window also not helps, window still is invisible Wayland debug log - ABC1.txt
Hi @qarmin, From a very cursory look I can't see anything wrong, could you also add --verbose to the flags and send me the log? (e.g. bin/godot.linuxbsd.tools.64 --verbose)
Thanks for your testing.
@qarmin I'm having trouble finding a problem in this log. Wayland side there are no errors and everything looks... smooth? Obviously Vulkan fails but I have no idea if this is my fault. Could you give me a little bit more info on your OS, specs and whether vkcube runs properly?
Edit: I'm a dumbass and forgot that you already told me your OS.
inxi -GSC -xx
System:
Host: rafal-H87M-D3H Kernel: 5.15.0-41-generic x86_64 bits: 64
compiler: gcc v: 11.2.0 Desktop: GNOME 42.2 tk: GTK 3.24.33 wm: gnome-shell
dm: GDM3 Distro: Ubuntu 22.04 LTS (Jammy Jellyfish)
CPU:
Info: quad core model: Intel Core i7-4770 bits: 64 type: MT MCP
arch: Haswell rev: 3 cache: L1: 256 KiB L2: 1024 KiB L3: 8 MiB
Speed (MHz): avg: 3834 high: 3886 min/max: 800/3900 cores: 1: 3842
2: 3886 3: 3864 4: 3843 5: 3765 6: 3775 7: 3869 8: 3834 bogomips: 54278
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: Gigabyte driver: nvidia
v: 515.48.07 pcie: speed: 2.5 GT/s lanes: 16 ports: active: none
off: DVI-D-1,DVI-I-1 empty: DP-1,HDMI-A-1 bus-ID: 01:00.0
chip-ID: 10de:13c2
Display: wayland server: X.org v: 1.21.1.3 with: Xwayland v: 22.1.1
compositor: gnome-shell driver: X: loaded: nvidia
unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia display-ID: 0
OpenGL: renderer: NVIDIA GeForce GTX 970/PCIe/SSE2
v: 4.6.0 NVIDIA 515.48.07 direct render: Yes
vkcube - works fine
Selected GPU 0: NVIDIA GeForce GTX 970, type: 2
echo $XDG_SESSION_TYPE
wayland
Thanks for giving me that much information! Just out of curiosity, what does happen if you run the editor with --gpu-index 1? It should use software rendering (the CPU). If it runs, please send me a log with --verbose and WAYLAND_DEBUG=1 too, so I avoid wasting your time too much.
Edit: Sorry, it doesn't make much sense to send a working log, could you please send it to me anyway?
Well, now it works - at least project manager ABC3.txt
There is visible also crash at exit(used address sanitizer to find it)
When running editor(both this PR and master) with Lavapipe I have such crash
0x00007fffe9c39496 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
(gdb) backtrace
#0 0x00007fffe9c39496 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#1 0x00007fffe9c3f9c8 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#2 0x00007fffe9c42b57 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#3 0x00007fffe9c25e91 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#4 0x00007fffe9c299cb in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#5 0x00007fffe9c29e08 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#6 0x00007fffe9c31a89 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#7 0x00007fffe9ba8623 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#8 0x00007fffe9baa901 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#9 0x00007fffe9b9bda8 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#10 0x00007fffe9b808f0 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#11 0x00007fffe99d1356 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#12 0x00007fffe99d3303 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#13 0x00007fffe99c3d3c in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#14 0x00007fffe99f24a9 in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#15 0x00007fffe99f201b in ?? () from /usr/lib/x86_64-linux-gnu/libvulkan_lvp.so
#16 0x00007ffff7aa5b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#17 0x00007ffff7b37a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
so I'm not able to test it
@qarmin now that's interesting. Regarding the crash, I "just" hope it's because Lavapipe isn't completely conformant (from the logs: WARNING: lavapipe is not a conformant vulkan implementation, testing use only.).
I wonder if it's somehow connected to that nvidia card of yours (and EGLStream compositor implementation from what I read)
@qarmin I've been thinking about your issue and would it be too messy to try another EGL compositor? (dunno, KDE?)
The issue looks very complicated and I can't think of many ways to debug it, if it's my fault (AFAICT, on AMD/GBM/sway it works fine in single-window mode)
@nathanfranke that's probably due to the absence of client-side decorations. It's on my TODO list but it's one of those more complex things to do along with HiDPI support. Thanks for testing!
Edit: I'm reading that KWin uses server-side decorations so I don't think that's the reason and I might need to implement the XDG decoration protocol. I'll see once I get some stuff done.
Well, preferring Wayland now obviously runs it in the CI, which uncovered stuff which I had no idea was there. I propose to add a step in the sanitized Linux job in order to run both DisplayServers one after the another.
I just tried again. It works but starts through xWayland. Is there any flag i need to set to make it start with wayland?
I just tried again. It works but starts through xWayland. Is there any flag i need to set to make it start with wayland?
If you compiled the latest commit, I think I messed something but I'm not sure where, I got issues setting up sanitizers on my musl machine.
I just tried again an somehow it is working now!!!! Godot on wayland!!! super happy to see it in action :+1: :heart: I am also really looking forward to hiDPI in the seperate pr you mentioned!
Drag and drop may be able to be, or may need to be, implemented using xdg desktop portals, although I'm not sure on that. Using the portals would allow the exported Godot application to function inside of Flatpak and other isolated environments, at least
@orowith2os you're sure? Shouldn't implementing the drag and drop part of the base protocol be enough?
@orowith2os you're sure? Shouldn't implementing the drag and drop part of the base protocol be enough?
Not using xdg portals for drag and drop would require that the app have access to the files in flatpak permissions, to be able to pull them in from outside. Again, I'm not sure, but it can be looked into. An example that may help is Electron, as it's MIT licensed and works as expected inside of Flatpak (aka with limited permissions)
@orowith2os mhhh. I thought that the file was transferred as a datastream, not as a path. What would the MIME type be in this case?
@orowith2os mhhh. I thought that the file was transferred as a datastream, not as a path. What would the MIME type be in this case?
From the Portals documentation, it seems they use application/vnd.portal.filetransfer?
https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.FileTransfer
I'm not sure how GTK implements it thooo..
Oh, and hiii! It seems I'm getting a crash when running the output executable on a Fedora 36 container (Toolbox) ^^
Here's my crash log: https://gist.github.com/lovelyyfiaaa/fcfe5ce327226572f97295990f78b84f
@lovelyyfiaaa hiii! I'm currently working on something else, but I think that this might be somehow related with seat handling and a null pointer somewhere in the process. Would you mind trying to wrap line 779 in an if (ss->wl_pointer) block and see if it works around the problem?
That part of the code looks a bit weird, I'll put a review of that part in my TODO list.
@lovelyyfiaaa hiii! I'm currently working on something else, but I think that this might be somehow related with seat handling and a null pointer somewhere in the process. Would you mind trying to wrap line 779 in an
if (ss->wl_pointer)block and see if it works around the problem?That part of the code looks a bit weird, I'll put a review of that part in my TODO list.
It seems instead of the wl_pointer being null, it's actually the cursor_image instead that's null!
@lovelyyfiaaa oh, right, I didn't check for the image presence, sorry.
What's going on in that photo?!
@lovelyyfiaaa oh, right, I didn't check for the image presence, sorry.
What's going on in that photo?!
Umm. The Projects window and the dialogs weren't displaying well.
They're just glitchy colors and that stuff ^^
@lovelyyfiaaa what's your system? Do you use anything particular other than that toolbox thing you talked about?
Nothing of interest, I think? I have Fedora Sirverblue as the host, and running Godot on the host doesn't fix anything ^^
@lovelyyfiaaa that's weird :/
I'll try replicating it on my side. What's your GPU?
I wanted to throw out there: since the Steam Deck uses a custom Wayland display server, I can't get Godot to compile on SteamOS 3 since X11 isn't available. It would be amazing to get this in for Godot 4.
Let me know if I can do anything to help (with a little spare time here and there); full-time C++ dev, only a little Godot experience.
I wanted to throw out there: since the Steam Deck uses a custom Wayland display server, I can't get Godot to compile on SteamOS 3 since X11 isn't available. It would be amazing to get this in for Godot 4.
Let me know if I can do anything to help (with a little spare time here and there); full-time C++ dev, only a little Godot experience.
You can compile Godot on SteamOS 3 without problem, you just need to install the X11 development libraries (you'd need to install the Wayland development libraries to compile this PR too).
To do so you have to disable the read-only mode on the filesystem to be able to use pacman to install packages: https://www.reddit.com/r/SteamDeck/comments/t8al0i/install_arch_packages_on_your_steam_deck/
A better alternative (which is the one I used last I tried on my Steam Deck) is to use the Linux SDK we provide for Linux (not well documented yet but it works, some instructions in https://github.com/godotengine/buildroot/#using-the-sdks). That's what we use for official builds.
@leetNightshade yeah, akien's approach is better. Thanks for the offer for help! Don't worry, for now I'm fine! Just going slower because lately I've been allowing myself some more relax for the summer. You can try to break the hell out of this PR though, that'd be very appreciated!
Hey, I was testing this in the editor and it seems to crash when moving the mouse on and off menus too quickly. To reproduce:
- Open godot --editor and select a project
- Select the menu at the top, e.g. Scene
- Drag the mouse quickly on and off different menus
It seems to crash specifically on menus that have multiple levels like recent files having a second level. Reproduced on swaywm. I built 2592247dad4b443aee269fe2da6c62b3977f430e.
(Please note that my build flags were a little weird because I did not like the slow build times: builtin_embree=no builtin_freetype=no builtin_libogg=no builtin_libpng=no builtin_libtheora=no builtin_libvorbis=no builtin_libvpx=no builtin_libwebp=no builtin_mbedtls=no builtin_miniupnpc=no builtin_opus=no builtin_pcre2=no builtin_wslay=no builtin_zlib=no linker=mold)
Coredump: https://m1.afileditch.ch/IlbWsReAVcPgAPFroDD.zst (warning: half a gigabyte uncompressed)
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Vulkan API 1.2.0 - Using Vulkan Device #0: Intel - Intel(R) HD Graphics 4400 (HSW GT2)
Editing project: $HOME/godot/fun
Godot Engine v4.0.alpha.custom_build.2592247da - https://godotengine.org
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Vulkan API 1.2.0 - Using Vulkan Device #0: Intel - Intel(R) HD Graphics 4400 (HSW GT2)
WARNING: FBX file import is enabled, but no FBX2glTF path is configured. FBX files will not be imported.
at: _editor_init (modules/gltf/register_types.cpp:92)
Destroying popup menu 69 which is not the topmost in the stack.
Destroying popup menu 68 which is not the topmost in the stack.
xdg_wm_base@6: error 2: xdg_popup was destroyed while it was not the topmost popup
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _update_swap_chain (drivers/vulkan/vulkan_context.cpp:1753)
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
at: _window_create (drivers/vulkan/vulkan_context.cpp:1461)
ERROR: Can't show a Vulkan window.
at: show_window (platform/linuxbsd/wayland/display_server_wayland.cpp:1704)
Error 71 while flushing the Wayland display.
ERROR: Condition "err" is true. Returning: ERR_CANT_CREATE
at: _update_swap_chain (drivers/vulkan/vulkan_context.cpp:1753)
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.alpha.custom_build (2592247dad4b443aee269fe2da6c62b3977f430e)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /usr/lib/libc.so.6(+0x38a40) [0x7f4cc02a0a40] (??:0)
[2] /usr/lib/libvulkan_intel.so(+0x1a60db) [0x7f4cba31b0db] (??:0)
[3] /usr/lib/libvulkan_intel.so(+0x9f309) [0x7f4cba214309] (??:0)
[4] /usr/lib/libvulkan_intel.so(+0x19c0c9) [0x7f4cba3110c9] (??:0)
[5] VulkanContext::prepare_buffers() (??:0)
[6] RenderingDeviceVulkan::prepare_screen_for_drawing() (??:0)
[7] RendererCompositorRD::prepare_for_blitting_render_targets() (??:0)
[8] RendererViewport::draw_viewports() (??:0)
[9] RenderingServerDefault::_draw(bool, double) (??:0)
[10] RenderingServerDefault::draw(bool, double) (??:0)
[11] Main::iteration() (??:0)
[12] OS_LinuxBSD::run() (??:0)
[13] $HOME/godot/bin/godot.linuxbsd.tools.64(main+0x187) [0x55e0d19c5900] (??:0)
[14] /usr/lib/libc.so.6(+0x232d0) [0x7f4cc028b2d0] (??:0)
================================================================25) [0x55e0d19c56a5] (??:0)
I hope this is not caused by Haswell Vulkan support is incomplete!
Hi @ndren, this is a known issue on which I researched an awful lot and which didn't happen at all on Weston, so I assume that it's a sway bug that I'll have to report properly some day to upstream. I also talked about this issue with other contributors and they said that it's fine for now if it works properly only in single window mode.
Still, thanks for testing and for your detailed bug report!