How do I keep KWin’s influence to a minimum on a particular app?

oldcastle · 2022-05-03 10:12:42

Hi guys,

I REALLY hope someone can help me here. I have an issue with KWin affecting an app that I run via Wine. I’m running MuLab 9 demo via Wine, and everything works fine, except for one issue. When you open ML9 and right-click on any track head, and then click on "Choose Target Module" as in the image, the window goes on and off instantly. It likes that the new window that should pop up stays behind the main window.

Why do I think there is something to do with KWin? Because if I use KDE with Openbox, I can keep that window on top, holding CTRL or SHIFT when I click on "Choose Target Module". That works!

https://i.imgur.com/Vfverwe.png

Another clue that the problem may be with KWin is a workaround found here, where you just need to uncheck the option Allow the window manager to control the windows on winecfg. That option basically takes the app away from KWin control. However, this workaround has some minor problems, too.

So, my question is, is there a way I can create Windows Rules to minimise the influence of KWin on an app? My logic is that if the app works with Openbox and it works when I don't allow the WM to control the window (via Wine winecfg), maybe it will work if I can reduce the "influence or impact" of Kwin on the app.

Any thoughts?

Mod edit: Replaced oversized image with URL. Please read the General Guidelines and adhere to the image posting rules. -- WorMzy

Last edited by WorMzy (2022-05-03 12:50:47)

seth · 2022-05-03 12:30:15

"kcmshell5 kwinrules", look around focus stealing prevention configurations.
(That's a guess, idk what the client does there, but it sounds like a focus issue)

oldcastle · 2022-05-03 12:55:37

Thanks, but it didn't work. Still the same behaviour.

seth · 2022-05-03 13:00:49

"It" "didn't work" *how*?
Focus management is icky - you want to disable or enforce the focus stealing prevention for the right window - w/o understanding what's going on there're at least 4 combinations on teh extreme ends. Did you try them all?

oldcastle · 2022-05-03 13:17:57

I tried all the possible combinations. I don't think is that.

seth · 2022-05-03 13:23:22

For clarification: you click an entry in that popup menu, then a new window appears, but that drops behind the main window immediately?
And does the main window at this point have the keyboard focus?

oldcastle · 2022-05-03 13:35:08

- correct
- it does

seth · 2022-05-03 13:41:34

So instead of the second widow getting the focus, the first one gets.
a) what's the global focus strategy setting?
b) Does the new window spawn below the mouse cursor? (ties into "a")
c) Did you try to raise the focus stealing prevention for that window, to lock the focus in there? (Though depending on "a" and "b" and whether your focus strategy is an "unreasonable" one, that might not help indeed)

oldcastle · 2022-05-03 13:46:55

If I understood right:

a) default -> i didn't change anything
b) no
c) yes, I did try.

seth · 2022-05-03 14:10:24

a) default -> i didn't change anything

Do you have to click windows for them to get the input focus?
The only supposed way around an extreme focus stealing prevention is when the demand claims to come from a taskmanager etc.

Wild guess: is this a wayland session?

oldcastle · 2022-05-03 14:16:17

KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.93.0
Qt Version: 5.15.3
Kernel Version: 5.15.36-1-lts (64-bit)
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-8565U CPU @ 1.80GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620
Wine: wine-staging

seth · 2022-05-03 14:23:09

seth wrote:

Do you have to click windows for them to get the input focus?
The only supposed way around an extreme focus stealing prevention is when the demand claims to come from a taskmanager etc.

oldcastle · 2022-05-03 16:20:05

Everything else is working fine. Can you replicate the issue?

seth · 2022-05-03 19:48:01

I've not been using KDE in years and no intention to install some windows demo version.

You've not answerd my previous question twice and I'll point out that from the symptoms this *is* some focus stealing issue (the popup is probably showing up as regular window, taking the focus and when the focus gets returned, that goes wrong - stealing the focus away from the new window)
A typical cause would be some (strictly) under the mouse focus policy that also evades all stealing prevention mechanisms - rather than the "focus follows mouse" policy.

