[XWAYLAND] Cannot drag anything in Unreal Engine

[TheSunCat]

NOTE: Krita is fixed now, thanks! This still applies for Unreal Engine, so I am keeping the issue open. Expand to view the original issue including Krita

Krita does not support Wayland, and Unreal Engine does not respond to mouse input on Wayland, so I unfortunately have to run both under Xwayland. Both apps seem to exhibit the same bug, which is why I am grouping them in this issue. In Krita, the primary way to manage layers is by dragging one up/down. When I do this in Hyprland, Krita appears to be unfocused for one frame, then focus is brought back to Krita and the drag-and-drop is instantly "dropped". If, within that frame, I was able to move my mouse to the desired destination, the layer does move, indicating that a drag and drop did indeed happen, but was ended nearly instantly.

Logs for doing this in Krita

``` [LOG] Set keyboard focus to surface 564cb5d59320, with window name: [Not Saved] (16.0 MiB) * — Krita [LOG] New XWayland Surface created (class krita). [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bee8 -> 564cb6246e68 (owner: XWayland Window) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6be68 -> 564cb6246f38 (owner: XWayland Window) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bfa8 -> 564cb62474e8 (owner: XWayland Window) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6be78 -> 564cb6247348 (owner: XWayland Window) [LOG] Registered signal for owner 564cb6247550: 564cb6252468 -> 564cb6247558 (owner: CWLSurface) [LOG] CWLSurface 564cb6247550 called init() [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bef8 -> 564cb6246ed0 (owner: CWindow) [LOG] Searching for matching rules for krita (title: Krita) [LOG] Window rule rounding 0 -> title:^(Krita)$ matched 564cb6246e00 [Krita] [LOG] Window rule noblur -> title:^(Krita)$ matched 564cb6246e00 [Krita] [LOG] Window rule opaque -> title:^(Krita)$ matched 564cb6246e00 [Krita] [LOG] Set keyboard focus to surface 564cb6252180, with window name: Krita [LOG] Window got assigned a surfaceTreeNode 0 [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bec8 -> 564cb6247070 (owner: XWayland Window Late) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bed8 -> 564cb62472e0 (owner: XWayland Window Late) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bf08 -> 564cb6246fa0 (owner: XWayland Window Late) [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bea8 -> 564cb62471a8 (owner: Xwayland Window Late) [ERR] Tried to connect a listener twice?! [LOG] Registered signal for owner 564cb6246e00: 564cb5d6bfb8 -> 564cb6247008 (owner: XWayland Window Late) [LOG] Registered signal for owner 564cb6243150: 564cb6252458 -> 564cb62431c8 (owner: SurfaceTreeNode) [LOG] Registered signal for owner 564cb6243150: 564cb6252448 -> 564cb6243230 (owner: SurfaceTreeNode) [LOG] Registered signal for owner 564cb6243150: 564cb6252468 -> 564cb6243298 (owner: SurfaceTreeNode) [LOG] Creating a surfaceTree Root! (pWindow: 564cb6246e00) [LOG] Map request dispatched, monitor eDP-2, xywh: 1579.000000 254.000000 232.000000 27.000000 [LOG] Unmanaged window 564cb6246e00 requests geometry update to 1579 250 232 27 [LOG] Unmanaged window 564cb6246e00 requests geometry update to 1580 246 232 27 [LOG] Window 564cb6246e00 unmapped (class krita) [LOG] Unregistered late callbacks XWL [LOG] Callback 564cb6247098 -> 564cb6247090, XWayland Window Late removed. [LOG] Callback 564cb6247308 -> 564cb6247300, XWayland Window Late removed. [LOG] Callback 564cb6246fc8 -> 564cb6246fc0, XWayland Window Late removed. [LOG] Callback 564cb6247030 -> 564cb6247028, XWayland Window Late removed. [LOG] Callback 564cb62471d0 -> 564cb62471c8, Xwayland Window Late removed. [LOG] Framebuffer created, status 36053 [LOG] On closed window, new focused candidate is 564cb6259820 [LOG] Set keyboard focus to surface 564cb5d59320, with window name: [Not Saved] (16.0 MiB) * — Krita [LOG] Destroying the SubSurface tree of unmapped window 564cb6246e00 [LOG] Callback 564cb6243258 -> 564cb6243250, SurfaceTreeNode removed. [LOG] Callback 564cb62432c0 -> 564cb62432b8, SurfaceTreeNode removed. [LOG] Callback 564cb62431f0 -> 564cb62431e8, SurfaceTreeNode removed. [LOG] SurfaceTree Node removed [LOG] Callback 564cb6247580 -> 564cb6247578, CWLSurface removed. [LOG] CWLSurface 564cb6247550 called destroy() [LOG] Callback 564cb6246ef8 -> 564cb6246ef0, CWindow removed. [LOG] Window 564cb6246e00 destroyed, queueing. (class ) [LOG] XWayland class raw: krita [LOG] Callback 564cb6246e90 -> 564cb6246e88, XWayland Window removed. [LOG] Callback 564cb6246f60 -> 564cb6246f58, XWayland Window removed. [LOG] Callback 564cb6247370 -> 564cb6247368, XWayland Window removed. [LOG] Callback 564cb6247510 -> 564cb6247508, XWayland Window removed. [LOG] Cleanup: destroyed a window ```

