Temporary hang on screen lock/unlock

I am running Ubuntu 21.10 and Gnome 40.4.0. I have observed the issue I am reporting in the KeePassXC app (and am also reporting the bug there, at https://github.com/keepassxreboot/keepassxc/issues/8146, though I am pretty sure it's a Qt issue), and seen what may be the same underlying problem in the `nvim-qt` GUI for the Neovim text editor.

When I lock the screen (i.e., the thing that happens on doing Win-L on a stock Ubuntu 21.10 install), my `keepassxc` and `nvim-qt` processes (these are all the Qt apps I am running) suddenly begin using (each) 100% of one CPU core. This state of affairs persists for about 20 seconds; it looks to me as if the `nvim-qt` processes stop doing this a little sooner than the `keepassxc` one does.

If I then press a key to bring up the unlock screen (with password input field), these processes again begin using 100% of a core apiece. Again, this persists for about 20 seconds.

If immediately after this I attempt to interact with the KeePassXC application, the same thing happens again. I think this doesn't happen with nvim-qt but have not done careful experiments.

(I have not filed Qt bugs before and it is very likely that I have not identified the correct component; my apologies if I haven't.)

While the applications are in this CPU-eating state, they do not respond to UI interactions, which is why this is anything more than a trivial annoyance.

Attaching to the `keepassxc` executable with `gdb`, I find that during the CPU-eating phase its main thread is sat inside (a single, long-lasting invocation of) `QWindowSystemInterface::sendWindowSystemEvents`, which is calling (many many times, each for a short duration) `QGuiApplicationPrivate::processScreenGeometryChange`. Eventually this stops happening, and that is when the application stops eating CPU and becomes responsive.

`strace` shows that while this is happening, about 50 times per second the application is calling `write` on a single file descriptor, writing 8 bytes [1,0,0,0,0,0,0,0]. Immediately before this there is a call to `futex`, the operation being `FUTEX_WAKE_PRIVATE`, which does not successfully wake up any waiters. (In normal operation the same call occurs from time to time and does wake up one waiter.)

(I have no idea whether either the futex calls or the writes are actually relevant, but it seems as if they might be. Obviously neither of these is itself consuming all that CPU; I imagine something somewhere is busy-waiting.)