oldcastle · 2022-05-03 20:34:00

seth wrote:

Do you have to click windows for them to get the input focus?

Yes.

I noticed the same thing with others DE (gnome, xfce and mate), but not Openbox. You don't need to install Windows, just Wine. The Windows program is portable, it's just an .exe file.

seth · 2022-05-03 21:08:21

Properties of the "Choose Target Module" subwindow

xwininfo: Window id: 0x4200041 (has no name)

  Absolute upper-left X:  412
  Absolute upper-left Y:  83
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 280
  Height: 817
  Depth: 24
  Visual: 0x21
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x3e00001 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +412+83  -748+83  -748-0  +412-0
  -geometry 280x817+412-0

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_CLOSE
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ICON(CARDINAL) = 	Icon (37 x 37):
	                                                                           
	                                                                           
	                               ░░░░░░░░░░░░░░                              
	                         ░░▒▒░░░░░░      ░░░░░░▒▒░░                        
	                         ░░▒▒░░░░░░      ░░░░░░▒▒░░                        
	                   ░░▒▒▒▒░░                      ░░▒▒▒▒░░                  
	                 ░░░░                                  ░░░░                
	               ░░░░                                      ░░░░              
	             ░░░░    ░░░░                                  ░░░░            
	           ░░▒▒  ░░░░░░░░░░                                ░░▒▒░░          
	           ▒▒░░░░░░░░░░░░░░░░    ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒          
	           ▒▒░░░░░░░░░░░░░░░░    ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒          
	       ░░░░░░  ░░░░░░░░░░░░░░░░  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒░░░░      
	       ▒▒▒▒░░░░░░░░░░░░░░░░░░░░    ░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒▒▒      
	       ░░░░░░▒▒░░░░░░░░░░░░░░░░░░  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒      
	     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒░░    
	     ░░░░░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░    ░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒░░    
	     ░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒    ░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒░░    
	     ░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒    ░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒░░    
	     ░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░░░  ░░░░░░░░░░░░░░░░░░░░░░░░▒▒▒▒░░    
	     ░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░    
	     ░░▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░    
	       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒  ░░░░░░░░░░░░░░░░░░░░░░░░░░      
	       ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░░  ░░░░░░░░░░░░░░░░░░░░▒▒▒▒      
	       ░░░░▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░    ░░░░░░░░░░░░░░░░░░░░░░      
	           ▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ░░░░░░░░░░░░░░░░▒▒          
	           ▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ░░░░░░░░░░░░░░░░▒▒          
	           ░░▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  ░░░░░░░░░░  ▒▒░░          
	             ▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░          ░░▒▒            
	               ▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░▒▒              
	                 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                
	                   ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░                  
	                         ░░░░░░░░░░░░░░░░░░░░░░░░░░                        
	                         ░░░░░░░░░░░░░░░░░░░░░░░░░░                        
	                             ░░░░░░░░░░░░░░░░░░                            
	                                                                           
	                                                                           


_NET_WM_STATE(ATOM) = _NET_WM_STATE_ABOVE, _NET_WM_STATE_SKIP_TASKBAR, _NET_WM_STATE_SKIP_PAGER
_NET_WM_NAME(UTF8_STRING) = 
WM_ICON_NAME(STRING) = 
WM_NAME(STRING) = 
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		Initial state is Normal State.
		bitmap id # to use for icon: 0x3e03a53
		bitmap id # of mask for icon: 0x3e03a55
		window id # of group leader: 0x4200041
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x24, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 412, 83
		program specified minimum size: 280 by 817
		program specified maximum size: 280 by 817
		window gravity: Static
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x3e0000f
XdndAware(ATOM) = BITMAP
WM_CLASS(STRING) = "mulab.exe", "mulab.exe"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, _NET_WM_PING, WM_TAKE_FOCUS

