Bspwm: Closing WINE windows causes hang before removal

[shinyquagsire23]

While it's not the worst bug, it's definitely jarring for people who frequently use Wine for programs which aren't on Windows. Basically the issue is that Wine windows do not close immediately like they do in other window managers, rather they will hang for a bit before closing. My best guess is that during this hang other WMs will hide the window and allow the parent window to be focused, however in bspwm the parent window (and any other child windows of the parent) are unable to be focused, forcing you to wait for the removal of the closed child.

To recreate the issue, you can spawn a Wine window from any program and close it, and it will cause a hang. Spawning child windows from a wine program and closing them will also prevent access to the parent window.

Currently I'm using no other altered setting other than defaulting Wine windows to floating and enabling compton to prevent any drawing oddities. Also compiled + installed latest version from repo, no change.

[mixedCase]

Can confirm.

[baskerville]

Maybe the output of xev -root, and xev -id WINDOW_ID reveals significant differences when closing a normal window and a _Wine_ window?

[mixedCase]

I get around 10 DestroyNotify events with Wine windows, compared to a single one in other applications. Can you reproduce @baskerville ?

[lc-guy]

can confirm too.
I also get around 10 DestroyNotify events.

[baskerville]

What's the output of xprop for the _Wine_ window?

[mixedCase]

https://gist.github.com/mixedCase/29fbb406ea3147cf69beb3729a59ce94

This is for winecfg, although almost all Wine applications are affected. And I say almost all only because I believe I once saw a window die right away when ordered to close, but don't quote me on that.

[baskerville]

Of course, you've tried killing (node -k) instead of closing?

I won't install _Wine_, so please post the full output of xev -root and xev -id WINDOW_ID while closing the window.

Is _Wine_ working as expected in _i3-wm_?

[neeasade]

With winecfg like in the above here, hang happens with bspc node -c, but window closes instantly with bspc node -k.

[mixedCase]

xev -root https://gist.github.com/mixedCase/f3d34eab1803f9db21512404adb7c86e

xev -id WINDOW_ID https://gist.github.com/mixedCase/6b5c7c153ef5475f4ffe842da9c3f9af

I was able to reproduce @neeasade's experiences. node -c hangs before closing just like closing from the application would, and node -k inmediately closes the window.

[baskerville]

Output of xlsw -r?

[mixedCase]

Is that the right name for the binary? I don't have it and my shell hook can't find it on repos, plus googling turns up nothing.

[lc-guy]

xlsw -r output: http://comfy.moe/aqjbqf.txt

[lc-guy]

I would also like to mention that deactivating the "Allow the window manager to control the windows" checkbox in winecfg fixes the issue. (of course, this makes wine windows behave weirdly with bspwm.)

[lc-guy]

anything new on this?

[lc-guy]

still happening...

[eigengrau]

I’ve been observing a (possibly related?) issue when running applications via wine. In certain applications (e.g., Windows Steam), context menu windows are placed in unexpected locations. E.g., when a context menu in triggered somewhere on the top left of the screen, it pops up in the center of the screen.

The displacement issue disappears when setting the Steam window to manage=off. However, this does not address the several seconds of lag when a context menu is being closed. Curiously, winecfg also has an option to make wine windows not be managed by the WM. Enabling this option resolves both the lag issue as well as the displacement. Of course, this is not ideal since wine windows then appear statically floated on every desktop.

[shinyquagsire23]

Anything new on this? Is there anything that can be done to help figure out why this is happening? If it were a regression, the earliest report of this was in March 2014, but this is still an issue and it's honestly kinda breaking.

Looking between xev and x11trace, the output between closing a normal app and a wine app actually looks fairly similar, however perhaps the source of confusion may be that both commands don't have any sort of timestamps? Here's the output of xev -root | awk '{ print strftime("%Y-%m-%d %H:%M:%S"), $0; fflush(); }' from me closing winecfg:

