Linux : button on UnrealEditor can't be clicked

Development Pipeline & Plugins
, ,
1

Commit of 5.7 branch

Problem:

  1. When there is a notification popup on the Lower right corner, anything else can’t be clicked, feeling like the mouse button event is been hijacked.
  2. When you want to click something, the tooltip would swallow your click once, so that you need to click again to make it work.

Currently, I have to use cvar:

  • Slate.bAllowNotifications 0 (Update 21/09: input this one after Editor started, don’t put it in the ini file)
  • Slate.EnableTooltips 0

to workaround the issue.

Operating System: Manjaro Linux

KDE Plasma Version: 6.3.6

KDE Frameworks Version: 6.18.0

Qt Version: 6.9.2

Kernel Version: 6.12.48-1-MANJARO (64-bit)

Graphics Platform: Wayland

Processors: 32 × 13th Gen Intel® Core™ i9-13900HX

Memory: 94.0 GiB of RAM

Graphics Processor: NVIDIA GeForce RTX 4080 Laptop GPU

1 Like
2

Steps to Reproduce
Reproduce step for notification preventing mouse button click:

  1. Open the editor
  2. Open one blueprint
  3. Close editor
  4. Open the editor
  5. There should be an notification popup on the Lower right corner, asking you whether to open last opened asset(the blueprint up there)
  6. Notice you can’t click anything except the notification widget

Reproduce step for tooltip preventing mouse button click(To be confirmed):

  1. Open the editor
  2. Summon some tooltips
  3. try click something
1 Like
3

I’m definitely not seeing this with our systems. Can you attached a full log from the editor?

4

I don’t see anything out of the ordinary in your logs. Though your window manager isn’t something we normally test with, our test team (and me personally) haven’t been able to reproduce this problem. Even a quick run with KDE Plasma I didn’t see any mouse click grabbing/ignoring. Though the drop down menus are very flashy (compared to Gnome), the notification window and tool tips behaved the way it was supposed to for me.

We just released UE 5.7 preview 1. It might be interesting if you could try our pre-build Linux binaries vs the build you did from Github.

https://www.unrealengine.com/en-US/linux

It also might be interesting to try a generic template project with the pre-built binary vs your project. The switch to SDL3 for UE 5.7 involved a number of changes and there will certainly be issues with window managers.

You can also build the 5.7 preview 1 version from github. Though testing the prebuilt might be easier. If the problem persists even with the prebuilt and a template project it most likely is something to do with your environment. You’d need to narrow it down so that we could get a jira for it and triage it.

5

Would it be possible for you to test it under X11 instead of Wayland? UE 5.7 requires XWayland when running under Wayland. It appeared from your logs you are using this (the SDL video driver is reporting x11) but it is possible that is why the mouse is behaving differently. Under pure Wayland (Wayland display server and SDL3 configured to use only Wayland), UE Editor’s menus can’t be clicked with a mouse (oddly enough touch works) and there are other mouse side effects. Running Wayland + XWayland with SDL3 set to X11 mode seems to solve all those problems for us (and it looked like from your logs that’s the mode you are running). It could be something about how XWayland is configured for you or something about your specific settings.

Please try our pre-built version on a new game template project (we usually use the first person template for testing) and see if it behaves the same as your build.

6

Right now pure Wayland doesn’t appear to offer what UE/UE Editor needs. It is something we are continuing to look into, but is unlikely to improve for UE 5.7. There has been some discussion of adding a startup message to UE Editor warning when trying to run under a pure Wayland situation. However Wayland + XWayland should be a workable combination. Do you know what version of XWayland you are running? Perhaps by running

Xwayland -versionThe crash you had with the Vulkan driver is related to your video drivers. Generally updating your video driver is the only way to fix that (if possible). You can also try running UE Editor with -sm5 but it’s not recommended.

The fact you had the same problems with our pre-built binaries points to your environment as being what is different, compared to what our QA teams are testing against (primarily stock Ubuntu 22.04 with NVIDIA hardware). And the fact that KDE in X11 mode doesn’t have these mouse problems definitely points to your Wayland/XWayland setup. I did notice KDE is really not very good for UE at all. Windows flashing/redraw much more than under GNOME. Though I’m not sure what I saw was what you are describing as visual glitches.

7

That is definitely pretty bad. I’ve created a jira to track issues visual issues with KDE. I have some theories about why it’s handling those windows so badly, but it may take a bit of research to see if there is anything we can do.

