borderWidth = 0 breaks workspaces with full-screen applications.

[jhodgdev]

Problem Description

Setting borderWidth = 0 in one's XConfig causes workspaces with full-screen applications in them to freeze (or load incredibly slowly).

When I launch a Steam game (I tested with Dark Souls III and Baldur's Gate 3) with the configuration provided below, the application launches but fails to load.

Some observations I made:

• The cursor will change to the cursor provided by the game client.
• I can move the cursor freely.
• If I issue a 'switch workspace' command i.e. Alt+[2..0], after some delay, I will switch to the workspace successfully. When in this workspace, everything will function as normal. If I switch back to the 'game workspace', it'll return quickly but the same issue will persist.
• Upon returning to the 'game workspace', the game might have loaded whilst I was in the other workspace e.g. I might have progressed past any splash screens onto the main menu. Upon returning to the 'game workspace', it will freeze once more.
• This behaviour does not occur with 'windowed' applications.
• I have a multi-head setup (1200x1920 portrait monitor -- 2560x1440 landscape monitor -- 1200x1920 portrait monitor). This only occurs, when the two portrait monitors each side of my primary monitor are disabled.
• The exact same phenomenon occurs regardless of whether I launch XMonad as below or with xmonad . ewmhFullScreen . ewmh i.e. the issue does not lie in the contrib repo.

Steps to Reproduce

1. Compile XMonad with the config provided.
2. Disable any other monitors, so you're only using a single display.
3. Launch a full-screen game.

Configuration File

Please include the smallest full configuration file that reproduces
the problem you are experiencing:

module Main (main) where

import XMonad

main :: IO ()
main = xmonad $ def{borderWidth = 0}

Checklist

• I've read CONTRIBUTING.md
• I tested my configuration
  • With xmonad version 0.17.2
  • With xmonad-contrib version 0.17.1

[geekosaur]

I don't have this problem with VMware, and suspect it's a bug with Steam and non-reparenting window managers; they may incorrectly assume that a nonzero border width means there's no window frame. (Steam and a number of other cross-platform UI toolkits need to translate coordinates for their canvases between X11/Wayland-style and Windows-style, which means they need to account for window frames.)

[jhodgdev]

@geekosaur that's interesting. Would you be able to explain to me what 'reparenting' means in this context? Furthermore, could you suggest any other Xorg window managers I could test to see if the issue is truly with Steam?

Last night (after posting the initial report) I found out that applying noBorders myLayoutHook causes the same, unwanted behaviour but smartBorders . noBorders $ myLayoutHook works fine.

[geekosaur]

Reparenting is taking a new window and making it a child of a frame window. Most other window management systems, notably including Windows, make the frame and titllebar part of the client GUI toolkit; X11 gives it to the window manager.

Why this is relevant is that X11 also does window-relative addressing, while most others (again notably including Windows) use screen-relative. So when writing a cross-platform toolkit you need to translate between the two, which on X11 means you also need to account for the frame window, especially in the case of canvas widgets. Java, Mono, and Steam have all had problems with not identifying frame windows or their absence properly, leading to clients looping due to IMO poor coding practices.