The main window is similar.
I was able to reliably show the window by running "xev -event substructure -root" next to it, otherwise the behavior was erratic (w/ or w/o the shift key) - the reason why this is so broken and why the kwin focus rules won't help, is

Client accepts input or input focus: False
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, _NET_WM_PING, WM_TAKE_FOCUS

The client manages the focus distribution itself, using the godawful WM_TAKE_FOCUS protocol. Otoh it doesn't provide the transient_for hints.
The kwin rules should also allow you to force the window to accept the focus, enabling the focus stealing prevention mechanisms - it might be though, that the client ends up confused about the focus state.

This is btw. not down to kwin or any other WM, the openbox situation is likely exploiting some race condition and the client following an absurd protocol that's akin to cooperative multitasking…

oldcastle · 2022-05-03 21:14:27

Thank you so much for your help.

If I understood right, there is no way to "fix" it. So, the best bet is to talk to the developer, right?

PS: Where and how did you run "xev -event substructure -root"?

Last edited by oldcastle (2022-05-03 21:20:46)

seth · 2022-05-03 21:30:14

Did you try to add a rule to enforce focus handling by the WM?
Not sure whether you'll get some response for a request to fix the wine/linux behavior of a windows program…

The WM_TAKE_FOCUS seems to be common for wine windows.
No idea why the specific client causes so much trouble and how much this is application specific (ie. whether the focus handling is supposed to be completely handled by wine or whether it forwards some windows API), but it does seem that the window reacts to changes in the active window and my guess is that this turns into a race between the main window (claiming focus and becoming active when the popup closes) and the target module window when the context "popup" closes.

Edit: in a terminal - I wanted to monitor what was going on when the windows show/shide.
The impact on the X11 event processing might have serialized them enough to stabilize the client, but it might also have been random luck by adding just enough context switches.

Last edited by seth (2022-05-03 21:33:01)

Arch Linux

#1 2022-05-03 10:12:42

How do I keep KWin’s influence to a minimum on a particular app?

#2 2022-05-03 12:30:15

Re: How do I keep KWin’s influence to a minimum on a particular app?

#3 2022-05-03 12:55:37

Re: How do I keep KWin’s influence to a minimum on a particular app?

#4 2022-05-03 13:00:49

Re: How do I keep KWin’s influence to a minimum on a particular app?

#5 2022-05-03 13:17:57

Re: How do I keep KWin’s influence to a minimum on a particular app?

#6 2022-05-03 13:23:22

Re: How do I keep KWin’s influence to a minimum on a particular app?

#7 2022-05-03 13:35:08

Re: How do I keep KWin’s influence to a minimum on a particular app?

#8 2022-05-03 13:41:34

Re: How do I keep KWin’s influence to a minimum on a particular app?

#9 2022-05-03 13:46:55

Re: How do I keep KWin’s influence to a minimum on a particular app?

#10 2022-05-03 14:10:24

Re: How do I keep KWin’s influence to a minimum on a particular app?

#11 2022-05-03 14:16:17

Re: How do I keep KWin’s influence to a minimum on a particular app?

#12 2022-05-03 14:23:09

Re: How do I keep KWin’s influence to a minimum on a particular app?

#13 2022-05-03 16:20:05

Re: How do I keep KWin’s influence to a minimum on a particular app?

#14 2022-05-03 19:48:01

Re: How do I keep KWin’s influence to a minimum on a particular app?

#15 2022-05-03 20:34:00

Re: How do I keep KWin’s influence to a minimum on a particular app?

#16 2022-05-03 21:08:21

Re: How do I keep KWin’s influence to a minimum on a particular app?

#17 2022-05-03 21:14:27

Re: How do I keep KWin’s influence to a minimum on a particular app?

#18 2022-05-03 21:30:14

Re: How do I keep KWin’s influence to a minimum on a particular app?

Board footer