In Unreal Engine, to interact with the "Blueprints" language, you drag links off of nodes (similar to Blender's shader editor).

Here is a video of the issue in Unreal Engine: https://user-images.githubusercontent.com/44881120/233791623-f872688b-a7ac-4b35-b618-a0bc364a3280.mp4

Logs from the video.

Additionally, focus as a whole is majorly broken on UE. If you open a right click menu and move your mouse over the options (especially to a sub-menu), the menu will close and put UE in a strange "unfocused" state, where the framerate is limited to 1fps and all menus instantly close when they are opened. Refocusing UE usually fixes this.

These two issues together make UE nearly impossible to use on Hyprland.

Hyprland version: 254c680bda9365b74472f066c1e6ee994a0d0a67dirty Let me know if I can provide anything else!

[vaxerski]

catch the class of the window that opens and add a nofocus rule to it

[TheSunCat]

Is there an easy way to do this, especially for the Unreal Engine issue? Ideally just printing every new window that is opened, for example.

[vaxerski]

watch -n 0.1 "cat /tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/hyprland.log | grep "rules" | tail -n 40"

[TheSunCat]

Thanks... it's the same properties as Krita's dialog boxes, so I don't think it can be singled out. Why could this be working in Sway and not Hyprland, without specific window rules? The same issue applies to Unreal Engine: windows that need to have focus also share class & title with these problematic ones.

[vaxerski]

it's because there is a bug somewhere in hyprland but I am not installing a 10GB pack to test

[TheSunCat]

It's reproducible with Krita, which is 160MiB according to pacman -Qi. I'm also happy to help with any testing required for Unreal Engine.

[vaxerski]

krita should be working with the retarded fix 97b03687657ba141f11128d25aa345d92892bd2d

Why could this be working in Sway and not Hyprland, without specific window rules?

Because X11 is such a fucking horrible protocol it's genuinely fucking baffling people still consider it "the standard"

[vaxerski]

I also like the fact how y'all shit on xwayland handling in hyprland meanwhile the "create new" window's size on sway is completely fucking wrong but on hl it's alright

[TheSunCat]

Thanks for the Krita fix! I see it was another one of those X11 window "properties". I don't think Hyprland's Xwayland implementation is bad (most of the issues I have complained about in the past were the hidpi patch's fault, which does indeed work better on Sway, but is too buggy to use in general). Besides that, Hyprland's implementation works well for the most part, and the fact these issues are getting fixed makes it even better.

As for Unreal: is there a way to print X11 window properties for new surfaces being created? I could then provide a log of this and maybe it can help find how Unreal is expecting Hyprland & Xwayland to filter its drag-and-drop objects. Unfortunately I have a class which forces usage of Unreal Engine, and I am not aware of a way to run it natively in Wayland to avoid these issues (it runs with SDL_VIDEODRIVER=wayland, keyboard works, but there is no mouse input, making it sadly useless). This is also the case on Sway, but there are posts of people having it working, so I wonder whether this is a recent regression on Unreal's part. I guess for now it's stuck on Xwayland.

[vaxerski]

As for Unreal: is there a way to print X11 window properties for new surfaces being created?

ye

patch.txt

Will print all atoms in the beginning and then window's atoms on window open

[TheSunCat]

With this patch, trying to drag a node in Unreal prints Window [some number] has atom 282, which is different from hover menus which have atom 284. Dragging an asset into the viewport (which is also broken) opens both a 282 and a 287 window. I guess 282 and 287 should also not have initial focus? I'm not sure how these numbers relate to the strings.

[vaxerski]

you get all the strings printed at the beginning

Search for Atom

One window can have multiple atoms.

opens both a 282 and a 287

u sure its not one window with both?

[TheSunCat]

The 287 happens when it registers the drag-and-drop ended on the same panel, as that causes a popup menu to open there (Atom 287 is _NET_WM_WINDOW_TYPE_POPUP_MENU). Here for example I try to drag the ceiling light blueprint into the scene, but it instantly ends the dnd and shows this popup instead: The logs show a 282 (_NET_WM_WINDOW_TYPE_NORMAL) being created, then a 287 shortly after.

As for dragging nodes, it seems again a 282 is created, then instantly closed and the tooltip 284 (_NET_WM_WINDOW_TYPE_TOOLTIP) comes back:

$ tail -f /tmp/hypr/$HYPRLAND_INSTANCE_SIGNATURE/hyprland.log | grep -i -A3 -B3 Atom
[LOG] Registered signal for owner 55d383fa9110: 55d3843e5898 -> 55d383fa9118 (owner: CWLSurface)
[LOG] CWLSurface 55d383fa9110 called init()
[LOG] Registered signal for owner 55d383fa89c0: 55d384401288 -> 55d383fa8a90 (owner: CWindow)
[LOG] Window 55d383fa89c0 has atom 284
[LOG] Searching for matching rules for UnrealEditor (title: )
[LOG] Window got assigned a surfaceTreeNode 0
[LOG] Registered signal for owner 55d383fa89c0: 55d384401258 -> 55d383fa8c30 (owner: XWayland Window Late)
--
[LOG] Registered signal for owner 55d383fb63f0: 55d383faf2d8 -> 55d383fb63f8 (owner: CWLSurface)
[LOG] CWLSurface 55d383fb63f0 called init()
[LOG] Registered signal for owner 55d383fb5ca0: 55d383fa9e38 -> 55d383fb5d70 (owner: CWindow)
[LOG] Window 55d383fb5ca0 has atom 282
[LOG] Searching for matching rules for UnrealEditor (title: )
[LOG] Set keyboard focus to surface 55d383faeff0, with window name: 
[LOG] Window got assigned a surfaceTreeNode 0
--
[LOG] Registered signal for owner 55d383fb9140: 55d384408128 -> 55d383fb9148 (owner: CWLSurface)
[LOG] CWLSurface 55d383fb9140 called init()
[LOG] Registered signal for owner 55d383fb89f0: 55d384401288 -> 55d383fb8ac0 (owner: CWindow)
[LOG] Window 55d383fb89f0 has atom 284
[LOG] Searching for matching rules for UnrealEditor (title: )
[LOG] Window got assigned a surfaceTreeNode 0
[LOG] Registered signal for owner 55d383fb89f0: 55d384401258 -> 55d383fb8c60 (owner: XWayland Window Late)

I think Unreal is signalling that it's a drag and drop menu in an unusual way, as it never uses atom 285 (_NET_WM_WINDOW_TYPE_DND). Note that all the 284s it creates seem to be the tooltips that appear on hover of any element.

[BackupPlease]

Having this issue as well Unreal Engine is not usable on Hyprland at all 😢 i have to jump from hyprland to i3 when i want to work on my project, not only that when for example i open the project settings window and close it and come back to the unreal engine viewport the engine lags and stutters with the fps acting like crazy until i open a terminal or a anything else and focus on that and when i refocus the engine again it work until i start doing something t

right click menu makes the engine have a fps seizure rendering it unusable until i focus another windows that is not unreal engine related and refocus the engine again it works great until i start using it

[TheSunCat]

So far I am using Unreal Engine in rootful XWayland (running i3 within it), but it is far from ideal. I also get the huge lag spike that you get, pretty often when trying to use Unreal Engine on Hyprland. It indeed goes away after refocusing. There is also an issue with right click menus disappearing instantly, which is sometimes fixed by refocusing, but usually ends up requiring a restart. I am hoping that fixing the drag-and-drop behavior might help fix some of the other focus-related issues in Unreal Engine.

@vaxerski, is there anything we can do to help? I understand it is not possible for you to test with this program, but I am unsure what other information I can provide. The program works fine in Sway and i3, but Hyprland does not like it.

[vaxerski]

not really, it's just some quirks in hyprland's xwayland focus impl that I really can't be arsed to fix. X11 is such a terrible protocol that I don't fully even understand what the impl is meant to be like. There are 0 docs, the only reference is basically "how xorg does it" and I will not read Xorg's source and spend a full week just for this.

Feel free to monitor the behavior every month or so, maybe it improves one day. Or pester ue devs to release a working wayland version.

You can also try running ue4 in Xephyr instead of XWayland rootful, maybe that will help.

Xephyr -br -ac -noreset -screen 1920x1080 :12 &

[BackupPlease]

I talked to one of the developers in Discord, and he said that the issue here is not Unreal, as it's working like it should in Sway i3 and KDE/gnome Wayland, but something in Hyprland Causes this strange behaviors mentioned above

I am not using XWayland.

[TheSunCat]

Unreal Engine does not work natively on Wayland for me, on any compositor. There is no mouse input. This is the reason I have to run it in XWayland, which leads to the issues on Hyprland. Does mouse input work for you with SDL_VIDEODRIVER=wayland?

[BackupPlease]

Unreal Engine does not work natively on Wayland for me, on any compositor. There is no mouse input. This is the reason I have to run it in XWayland, which leads to the issues on Hyprland. Does mouse input work for you with SDL_VIDEODRIVER=wayland?

I didn't use that but i do have the mouse working like it should

[TheSunCat]

So it is running in XWayland? Without that variable, Unreal Engine runs in XWayland.

[BackupPlease]

Unreal Engine does not work natively on Wayland for me, on any compositor. There is no mouse input. This is the reason I have to run it in XWayland, which leads to the issues on Hyprland. Does mouse input work for you with SDL_VIDEODRIVER=wayland?

I didn't use that but i do have the mouse working like it should

Again I don't use Xwayland I use Wayland...

[TheSunCat]

How are you launching Unreal Engine as a native Wayland app, without that env var? Are you sure it's not running in the embedded X11 server XWayland? You can check with xeyes, if the eyes follow the mouse while hovering over Unreal Engine.

[vaxerski]

or just hyprctl clients and checking the xwayland flag

[vaxerski]

check w/ 4ad03af544ba56399918642b609ed538764d1c0f

[TheSunCat]

Thanks for looking into this! Sadly it is still happening. When I start dragging, Unreal Engine gets unfocused for a very short moment, then refocused, and the drag gets instantly cancelled (as seen in my first post).

[deathbymanatee]

have you tried running UE5 using lutris? i am having the same issues you've described and i'm thinking about just running it through lutris instead of using the native port, but i would like to know if you have any experience doing that and if it's even worth the time

[TheSunCat]

I would not expect a better experience as WINE apps have lots of issues on Hyprland (e.g Photoshop and various installers get a separate black window over them that I have to move out of the way to be able to see and interact with the app, but snaps back to it after some time/moving the window). I think the solution has to be either running Unreal as native Wayland, or fixing the Xwayland issue that causes this behavior in Hyprland. As Unreal does not seem to work on Wayland (no mouse input), fixing Xwayland on the Hyprland side seems to be the only option.

[deathbymanatee]

went ahead and tried it, it's a lot worse than running it in hyprland (as you predicted). it has its own set of issues that make it pretty much unusable

[TheSunCat]

I figured out the drag and drop! It works consistently with these windowrules:

# Don't focus Unreal Engine's untitled popups
windowrulev2=unset,class:^(UnrealEditor)$,title:^\w*$
windowrulev2=noinitialfocus,class:^(UnrealEditor)$,title:^\w*$
windowrulev2=noanim,class:^(UnrealEditor)$,title:^\w*$

However, the menus disappearing issue still occurs. This is reproducible with the top menubar (File/Edit/Asset/etc), if you open a menu, then move the mouse to another menu, it will appear for a fraction of a second then close. Now Unreal Engine has entered a state where it will happen for every menu. You can temporarily bypass the bug by click-and-holding on a menu button for ~1s, and then that menu won't close instantly. You can also reset Unreal to the non-glitched state by resizing it (I just use Super+LMB on the tiled window, which has the same effect). If this last bug can be fixed, Unreal Engine will be fully usable on Hyprland!

Video of the menu issue:

https://github.com/hyprwm/Hyprland/assets/44881120/cd671af2-c699-44aa-a416-cd992e6ab514

[TheSunCat]

I think this is related to focus again, as when this glitched state is entered, the viewport framerate is reduced to 1fps (which is intended to happen when Unreal is unfocused, I believe). Unfortunately some menus are inaccessible with the workaround I wrote about earlier, such as right clicking objects, because right-click-hold does not open the popup like left-click-hold does for the top menu.

[BackupPlease]

I think this is related to focus again, as when this glitched state is entered, the viewport framerate is reduced to 1fps (which is intended to happen when Unreal is unfocused, I believe). Unfortunately some menus are inaccessible with the workaround I wrote about earlier, such as right clicking objects, because right-click-hold does not open the popup like left-click-hold does for the top menu.

About the rules you found Do they fix the FPS issues ?

[TheSunCat]

Nope, the issue where Unreal thinks it's unfocused (and thus reduces the framerate and breaks menus) is not fixed by these windowrules.

[theoparis]

I have managed to get the same issue, with prebuilt unreal engine 5.2 and Gentoo.

I tried running it by using LD_PRELOAD=/usr/lib64/libSDL2.so SDL_VIDEODRIVER=wayland ./Engine/Binaries/Linux/UnrealEditor - but as mentioned earlier in this thread mouse input does not work and therefore I cannot create a project.

When I use tab and tab over to a dropdown and hit enter the window closes with the following in the logs:

xdg_wm_base@9: error 5: positioner object is not complete

Edit: If I use XWayland with SDL_VIDEODRIVER=x11 it crashes saying it can't create a vulkan window. However both vulkaninfo and vkcube work fine on my system.

Assertion failed: false [File:./Runtime/ApplicationCore/Private/Linux/LinuxWindow.cpp] [Line: 263] 
Unable to create a Vulkan window - make sure an up-to-date libvulkan.so.1 is installed.

[BackupPlease]

Yeah this issue will never be fixed 450 opened cases what a buggy mess

[vaxerski]

sway has twice as many, gtk 4x as many.

Besides, your comment is just bitching and adds nothing.

[TheSunCat]

Hyprland has 1,701 closed issues and the fastest developer response and fixes I've ever seen. This issue sucks because X11 and it affects a 50GiB program that supposedly shouldn't even require X11 (it works on Wayland according to Google, but not on my machine). I don't think that makes Hyprland a buggy mess.

I do think the solution to this should be getting UE to run natively on Wayland as it claims to do, rather than fixing the legacy X11 version. I'll give it another shot later.

[BackupPlease]

sway has twice as many, gtk 4x as many.

Besides, your comment is just bitching and adds nothing.

That's not how programming works. If a program has issues, you should learn from them and make a better product. Comparing the number of issues is pathetic and lame. And for the dude above me, the issue is with Hyprland and not with Unreal or Wayland. I tried five other managers, and none of them had this issue.

PS: Saying that a repo is a buggy mess is not bitching; it's just stating facts. This is what's wrong with programmers in this day and age: they think they can release a shit product and want people to thank them for it and be grateful.

[JustSimplyKyle]

Don't want to clutter this issue but you do realize that he's doing this all for free? You probably should be grateful for that. If he charges money then you might be able to complain stuff like this. Even if it IS a buggy mess, it's your own decision to use this compositor. I personally this blog post by the developer himself really well describes how is it like to maintain a popular FOSS project https://blog.vaxry.net/articles/2023-maintainingFoss. And if you can provide a simple way to reproduce, vaxry would probably fix it in a matter of minutes.(which is really nice imo)

Comparing the number of issues is pathetic and lame.

Yes so the saying "Yeah this issue will never be fixed 450 opened cases what a buggy mess" is also pointless, just saying the number of issues isn't helping nor does it express any meaning.

[BackupPlease]

Don't want to clutter this issue but you do realize that he's doing this all for free? You probably should be grateful for that. If he charges money then you might be able to complain stuff like this. Even if it IS a buggy mess, it's your own decision to use this compositor. I personally this blog post by the developer himself really well describes how is it like to maintain a popular FOSS project https://blog.vaxry.net/articles/2023-maintainingFoss. And if you can provide a simple way to reproduce, vaxry would probably fix it in a matter of minutes.(which is really nice imo)

Comparing the number of issues is pathetic and lame.

Yes so the saying "Yeah this issue will never be fixed 450 opened cases what a buggy mess" is also pointless, just saying the number of issues isn't helping nor does it express any meaning.

Steps to reproduce the issue Did you even read what the issue is? All he has to do is literally download UE5 or UE4, and he will get this issue. It's a Hyprland issue, and whether it's  AMD or Nvidia hardware does not matter; it happens.

[JustSimplyKyle]

I wouldn't say downloading 50Gib program is a "simple" one. I'm not saying this isn't Hyprland issue. It mos likely is

[SchnozzleCat]

Hyprland has 1,701 closed issues and the fastest developer response and fixes I've ever seen. This issue sucks because X11 and it affects a 50GiB program that supposedly shouldn't even require X11 (it works on Wayland according to Google, but not on my machine). I don't think that makes Hyprland a buggy mess.

I do think the solution to this should be getting UE to run natively on Wayland as it claims to do, rather than fixing the legacy X11 version. I'll give it another shot later.

I just built 5.3.1 from source with a manually compiled SDL2 that supports wayland, it still doesn't recognize mouse input. So unless someone over at Epic fixes this I don't think it is usable under wayland.

I also tested using sway and gnome-shell running under wayland, both of them have the same issue. Ideally they fix this so hyprland doesn't need to bother with a fix to how xwayland handles it.

Edit: It seems the issue was somewhat fixed in 5.2.0+, but Unreal Engine is still confused if the starting coordinates of your monitor do not start at 0x0 (mine was at 0x1080), the clicks were being forwarded to the wrong location.

However, if I try to launch the editor, it will crash if I move the mouse over something that needs to display a tooltip, with the following logs:

xdg_wm_base@8: error 5: positioner object is not complete
[2023.09.21-22.35.51:060][ 38]LogVulkanRHI: AcquireNextImage() failed due to the outdated swapchain, not even attempting to present.
[2023.09.21-22.35.51:060][ 38]LogVulkanRHI: AcquireNextImage() failed due to the outdated swapchain, not even attempting to present.
[2023.09.21-22.35.51:068][ 38]LogVulkanRHI: Error: VulkanRHI::vkGetPhysicalDeviceSurfaceFormatsKHR(Device.GetPhysicalHandle(), Surface, &NumFormats, nullptr) failed, VkResult=-1000000000
 at ./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:160 
 with error VK_ERROR_SURFACE_LOST_KHR
[2023.09.21-22.35.51:068][ 38]LogVulkanRHI: Error: VulkanRHI::vkGetPhysicalDeviceSurfaceFormatsKHR(Device.GetPhysicalHandle(), Surface, &NumFormats, nullptr) failed, VkResult=-1000000000
 at ./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:160 
 with error VK_ERROR_SURFACE_LOST_KHR
Fatal error: [File:./Runtime/VulkanRHI/Private/VulkanUtil.cpp] [Line: 1131] 
VulkanRHI::vkGetPhysicalDeviceSurfaceFormatsKHR(Device.GetPhysicalHandle(), Surface, &NumFormats, nullptr) failed, VkResult=-1000000000
 at ./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:160 
 with error VK_ERROR_SURFACE_LOST_KHR
Signal 11 caught.
[2023.09.21-22.35.51:069][ 38]LogCore: Error: appError called: Fatal error: [File:./Runtime/VulkanRHI/Private/VulkanUtil.cpp] [Line: 1131] 
VulkanRHI::vkGetPhysicalDeviceSurfaceFormatsKHR(Device.GetPhysicalHandle(), Surface, &NumFormats, nullptr) failed, VkResult=-1000000000
 at ./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:160 
 with error VK_ERROR_SURFACE_LOST_KHR
0x00007ff3c6861157 libUnrealEditor-VulkanRHI.so!VulkanRHI::VerifyVulkanResult(VkResult, char const*, char const*, unsigned int) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanUtil.cpp:1130]
Malloc Size=262146 LargeMemoryPoolOffset=262162 
0x00007ff3c6820606 libUnrealEditor-VulkanRHI.so!FVulkanSwapChain::FVulkanSwapChain(VkInstance_T*, FVulkanDevice&, void*, EPixelFormat&, unsigned int, unsigned int, bool, unsigned int*, TArray<VkImage_T*, TSizedDefaultAllocator<32> >&, signed char, FVulkanSwapChainRecreateInfo*) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:160]
0x00007ff3c686ce83 libUnrealEditor-VulkanRHI.so!FVulkanViewport::CreateSwapchain(FVulkanSwapChainRecreateInfo*) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:703]
0x00007ff3c686e012 libUnrealEditor-VulkanRHI.so!FVulkanViewport::RecreateSwapchain(void*) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:648]
0x00007ff3c6873203 libUnrealEditor-VulkanRHI.so!FVulkanViewport::Present(FVulkanCommandListContext*, FVulkanCmdBuffer*, FVulkanQueue*, FVulkanQueue*, bool) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:983]
0x00007ff3c6814700 libUnrealEditor-VulkanRHI.so!FVulkanCommandListContext::RHIEndDrawingViewport(FRHIViewport*, bool, bool) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/VulkanRHI/Private/VulkanRHI.cpp:1134]
0x00007ff4e7fb9aec libUnrealEditor-RHI.so!FRHICommand<FRHICommandEndDrawingViewport, FRHICommandEndDrawingViewportString2069>::ExecuteAndDestruct(FRHICommandListBase&, FRHICommandListDebugContext&) [/home/linus/Repositories/UnrealEngine/Engine/Source/Runtime/RHI/Public/RHICommandList.h:1245]
0x00007ff4e7f2596d libUnrealEditor-RHI.so!FRHICommandListBase::Execute(TRHIPipelineArray<IRHIComputeContext*>&, FRHICommandListBase::FPersistentState::FGPUStats*) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/RHI/Private/RHICommandList.cpp:461]
0x00007ff4e7f5ecc4 libUnrealEditor-RHI.so!UE::Core::Private::Function::TFunctionRefCaller<FRHICommandListImmediate::ExecuteAndReset(bool)::$_0, void ()>::Call(void*) [/home/linus/Repositories/UnrealEngine/Engine/Source/Runtime/Core/Public/Templates/Function.h:479]
0x00007ff4ef21a72c libUnrealEditor-Core.so!TGraphTask<TFunctionGraphTaskImpl<void (), (ESubsequentsMode::Type)0> >::ExecuteTask(TArray<FBaseGraphTask*, TSizedDefaultAllocator<32> >&, ENamedThreads::Type, bool) [/home/linus/Repositories/UnrealEngine/Engine/Source/Runtime/Core/Public/Async/TaskGraphInterfaces.h:1265]
0x00007ff4ef168b03 libUnrealEditor-Core.so!FNamedTaskThread::ProcessTasksNamedThread(int, bool) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/Core/Private/Async/TaskGraph.cpp:758]
0x00007ff4ef166baf libUnrealEditor-Core.so!FNamedTaskThread::ProcessTasksUntilQuit(int) [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/Core/Private/Async/TaskGraph.cpp:648]
0x00007ff4e82eb3f8 libUnrealEditor-RenderCore.so!FRHIThread::Run() [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/RenderCore/Private/RenderingThread.cpp:328]
0x00007ff4ef322e17 libUnrealEditor-Core.so!FRunnableThreadPThread::Run() [/home/linus/Repositories/UnrealEngine/Engine/Source/./Runtime/Core/Private/HAL/PThreadRunnableThread.cpp:25]
0x00007ff4ef2752ef libUnrealEditor-Core.so!FRunnableThreadPThread::_ThreadProc(void*) [/home/linus/Repositories/UnrealEngine/Engine/Source/Runtime/Core/Private/HAL/PThreadRunnableThread.h:187]
0x00007ff4e34ae907 libc.so.6!UnknownFunction(0x8c906)
0x00007ff4e3534870 libc.so.6!UnknownFunction(0x11286f)
CommonUnixCrashHandler: Signal=11

