You probably will need to look at Qt code.

It looks like the second thread is an X11 event loop, which isn't weird at all. It also doesn't mean that it's actually waiting for a specific event (I guess?), it's just part of the normal X11 event handling. Now, obviously, this thread should terminate once you try to quit an application, but why that is not happening beats me without looking at Qt code.

Thank you for this first (and extremely fast) feedback :)

Looking around, it seems that quite some people have had issues with newer Qt versions and more exotic X servers (mostly on Windows, like XMing), which lead to the application window not showing up at all. They also got a BadRequest with codes {130,47}, but that might be a red herring.

The major code should be related to the MIT-SHM/XShm extension, minor code 47 is... I don't know. X_ShmPutImage should be 3, which is usually failing, I'm having a hard time finding out what 47 is supposed to be. It's probably something that we don't provide in NX, so it makes sense that Qt gets a BadRequest.

But if you don't see this message right when quitting applications, but rather right at the start, it probably means that it has nothing todo with the quitting issue.

Weird stuff indeed. There is no minor opcode 47 in https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/include/X11/extensions/shmproto.h?ref_type=heads , which makes the BadRequest response very understandable... now... what did Qt try to call exactly?

The XInput2 extension does have a minor opcode of 47, which would be XIQueryVersion: https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/include/X11/extensions/XI2proto.h?ref_type=heads#L82

I think we're not providing XInput2 at all in NX.

The combination used here doesn't make sense, though...

that might be a red herring.

Yes, most likely.

But if you don't see this message right when quitting applications, but rather right at the start, it probably means that it has nothing todo with the quitting issue.

I mentioned these warnings for the sake of completeness but, indeed, I should have mentioned they appear right at the start. I am going to adjust my report accordingly.

I think we're not providing XInput2 at all in NX.

Confirmed, I remember having checked that point.

I captured the X11 traffic between qtdeadsimple and nxagent. When Qt wishes to close the connection, it emits a SendEvent request along with a ClientMessage, the type of which is "not a predefined atom" (according to Wireshark) but most likely the actual value of QXcbAtom::_QT_CLOSE_CONNECTION: https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/xcb/qxcbeventqueue.cpp#n348
It then waits for the associated Sent-ClientMessage event before cleaning up the place (CloseFont, FreeCursor, FreeColormap, FreeGC) and closing the underlying connection.
This works fine in regular mode. However, in rootless mode, something prevents nxagent from emitting this Sent-ClientMessage.
Next step: investigate why nxagent behaves differently in rootless mode.

The most visible difference between "normal" (desktop) mode and rootless mode is that in the first case, a window manager is running within the session, while in the latter case the windows are decorated through an external window manager. Maybe atoms are not exchanged correctly.

In that case you should get the same problem when running on a normal X server without window manager. Can you confirm?

I killed my window manager and ran qtdeadsimple against my X.org server: it exited as soon as I pressed the button, i.e. it behaved normally.

Having written that something comes to my mind: [...]

Thanks for the hint, I will dive into all of this until I reach a diagnosis.

According to Atom map in context [nxagentResetAtomMap: Exiting] (and other calls to nxagentPrintAtomMapInfo()), _QT_CLOSE_CONNECTION never enters the atom map despite existing (with different values) in both local and remote servers. However, I believe this is a consequence, not a cause.

So I got back to my previous reasoning, which is: in rootless mode, the Qt-issued SendEvent X11 request with a custom-type ClientMessage is seemingly ignored.
Based on the function name, I assumed SendEvent requests are processed by the ProcSendEvent function:

In Events.c, ForwardClientMessage acts only if:

I tested the following quick-and-dirty workaround:

--- nx-X11/programs/Xserver/hw/nxagent/NXevents.c
+++ nx-X11/programs/Xserver/hw/nxagent/NXevents.c
@@ -144,6 +144,7 @@ of the copyright holder.
 #include "Windows.h"
 #include "Args.h"
 #include "Clipboard.h"
+#include "Atoms.h"

 extern Display *nxagentDisplay;

@@ -427,8 +428,11 @@ ProcSendEvent(ClientPtr client)

     if (nxagentOption(Rootless) && stuff->event.u.u.type == ClientMessage)
     {
-        ForwardClientMessage(client, stuff);
-        return Success;
+        Atom qt_close_connection = MakeAtom("_QT_CLOSE_CONNECTION", strlen("_QT_CLOSE_CONNECTION"), False);
+        if (stuff->event.u.clientMessage.u.l.type != qt_close_connection) {
+            ForwardClientMessage(client, stuff);
+            return Success;
+        }
     }

     if (stuff -> event.u.u.type == SelectionNotify)

... and Qt applications now exit as expected in rootless mode. Wireshark confirms the expected Sent-ClientMessage Event was issued by nxagent and received by the Qt Application.

At this stage, I believe we have a complete diagnosis.
Next step: discuss how to best tackle the issue.

Here is a different fix: instead of systematically returning, ProcSendEvent() returns only if ForwardClientMessage() acknowledges it did something (or tried to do something) with the message.

--- nx-X11/programs/Xserver/hw/nxagent/Events.h
+++ nx-X11/programs/Xserver/hw/nxagent/Events.h
@@ -222,6 +222,6 @@ int nxagentPendingEvents(Display *dpy);
 
 int nxagentWaitEvents(Display *, useconds_t msec);
 
-void ForwardClientMessage(ClientPtr client, xSendEventReq *stuff);
+int ForwardClientMessage(ClientPtr client, xSendEventReq *stuff);
 
 #endif /* __Events_H__ */
--- nx-X11/programs/Xserver/hw/nxagent/Events.c
+++ nx-X11/programs/Xserver/hw/nxagent/Events.c
@@ -4499,7 +4499,7 @@ int nxagentWaitEvents(Display *dpy, usec
   return 1;
 }
 
-void ForwardClientMessage(ClientPtr client, xSendEventReq *stuff)
+int ForwardClientMessage(ClientPtr client, xSendEventReq *stuff)
 {
     Atom netwmstate = MakeAtom("_NET_WM_STATE", strlen("_NET_WM_STATE"), False);
     Atom wmchangestate = MakeAtom("WM_CHANGE_STATE", strlen("WM_CHANGE_STATE"), False);
@@ -4542,7 +4542,7 @@ void ForwardClientMessage(ClientPtr clie
                 #endif
             }
             else
-                return; // ERROR!
+                return -1; // ERROR!
 
             #ifdef DEBUG
             fprintf(stderr, "%s: window [0x%lx]\n", __func__, X.xclient.window);
@@ -4562,8 +4562,10 @@ void ForwardClientMessage(ClientPtr clie
             fprintf(stderr, "%s: send to window [0x%lx]\n", __func__, dest);
             fprintf(stderr, "%s: return Status [%d]\n", __func__, stat);
             #endif
+            return 1; // Processed/Forwarded/Sent
         }
     }
+    return 0; // Ignored
 }
 
 #ifdef NX_DEBUG_INPUT
--- nx-X11/programs/Xserver/hw/nxagent/NXevents.c
+++ nx-X11/programs/Xserver/hw/nxagent/NXevents.c
@@ -427,8 +427,8 @@ ProcSendEvent(ClientPtr client)
 
     if (nxagentOption(Rootless) && stuff->event.u.u.type == ClientMessage)
     {
-        ForwardClientMessage(client, stuff);
-        return Success;
+        if (ForwardClientMessage(client, stuff) != 0)
+            return Success;
     }
 
     if (stuff -> event.u.u.type == SelectionNotify)

The problem I just mentioned in #1015 might be related to this. We both issues should be fixable in one go.