We appear to be running XWayland version 22.1.1 (12201001) (matches with Ubuntu 22.04) I’m not certain your newer XWayland is a factor. We have also done testing under XWayland 23.2.6 (Ubuntu 24.04).

1 Like
8

> You can also build the 5.7 preview 1 version from github.

I’ve try updated to commit e35804760556ece1685f50ea6c1392ab428d7272 29/09/25 of 5.7 branch, with no luck.

Might try other options later.

9

> the SDL video driver is reporting x11

Yes, from the callstack, I can see it’s coming from X11.

> test it under X11

I can do it later in the day, but I don’t think I’m willing to work under X11, because everything default to wayland nowadays.

> Under pure Wayland (Wayland display server and SDL3 configured to use only Wayland)

I tried this just now, with:

  • set environment variable : SDL_VIDEODRIVER=wayland
  • modified “SDL3.Build.cs”, adding "PublicDefinitions.Add(“SDL_VIDEO_DRIVER_X11=0”); and PublicDefinitions.Add(“SDL_VIDEO_DRIVER_WAYLAND=1”);
  • start KDE in wayland mode

Indeed, the mouse can’t be clicked, but after specify “Slate.EnableTooltips=0” in DefaultEngine.ini, it can be clicked now.

Other side effects observed:

  1. the left-click/sub menu always opened on the center of screen
  2. some visual offsets between where the mouse at VS what the mouse is actually hovering

> It could be something about how XWayland is configured for you or something about your specific settings.

I don’t think I could mess with these settings before. Those should be defaulted.

Will try pre-built version today and update the result here.

10 
Assertion failed: NumFormats > 0 [File:./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp] [Line: 180] 
 
 
 
 
libUnrealEditor-Core.so!FDebug::CheckVerifyFailedImpl2(char const*, char const*, int, char16_t const*, ...) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Core/Private/Misc/AssertionMacros.cpp:741]
 
libUnrealEditor-VulkanRHI.so!FVulkanSwapChain::FVulkanSwapChain(VkInstance_T*, FVulkanDevice&, EPixelFormat&, unsigned int, unsigned int, bool, unsigned int*, TArray<VkImage_T*, TSizedDefaultAllocator<32> >&, signed char, FVulkanGenericPlatformWindowContext&, FVulkanSwapChainRecreateInfo*) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/VulkanRHI/Private/VulkanSwapChain.cpp:180]
 
libUnrealEditor-VulkanRHI.so!FVulkanViewport::CreateSwapchain(FVulkanCommandListContext&, FVulkanSwapChainRecreateInfo*, FVulkanGenericPlatformWindowContext&) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:420]
 
libUnrealEditor-VulkanRHI.so!FVulkanViewport::RecreateSwapchain(FVulkanCommandListContext&, FVulkanGenericPlatformWindowContext&) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:303]
 
libUnrealEditor-VulkanRHI.so!FVulkanViewport::Present(FVulkanCommandListContext&, FVulkanQueue*, bool) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/VulkanRHI/Private/VulkanViewport.cpp:718]
 
libUnrealEditor-VulkanRHI.so!FVulkanCommandListContext::RHIEndDrawingViewport(FRHIViewport*, bool, bool) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/VulkanRHI/Private/VulkanRHI.cpp:1283]
 
libUnrealEditor-RHI.so!FRHICommand<FRHICommandEndDrawingViewport, FRHICommandEndDrawingViewportString2514>::ExecuteAndDestruct(FRHICommandListBase&) [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/RHI/Public/RHICommandListCommandExecutes.inl:565]
 
libUnrealEditor-RHI.so!FRHICommandListBase::Execute() [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/RHI/Private/RHICommandList.cpp:542]
 
libUnrealEditor-RHI.so!FRHICommandListExecutor::FTranslateState::Translate(FRHICommandListBase*) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/RHI/Private/RHICommandList.cpp:1092]
 
libUnrealEditor-RHI.so!UE::Core::Private::Function::TFunctionRefCaller<FRHICommandListExecutor::FSubmitState::Dispatch(FRHICommandListBase*)::$_0, void>::Call(void*) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/RHI/Private/RHICommandList.cpp:1043]
 
libUnrealEditor-RHI.so!FRHICommandListExecutor::FTaskPipe::Execute(FRHICommandListExecutor::FTaskPipe::FTask*, TRefCountPtr<FBaseGraphTask> const&) const [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/Core/Public/Templates/Function.h:414]
 