This also happens under sway, but not gnome-shell running in wayland. I assume it has something to do with the dropdowns, but I don't know enough about how any of this works.

In gnome-shell the XWayland issues in Unreal (like disappearing context menus) also seem to be gone, but I did not have time to test the other stuff like blueprints and drag-and-drop extensively.

I'm not sure if this issue should be closed and a new one should be opened, since this doesn't have anything to do with XWayland anymore, and I assume running it under native wayland would be the preferred method anyways.

I have no idea if the crash above is something Hyprland can reasonably fix if it also happens under sway as well though.

[TheSunCat]

I can indeed reproduce the crash by forcing it to use my Wayland-enabled SDL2 system library. I think this issue is still very much relevant because at the moment it is impossible to use UE on Hyprland, while it does work on GNOME.

The issue with focus is the worst, where when opening a context menu and hovering over the options, the menu will suddenly disappear and UE will enter an "unfocused" state. The framerate then becomes ~1fps and keyboard input does not work until you manually refocus or resize it. I have to use the program every day for class and am affected by this.

[SchnozzleCat]

I can indeed reproduce the crash by forcing it to use my Wayland-enabled SDL2 system library. I think this issue is still very much relevant because at the moment it is impossible to use UE on Hyprland, while it does work on GNOME.

The issue with focus is the worst, where when opening a context menu and hovering over the options, the menu will suddenly disappear and UE will enter an "unfocused" state. The framerate then becomes ~1fps and keyboard input does not work until you manually refocus or resize it. I have to use the program every day for class and am affected by this.