2016-09-25 12:58:18 
2016-09-25 12:58:18 PropertyNotify event, serial 18, synthetic NO, window 0xf6,
2016-09-25 12:58:18     atom 0x13b (_NET_ACTIVE_WINDOW), time 78053296, state PropertyNewValue
2016-09-25 12:58:18 
2016-09-25 12:58:18 PropertyNotify event, serial 18, synthetic NO, window 0xf6,
2016-09-25 12:58:18     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78053296, state PropertyNewValue
2016-09-25 12:58:20 
2016-09-25 12:58:20 FocusIn event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:20     mode NotifyGrab, detail NotifyInferior
2016-09-25 12:58:20 
2016-09-25 12:58:20 KeymapNotify event, serial 20, synthetic NO, window 0x0,
2016-09-25 12:58:20     keys:  4294967265 0   0   2   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:20            32  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:20 
2016-09-25 12:58:20 FocusOut event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:20     mode NotifyUngrab, detail NotifyInferior
2016-09-25 12:58:22 
2016-09-25 12:58:22 UnmapNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200001, from_configure NO
2016-09-25 12:58:22 
2016-09-25 12:58:22 FocusIn event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     mode NotifyNormal, detail NotifyInferior
2016-09-25 12:58:22 
2016-09-25 12:58:22 KeymapNotify event, serial 20, synthetic NO, window 0x0,
2016-09-25 12:58:22     keys:  1   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:22            0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:22 
2016-09-25 12:58:22 Expose event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     (966,148), width 19, height 454, count 0
2016-09-25 12:58:22 
2016-09-25 12:58:22 UnmapNotify event, serial 20, synthetic YES, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200001, from_configure NO
2016-09-25 12:58:22 
2016-09-25 12:58:22 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     atom 0x178 (_NET_CLIENT_LIST), time 78056756, state PropertyNewValue
2016-09-25 12:58:22 
2016-09-25 12:58:22 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78056756, state PropertyNewValue
2016-09-25 12:58:22 
2016-09-25 12:58:22 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     atom 0x13b (_NET_ACTIVE_WINDOW), time 78056757, state PropertyNewValue
2016-09-25 12:58:22 
2016-09-25 12:58:22 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78056757, state PropertyNewValue
2016-09-25 12:58:22 
2016-09-25 12:58:22 FocusOut event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     mode NotifyNormal, detail NotifyInferior
2016-09-25 12:58:22 
2016-09-25 12:58:22 ConfigureNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200001, (845,152), width 410, height 446,
2016-09-25 12:58:22     border_width 4, above 0x2800009, override NO
2016-09-25 12:58:22 
2016-09-25 12:58:22 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200001
2016-09-25 12:58:22 
2016-09-25 12:58:22 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200002
2016-09-25 12:58:22 
2016-09-25 12:58:22 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x3200003
2016-09-25 12:58:22 
2016-09-25 12:58:22 ClientMessage event, serial 21, synthetic YES, window 0x2c00004,
2016-09-25 12:58:22     message_type 0x146 (_NET_WM_STATE), format 32
2016-09-25 12:58:22 
2016-09-25 12:58:22 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 12:58:22     event 0xf6, window 0x300000d

vs. gedit

2016-09-25 13:00:09 
2016-09-25 13:00:09 PropertyNotify event, serial 18, synthetic NO, window 0xf6,
2016-09-25 13:00:09     atom 0x13b (_NET_ACTIVE_WINDOW), time 78164015, state PropertyNewValue
2016-09-25 13:00:09 
2016-09-25 13:00:09 PropertyNotify event, serial 18, synthetic NO, window 0xf6,
2016-09-25 13:00:09     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78164015, state PropertyNewValue
2016-09-25 13:00:12 
2016-09-25 13:00:12 FocusIn event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     mode NotifyGrab, detail NotifyInferior
2016-09-25 13:00:12 
2016-09-25 13:00:12 KeymapNotify event, serial 20, synthetic NO, window 0x0,
2016-09-25 13:00:12     keys:  4294967265 0   0   2   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 13:00:12            32  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 13:00:12 
2016-09-25 13:00:12 UnmapNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e000f8, from_configure NO
2016-09-25 13:00:12 
2016-09-25 13:00:12 FocusIn event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     mode NotifyWhileGrabbed, detail NotifyInferior
2016-09-25 13:00:12 
2016-09-25 13:00:12 KeymapNotify event, serial 20, synthetic NO, window 0x0,
2016-09-25 13:00:12     keys:  4294967265 0   0   2   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 13:00:12            32  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 13:00:12 
2016-09-25 13:00:12 Expose event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     (966,184), width 19, height 737, count 0
2016-09-25 13:00:12 
2016-09-25 13:00:12 UnmapNotify event, serial 20, synthetic YES, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e000f8, from_configure NO
2016-09-25 13:00:12 
2016-09-25 13:00:12 DestroyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e000f8
2016-09-25 13:00:12 
2016-09-25 13:00:12 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     atom 0x178 (_NET_CLIENT_LIST), time 78166552, state PropertyNewValue
2016-09-25 13:00:12 
2016-09-25 13:00:12 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78166552, state PropertyNewValue
2016-09-25 13:00:12 
2016-09-25 13:00:12 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     atom 0x13b (_NET_ACTIVE_WINDOW), time 78166552, state PropertyNewValue
2016-09-25 13:00:12 
2016-09-25 13:00:12 PropertyNotify event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     atom 0x179 (_NET_CLIENT_LIST_STACKING), time 78166552, state PropertyNewValue
2016-09-25 13:00:12 
2016-09-25 13:00:12 FocusOut event, serial 20, synthetic NO, window 0xf6,
2016-09-25 13:00:12     mode NotifyWhileGrabbed, detail NotifyInferior
2016-09-25 13:00:12 
2016-09-25 13:00:12 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e00001
2016-09-25 13:00:12 
2016-09-25 13:00:12 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e00130
2016-09-25 13:00:12 
2016-09-25 13:00:12 DestroyNotify event, serial 21, synthetic NO, window 0xf6,
2016-09-25 13:00:12     event 0xf6, window 0x2e000f4
2016-09-25 13:00:12 
2016-09-25 13:00:12 FocusOut event, serial 21, synthetic NO, window 0xf6,
2016-09-25 13:00:12     mode NotifyUngrab, detail NotifyInferior

