Bug 359157 - Unreal Tournament 4 first startup causes partial freezing
Summary: Unreal Tournament 4 first startup causes partial freezing
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 5.5.4
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-08 23:07 UTC by Unknown
Modified: 2021-12-06 04:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Output of xwininfo -root -tree (4.99 KB, text/plain)
2016-02-17 17:14 UTC, Unknown
Details
xwininfo -root -tree (2) (8.15 KB, text/plain)
2016-02-19 17:45 UTC, Unknown
Details
xwininfo for UT4 main window (616 bytes, text/plain)
2016-02-19 17:46 UTC, Unknown
Details
xwininfo for the dialog (603 bytes, text/plain)
2016-02-19 17:46 UTC, Unknown
Details
xprop for UT4 main window (1.37 KB, text/plain)
2016-02-19 17:47 UTC, Unknown
Details
xprop for the dialog (881 bytes, text/plain)
2016-02-19 17:47 UTC, Unknown
Details
Screen glitch when UT4 starts (259.74 KB, image/png)
2016-02-22 12:13 UTC, Unknown
Details
Screen glitch with KWin 5.5.5 (235.48 KB, image/png)
2016-03-04 14:27 UTC, Unknown
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2016-02-08 23:07:00 UTC
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.
Comment 1 Thomas Lübking 2016-02-08 23:21:26 UTC
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"
Comment 2 Unknown 2016-02-17 17:14:26 UTC
Created attachment 97267 [details]
Output of xwininfo -root -tree
Comment 3 Unknown 2016-02-17 17:16:32 UTC
xwininfo -root -tree shows multiple entries (see attachment) related to UT4 - which entries should be chosen to be checked by xprop and xwininfo?
Comment 4 Thomas Lübking 2016-02-17 21:44:02 UTC
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)
Comment 5 Unknown 2016-02-19 17:45:48 UTC
Created attachment 97302 [details]
xwininfo -root -tree (2)
Comment 6 Unknown 2016-02-19 17:46:26 UTC
Created attachment 97303 [details]
xwininfo for UT4 main window
Comment 7 Unknown 2016-02-19 17:46:55 UTC
Created attachment 97304 [details]
xwininfo for the dialog
Comment 8 Unknown 2016-02-19 17:47:24 UTC
Created attachment 97305 [details]
xprop for UT4 main window
Comment 9 Unknown 2016-02-19 17:47:50 UTC
Created attachment 97306 [details]
xprop for the dialog
Comment 10 Unknown 2016-02-19 17:49:27 UTC
Added xwininfo and xprop outputs and a new list. What do you mean by updating the tree?
Comment 11 Thomas Lübking 2016-02-19 20:31:57 UTC
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?
Comment 12 Unknown 2016-02-22 12:13:27 UTC
Created attachment 97355 [details]
Screen glitch when UT4 starts
Comment 13 Unknown 2016-02-22 12:15:09 UTC
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.
Comment 14 Unknown 2016-02-22 12:20:14 UTC
Also, setting focus stealing prevention to "none" did not have any apparent effect.
Comment 15 Thomas Lübking 2016-02-22 23:08:41 UTC
(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?
Comment 16 Unknown 2016-02-23 09:17:53 UTC
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.
Comment 17 Thomas Lübking 2016-02-23 12:03:21 UTC
(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?
Comment 18 Unknown 2016-02-23 18:05:46 UTC
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.
Comment 19 Thomas Lübking 2016-02-23 18:09:16 UTC
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?)
Comment 20 Thomas Lübking 2016-02-23 18:13:00 UTC
Nope, doesn't happen with fullscreen jedit :-(
Comment 21 Unknown 2016-02-23 23:01:39 UTC
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/
Comment 22 Unknown 2016-03-04 14:27:56 UTC
Created attachment 97680 [details]
Screen glitch with KWin 5.5.5
Comment 23 Unknown 2016-03-04 14:30:00 UTC
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.
Comment 24 Thomas Lübking 2016-03-04 14:51:55 UTC
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.
Comment 25 kde.org 2021-11-06 17:35:50 UTC
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
Comment 26 Bug Janitor Service 2021-11-21 04:39:08 UTC
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!
Comment 27 Bug Janitor Service 2021-12-06 04:38:30 UTC
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!