I've sent separate bug reports for both the missing Wayland support for SDL in pre-built 5.2 / 5.3 binaries and for the dropdown crash bug under sway / hyprland. I guess it's up to them to fix it now.

[blurskye]

damn, still not fixed, no workarounds or anything, xephyr doenst have gpu acceleration, so pointless, and making new window rules for unreal barely does anything

[TheSunCat]

FWIW it works perfectly on GNOME, so I will be using that. I have to work in Unreal Engine for the next year so will likely have to move off Hyprland because of this, but I'll keep checking back in case it does get fixed. The issue is simply that UE thinks it's unfocused and thus enables some power-saving low FPS mode that also breaks context menus, dragging, and such.

Another solution would be running UE on Wayland, but this crashes instantly when you compile it with SDL's wayland backend enabled.

[ThatOneCalculator]

Out of sheer curiosity, have you tried Epic Asset Manager? I doubt it would do much, but maybe it launches Unreal in a way that could help this.

[TheSunCat]

Yep I have, sadly no luck with it. Same issues as before, and works perfectly on GNOME like w/o EAM.

[blurskye]

well i suppose this never getting fixed like this, why doesnt no focus rule do anything, why does hyprland focus on the sub window anyways?

[TheSunCat]

This issue appears much improved as of recently. I can drag and place nodes consistently, however it still very much and often enters the glitched state where:

• all submenus close almost instantly (node selector, right click, etc)
• no keyboard input works
• tooltips seem to lag at ~1fps
• clicking on the tiled window to move it and letting go fixes the glitched state until next time it happens

[TheSunCat]

After toying with it a lot, I seem to have a functional setup!!

Window rules:

windowrulev2=unset,class:^(UnrealEditor)$,title:^\w*$
windowrulev2=noinitialfocus,class:^(UnrealEditor)$,title:^\w*$
windowrulev2=suppressevent activate,class:^(UnrealEditor)$,title:^\w*$

In my short testing, I was able to drag nodes, open menus (WITHOUT going into the glitched focus mode), and drag and drop objects onto the scene. Could someone else please confirm this works?