libUnrealEditor-Core.so!TGraphTask<TFunctionGraphTaskImpl<void (ENamedThreads::Type, TRefCountPtr<FBaseGraphTask> const&), (ESubsequentsMode::Type)0> >::ExecuteTask() [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/Core/Public/Templates/Function.h:414]
 
libUnrealEditor-Core.so!UE::Tasks::Private::FTaskBase::TryExecuteTask() [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/Core/Public/Tasks/TaskPrivate.h:518]
 
libUnrealEditor-Core.so!FNamedTaskThread::ProcessTasksNamedThread(int, bool) [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/Core/Public/Async/TaskGraphInterfaces.h:495]
 
libUnrealEditor-Core.so!FNamedTaskThread::ProcessTasksUntilQuit(int) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Core/Private/Async/TaskGraph.cpp:679]
 
libUnrealEditor-RenderCore.so!FRHIThread::Run() [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/RenderCore/Private/RenderingThread.cpp:212]
 
libUnrealEditor-Core.so!FRunnableThreadPThread::Run() [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Core/Private/HAL/PThreadRunnableThread.cpp:25]
 
libUnrealEditor-Core.so!FRunnableThreadPThread::_ThreadProc(void*) [/mnt/horde/++UE5/Sync/Engine/Source/Runtime/Core/Private/HAL/PThreadRunnableThread.h:187]
 
libc.so.6!UnknownFunction(0x969ca)
 
libc.so.6!UnknownFunction(0x11aa0b)

Forget to mention that ​when under pure Wayland, the editor would crash with just some mouse hovering around.

The callstack is coming from the pre-built version

1 Like
11 
Caught signal 6 Aborted
 
libX11.so.6!XIfEvent(+0x74)
libX11.so.6!UnknownFunction(0x728ef)
libX11.so.6!UnknownFunction(0x74073)
libX11.so.6!_XimRead(+0x51)
libX11.so.6!UnknownFunction(0x61f7a)
libUnrealEditor-ApplicationCore.so!X11_StartTextInput [/SDL-gui-backend/src/video/x11/SDL_x11keyboard.c:683]
libUnrealEditor-ApplicationCore.so!SDL_SetKeyboardFocus [/SDL-gui-backend/src/events/SDL_keyboard.c:373]
libUnrealEditor-ApplicationCore.so!X11_DispatchEvent [/SDL-gui-backend/src/video/x11/SDL_x11events.c:475]
libUnrealEditor-ApplicationCore.so!X11_PumpEvents [/SDL-gui-backend/src/video/x11/SDL_x11events.c:2145]
libUnrealEditor-ApplicationCore.so!SDL_PumpEventsInternal [/SDL-gui-backend/src/events/SDL_events.c:1453]
libUnrealEditor-ApplicationCore.so!SDL_WaitEventTimeoutNS [/SDL-gui-backend/src/events/SDL_events.c:1628]
libUnrealEditor-ApplicationCore.so!FLinuxPlatformApplicationMisc::PumpMessages(bool) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/ApplicationCore/Private/Linux/LinuxPlatformApplicationMisc.cpp:458]
UnrealEditor!FEngineLoop::Tick() [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Launch/Private/LaunchEngineLoop.cpp:5773]
UnrealEditor!GuardedMain(char16_t const*) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Launch/Private/Launch.cpp:60]
libUnrealEditor-UnixCommonStartup.so!CommonUnixMain(int, char**, int (*)(char16_t const*), void (*)()) [/mnt/horde/++UE5/Sync/Engine/Source/./Runtime/Unix/UnixCommonStartup/Private/UnixCommonStartup.cpp:323]
libc.so.6!UnknownFunction(0x27674)
libc.so.6!__libc_start_main(+0x88)

> Running Wayland + XWayland with SDL3 set to X11 mode seems to solve all those problems for us

But I encountered all the same problems with the pre-built version.

As you can see from the video, I followed the "Steps to Reproduce" up there, and I got the problem described before

  • double click
  • can’t click anything

It make my plasmashell crashes, so the background is black. I can’t click anything, so I killed the app with task manager, and got the callstack above,

1 Like
12

> Would it be possible for you to test it under X11 instead of Wayland?

After running KDE in X11 mode, looks like all the problems are gone, except there are some visual glitches everywhere.

Are you going to provide usable support for Wayland though?

1 Like
13

> Xwayland -version

The X.Org Foundation Xwayland Version 24.1.8 (12401008)

X Protocol Version 11, Revision 0

14

Can’t use screen recorder under X11, so I recorded it with my phone:

notice the visual of tooltip