This is simply focusing over to the window and using bspc node -c through a key mapping. Upon asking to be closed, the Wine window outputs

2016-09-25 12:58:20 
2016-09-25 12:58:20 FocusIn event, serial 20, synthetic NO, window 0xf6,
2016-09-25 12:58:20     mode NotifyGrab, detail NotifyInferior
2016-09-25 12:58:20 
2016-09-25 12:58:20 KeymapNotify event, serial 20, synthetic NO, window 0x0,
2016-09-25 12:58:20     keys:  4294967265 0   0   2   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:20            32  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
2016-09-25 12:58:20 

but waits a full two seconds before actually sending an unmap and destroy event. x11trace gives me this with winecfg on closing:

2016-09-25 13:03:09 002:>:008f: Event FocusOut(10) detail=Ancestor(0x00) event=0x03400001 mode=Grab(0x01)
2016-09-25 13:03:09 002:<:0090:  4: Request(43): GetInputFocus 
2016-09-25 13:03:09 002:>:0090:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x03400001
2016-09-25 13:03:09 002:>:0090: Event (generated) ClientMessage(33) format=0x20 window=0x03400001 type=0x138("WM_PROTOCOLS") data=0x36,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xfc,0x7f,0x00,0x00,0x76,0xe3,0x40,0x00,0x00,0x00,0x00,0x00;
2016-09-25 13:03:09 001:<:02f2:  8: Request(60): FreeGC gc=0x02e00057
2016-09-25 13:03:09 001:<:02f3:  8: MIT-SHM-Request(130,2): Detach shmseg=0x02e00056
2016-09-25 13:03:09 002:>:0090: Event FocusOut(10) detail=Pointer(0x05) event=0x03400001 mode=Ungrab(0x02)
2016-09-25 13:03:09 002:>:0090: Event FocusIn(9) detail=Ancestor(0x00) event=0x03400001 mode=Ungrab(0x02)
2016-09-25 13:03:09 002:>:0090: Event KeymapNotify(11) keys(0-7 omitted)=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x20,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
2016-09-25 13:03:09 002:>:0090: Event KeyRelease(3) keycode=0x85 time=0x04ab6dd3 root=0x000000f6 event=0x03400001 child=None(0x00000000) root-x=404 root-y=415 event-x=397 event-y=389 state=Mod4 same-screen=true(0x01)
fixme:event:wait_for_withdrawn_state window 0xc0190/3400001 wait timed out
2016-09-25 13:03:11 002:<:0091:  8: Request(10): UnmapWindow window=0x03400001
2016-09-25 13:03:11 002:<:0092: 44: Request(25): SendEvent propagate=false(0x00) destination=0x000000f6 event-mask=SubstructureNotify,SubstructureRedirect UnmapNotify(18) event=0x000000f6 window=0x03400001 from-configure=false(0x00)
2016-09-25 13:03:11 002:<:0093: 96: Request(18): ChangeProperty mode=Replace(0x00) window=0x03400001 property=0x28("WM_NORMAL_HINTS") type=0x29("WM_SIZE_HINTS") data=0x00000234,0x00000007,0x0000001a,0x00000000,0x00000000,0x0000019a,0x000001be,0x0000019a,0x000001be,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x00000000,0x0000000a;
2016-09-25 13:03:11 002:<:0094: 44: Request(18): ChangeProperty mode=Replace(0x00) window=0x03400001 property=0x1ae("_MOTIF_WM_HINTS") type=0x1ae("_MOTIF_WM_HINTS") data=0x00000003,0x00000024,0x0000001a,0x00000000,0x00000000;
2016-09-25 13:03:11 002:<:0095: 28: Request(12): ConfigureWindow window=0x03400001 values={x=7 y=26 width=410 height=446}
2016-09-25 13:03:11 002:>:0095: Event UnmapNotify(18) event=0x03400001 window=0x03400001 from-configure=false(0x00)
2016-09-25 13:03:11 002:>:0095: Event FocusOut(10) detail=Ancestor(0x00) event=0x03400001 mode=Normal(0x00)
2016-09-25 13:03:11 002:>:0095: Event PropertyNotify(28) window=0x03400001 atom=0x28("WM_NORMAL_HINTS") time=0x04ab754c state=NewValue(0x00)
2016-09-25 13:03:11 002:>:0095: Event PropertyNotify(28) window=0x03400001 atom=0x1ae("_MOTIF_WM_HINTS") time=0x04ab754c state=NewValue(0x00)
2016-09-25 13:03:11 002:>:0095: Event ConfigureNotify(22) event=0x03400001 window=0x03400001 above-sibling=0x02800009 x=7 y=26 width=410 height=446 border-width=4 override-redirect=false(0x00)
2016-09-25 13:03:11 002:<:0096: 44: Request(18): ChangeProperty mode=Replace(0x00) window=0x03400001 property=0x27("WM_NAME") type=0x1f("STRING") data='Wine configuration'
2016-09-25 13:03:11 002:<:0097: 44: Request(18): ChangeProperty mode=Replace(0x00) window=0x03400001 property=0x25("WM_ICON_NAME") type=0x1f("STRING") data='Wine configuration'
2016-09-25 13:03:11 002:<:0098: 44: Request(18): ChangeProperty mode=Replace(0x00) window=0x03400001 property=0x143("_NET_WM_NAME") type=0x134("UTF8_STRING") data=0x57,0x69,0x6e,0x65,0x20,0x63,0x6f,0x6e,0x66,0x69,0x67,0x75,0x72,0x61,0x74,0x69,0x6f,0x6e;
2016-09-25 13:03:11 002:<:0099:  8: Request(4): DestroyWindow window=0x03400002
2016-09-25 13:03:11 002:<:009a:  8: Request(4): DestroyWindow window=0x03400001
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x27("WM_NAME") time=0x04ab7550 state=NewValue(0x00)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x25("WM_ICON_NAME") time=0x04ab7550 state=NewValue(0x00)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x143("_NET_WM_NAME") time=0x04ab7550 state=NewValue(0x00)
2016-09-25 13:03:11 002:>:009a: Event DestroyNotify(17) event=0x03400002 window=0x03400002
2016-09-25 13:03:11 002:>:009a: Event DestroyNotify(17) event=0x03400001 window=0x03400001
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x140(unrecognized atom) time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x146("_NET_WM_STATE") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x141("_NET_WM_ICON") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x143("_NET_WM_NAME") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x25("WM_ICON_NAME") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x27("WM_NAME") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x23("WM_HINTS") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x153("_NET_WM_WINDOW_TYPE") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x1ae("_MOTIF_WM_HINTS") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x28("WM_NORMAL_HINTS") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x15e("_NET_WM_USER_TIME_WINDOW") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x16b("XdndAware") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x144("_NET_WM_PID") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x137("WM_LOCALE_NAME") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x24("WM_CLIENT_MACHINE") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x43("WM_CLASS") time=0x04ab7550 state=Deleted(0x01)
2016-09-25 13:03:11 002:>:009a: Event PropertyNotify(28) window=0x03400001 atom=0x138("WM_PROTOCOLS") time=0x04ab7550 state=Deleted(0x01)

