When starting up Unreal Tournament 4 for the first time, it shows a dialog asking whether you accept the EULA or not. However, this dialog is not shown when KWin is used. Instead, the screen gets unresponsive. Alt+Tab works and you can see the dialog there, but you can't switch to it. Apparently, the only way to continue is to switch to another tty and kill the process. With Openbox, the dialog appears (although minimized) and you can choose "yes" there. After the first startup, the game starts correctly with KWin as well. Similar issue and solution reported here: https://forums.unrealtournament.com/showthread.php?19828-Unable-to-launch-game-screen-freezes Reproducible: Always Steps to Reproduce: 1. Start UT4 for the first time (cd <programdir>/Engine/Binaries/Linux && ./UE4-Linux-Test UnrealTournament) Actual Results: No first start dialog appears and desktop gets unresponsive. Expected Results: First start dialog should appear; it appears correctly with Openbox. UT4 builds 2771652 and 2848065 tested.
Afaiu kwin and openbox do act pretty similar - a minimized dialog is added (but I assume that's not what unreal wanted to achieve) My guess is that the client reversed the desired transiency and the (fullscreen) game window is transient for its dialog, so whenever you try to activate the dialog, you get the game window (which is likely uninitialized, explaining "screen gets unresponsive. Alt+Tab works") active instead (and it's also always on top of the dialog) Can you switch to the other VT and dump "xprop" and "xwininfo" on game window and dialog? Both take an "-id" parameter and "xwininfo -root -tree" will print a list of all windows. Don't forget to "export DISPLAY=:0"
Created attachment 97267 [details] Output of xwininfo -root -tree
xwininfo -root -tree shows multiple entries (see attachment) related to UT4 - which entries should be chosen to be checked by xprop and xwininfo?
Those look fishy: 0x2600040 "UE4 Dummy GL window": ("UE4-Linux-Test" "UE4-Linux-Test") 1x1+0+0 +0+0 0x260003d "UE4 Dummy GL window": ("UE4-Linux-Test" "UE4-Linux-Test") 1x1+0+0 +0+0 But the relevant should be the game: 0x2600043 "UnrealTournament (64-bit, GLSL_150)": ("UE4-Linux-Test" "UE4-Linux-Test") and the dialog: 0x2e00002 "READ ME FIRST": () 505x146+0+0 +711+340 Basically all unreal related windows with names (the outer ones are technical wrappers) Please update the tree as well when obtaining the wininfo and props (so we can see the window relation in case the windows are not directly transient to each other - the id's change with restarting the game)
Created attachment 97302 [details] xwininfo -root -tree (2)
Created attachment 97303 [details] xwininfo for UT4 main window
Created attachment 97304 [details] xwininfo for the dialog
Created attachment 97305 [details] xprop for UT4 main window
Created attachment 97306 [details] xprop for the dialog
Added xwininfo and xprop outputs and a new list. What do you mean by updating the tree?
Nope, it's (most likely just) focus stealing prevention. The dialog has no WM_CLASS nor any other relation to it's main window (the game) So not only is it NOT a transient (ie. marked to always stay above the game what's likely desired) nor can kwin determine that it's a related window. So it denies activation (and raising) This patch may resolve this (at least let it raise above) https://git.reviewboard.kde.org/r/124130/ The actual problem though is the complete lack of hints on the dialog, notably not being a transient as could be expected. You can confirm the above by setting the focus stealing prevention to "none" in "kcmshell5 kwinoptions", first tab. That however doesn't explain the inability to successfully focus the dialog. It neither provides WM_HINTS, but should be considered to take focus by default. What's suspicious is that the game window denies focus resp. relies on the wonky WM_TAKE_FOCUS protocol (*sigh*, I thought Java was the last remainder) to handle the focus assignment itself. => Can you activate any (other) window when alt+tabbing away from the game window and if so, what happens when you try to alt+tab to the dialog (not! the game) from that 3rd (eg. kwrite or dolphin) window?
Created attachment 97355 [details] Screen glitch when UT4 starts
Switching to another window by Alt+Tab is not possible. If compositing is on, you can preview the windows, but not switch to them. If compositing is off, it's not even possible to preview. Also, the screen gets glitched when UT4 starts, see attachment. Parts of the screen content shift upwards and right.
Also, setting focus stealing prevention to "none" did not have any apparent effect.
(In reply to antti from comment #13) > Switching to another window by Alt+Tab is not possible. If compositing is > on, you can preview the windows, but not switch to them. That's terribly odd - a client should not be able to maintain the focus against the users distribution. * You can alt+tab, so the window will likely not grab the keyboard (can you Alt+F3, which should bring you the window context menu?) * The window isn't set to keep above others, so it's not that it would simply still cover the new active window. Any chance to test the patch that fixed bug #347153 ? (https://git.reviewboard.kde.org/r/126753/ or upcoming KWin 5.6) The screen glitch is an uncomposited shot?
The screenshot is uncomposited, but the glitch occurs also when compositing is enabled. Alt+F3 works, apparently for both the dialog and the main window, and the context menu appears. It's possible to move the dialog by choosing "move" in the context menu; the menu appears in a different place after moving. But I didn't find any way to make the window visible.
(In reply to antti from comment #16) > The screenshot is uncomposited Means that the client creates a window with undefined (or inherited) background and then shifts it a bit - you see the UT4 window, containing a desktop "screenshot". > Alt+F3 works, apparently for both the dialog and the main window, and the > context menu appears. It's possible to move the dialog by choosing "move" So the client doesn't grab any input (i worried it might forward Alt+Tab) > didn't find any way to make the window visible. What bothers me much more is that you're not able to activate *any* window while UT4 is there - and there's no apparent reason for this behavior (only a grabbed input should cause this) Although: if you alt+tab to kwrite and then (blindly) enter some text - does it end up in kwrite or UT4?
Yes - Alt+Tab to text editor -> type text -> it appears in the editor after killing the UT4 processes (there are actually 2 of them). I'll try KWin 5.6 when it gets to Arch Linux repos.
Won't do - this means activation works, just the stack isn't altered. Could relate to the fullscreen mode and the weird activation protocol, resulting in the wrong assumption that the window is still active. This might be testable with those java clients, gonna give it a try. (UT4 is some private beta?)
Nope, doesn't happen with fullscreen jedit :-(
UT4 is currently in pre-alpha stage. It's freely available (and will always be) but the developers have asked to not post the direct download links publicly. The link is available on the forums after registration: https://forums.unrealtournament.com/
Created attachment 97680 [details] Screen glitch with KWin 5.5.5
KWin 5.5.5 tested - bug still present. However, the screen gets glitched in a different way. If UT4 is started in windowed mode (add -windowed command line parameter), the dialog appears correctly. New UT4 build 2883976 not yet tested.
The "glitch" won't relate to kwin, notably since the compositor is down (and is likely unrelated to the stack alteration) It could point a driver issue where the (uncomposited) stack isn't reflected by the visuals on-screen, but that's it.
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!