I forgot to mention something that provide another reason why I think the shell
itself cannot be the part that drops input: copy/paste still works.
That is, I can use whatever subterfuge I want to put a terminal command on the
clipboard; if I paste it into a "deaf" terminal window or tab and the command
has a newline append it will be executed by the shell running in that window or
tab. The same was true for the deaf KDevelop window: input from the clipboard
still appeared. Of course I had to use the Paste menu action in both cases.
I did consider the possibility that something in the shell or the
readline/libedit libraries it uses put a relevant component of the event
handling loop in an unforeseen state, which also would explain why keyboard
input doesn't even appear in the window (most of the time it does if the shell
has simply "disconnected").
For a long time I thought that must be in Konsole. Except that I never found
anything in its event handling code that seemed like it could explain my
As you know I also have a functional XCB QPA plugin on my Mac and have actually
been using Konsole 5 under X11 as my main terminal emulator for months now.
Works really nicely. Of course that XCB QPA plugin is used with a Qt install
otherwise built for Cocoa, and basically all KF5 software is built that way too
so binaries lack all X11 specific code not provided by the QPA (or the
Development mailing list