The winecfg stdout(?) also outputs this:

fixme:event:wait_for_withdrawn_state window 0xd018c/3400001 wait timed out

Which may suggest it's trying to wait for something from bspwm but never recieves it? And as such waits 2-5 seconds to actually send an unmap and destroy event. Interestingly, looking for that string shows this https://www.winehq.org/pipermail/wine-bugs/2008-September/136228.html, which is interesting.

[baskerville]

Thanks for digging in.

Can you close the _winecfg_ window using _dwm_?

If you can, please provide the _x11trace_ output.

[shinyquagsire23]

@baskerville
In dwm when closing winecfg, the window is gone without lag when pressing the OK button to close, however it does take a bit for the x11trace process to close. I didn't know what key bindings would close and I wasn't sure if it could have differences in close methods like bspc node -k, hence I just went with the OK button since that would have lagged in bspwm as well. It seems to match up at https://gist.github.com/shinyquagsire23/3d9900cfd0be021e4af25fc4086135e7#file-gistfile1-txt-L2128 with the part that would normally lag with bspwm.

[baskerville]

Thanks, could you try the _icccm-state_ branch?

[shinyquagsire23]

@baskerville Didn't seem to make a difference. https://gist.github.com/shinyquagsire23/86ebf3b0c3ed71b820a59038c05c0439 is the new x11trace with that branch. Still does the _fixme:event:wait_for_withdrawn_state window 0x30096/2400001 wait timed out_ deal as well.

[baskerville]

I can't find wait_for_withdrawn_state in the log.

[shinyquagsire23]

@baskerville I think that's because I copied the log in the previous post from the console, but that log I piped the output to a file using >, so stderr didn't show up in it. https://gist.github.com/shinyquagsire23/f2df0904dfcdb44057ac88106a04f198 includes the position of the wait_for_widthdrawn_state print if you're curious on that.

[baskerville]

That's puzzling.

I will have to look at _wine_'s source.

[baskerville]

I've updated the _icccm-state_ branch.

But I still don't know what might be happening…

[shinyquagsire23]

@baskerville Yeah still nothing unfortunately. https://github.com/wine-mirror/wine/blob/master/dlls/winex11.drv/event.c#L1321-L1373 Seems to be the relevant code, even has that two second wait there. I don't know a whole lot about X11 but I might poke around and see if I find anything, particularly a way to get those TRACE prints, those could be handy.

EDIT: I can do WINEDEBUG=event winecfg to get the traces from that file, although all I get out of it with the new branch is

trace:event:wait_for_withdrawn_state waiting for window 0x10058 to become not withdrawn
fixme:event:wait_for_withdrawn_state window 0x10058/3200001 wait timed out

EDIT 2: did a bspc subscribe all and

node_unmanage 0x00400001 0x00400004 0x03400001
WMeDP1:o1:O2:o3:f4:f5:f6:f7:f8:f9:f10:f11:LT:TT:G
node_focus 0x00400001 0x00400004 0x02A00009
node_stack 0x02A00009 above 0x01200009

only occurred after the timeout with WINE. Since the withdrawn state is set after that log, it seems it's effectively useless. I believe it needs to be set sooner.

[baskerville]

It might be interesting to know what _wine_ does starting at handle_wm_protocols.

[baskerville]

@shinyquagsire23 (Regarding _EDIT 2_:) I don't think so, all the window managers do it in response to _{unmap,destroy}_notify_ events. Also, the trace says: _waiting for window 0x10058 to become_ not _withdrawn_.

[shinyquagsire23]

@baskerville There's one print from handle_wm_protocols in the full log, https://gist.github.com/shinyquagsire23/d7085bb7a2a724f11dcc57f5a3cb17da. The thing is though the only instance is before a Super+W to close.

EDIT: Also a WINEDEBUG=event winecfg log from dwm https://gist.github.com/shinyquagsire23/40a2c02765e2f77b937fa3ef63b37593, merged with x11trace https://gist.github.com/shinyquagsire23/db0809e233aab01d542a4ebec93c60d0

EDIT 2: In the mean time I'm going to compile wine so I can get some better printing from this, it would be good to know what data->wm_state is besides the NORMAL state or whatever.

[baskerville]

Thanks: the _dwm_ output was very useful: in the excerpt _state now 1_, _1_ means _NormalState_ which means that the state wasn't _NormalState_ within _bspwm_. In fact the state didn't exist, because I was setting the wrong property :sweat:

Time to retest the branch…

[eigengrau]

@shinyquagsire23 had better test this as well, but this seems to have done it for me. (However, the menu displacement issue still exists, so that one might be an unrelated issue.)

[shinyquagsire23]

@baskerville Yep, latest icccm-state branch fixed it, no more issues :)

Should be able to close this once it gets merged into master I suppose.