Web lists-archives.com

Re: KDE hang? (not computer, not X11?)






On Sun, Mar 5, 2017 at 9:09 PM, Duncan <1i5t5.duncan@xxxxxxx> wrote:
Mark Knecht posted on Sun, 05 Mar 2017 10:33:09 -0700 as excerpted:

> As I was able to shell to the console is there something I could have
> run to tell me who owns the mouse at any given time? After the VM shut
> down I still couldn't switch virtual desktops and there didn't appear to
> be any apps open, at least by looking at the 6 Pager icons. However if
> the application that grabbed the keyboard and/or mouse was minimized I
> wouldn't have seen it anyway. (Or so I think.)

FWIW, I've had this happen to me under a few scenarios, one of which is
explainable as follows:

I use a separate touchpad device with the xf86-input-mtrack driver,
configured to recognize gestures such as four-finger-swipe-left, two-
finger-rotate-right, etc, and translate them to X upper-mouse-button
events (buttons 1-3 are well recognized as left/middle/right, along with
4-5 as vertical-scroll, and somewhat less consistently, 6-7 as horizontal-
scroll, with the driver then converting various gestures to events for
buttons 8-20).  But these upper mouse buttons aren't standardized so apps
normally just ignore them, so I use another app (sxhkd, simple X hotkey
daemon) to translate these upper mouse button events into actually
practical actions, most of which are either faked hotkey events (two-
finger-pinch-in/out is configured to emit the hotkeys that trigger the
kwin zoom effect, for instance) or running specific commands, much as one
might otherwise do with hotkeys, but here, I trigger them with touchpad
gestures.

Now normally, a button "click" consists of two events, button-down and
button-up, but as my touchpad doesn't have any physical buttons and
translates 1-4-finger-taps into "clicks", it lacks a directly intuitive
way to drag, except with the primary (left) mouse button (single-finger
tap-and-drag, but the tap-and-drag also emits a double-click before the
drag kicks in, which can sometimes foil the drag, depending on context).
Multi-finger gestures are interpreted as other gestures, so can't be
used, directly, for tap-and-drag.

So I configured one gesture, four-finger-swipe-down, to wait for and
detect the number of fingers used for the next tap, and to lock the
corresponding button down (emit just button-down, not the corresponding
button-up) when it sees it.

So for instance, 4-swipe-down, 1-tap, emits left-button-down, letting me
then drag.  4-swipe-down, 3-tap, is right-button-down, and 4-swipe-down,
4-tap, is middle-button-down.  (4-swipe-down, 2-tap, cancels the action,
so I don't get stuck waiting for a drag when I've decided half way thru I
don't want to do one.)

I can then drag, repeatedly dragging and lifting my finger up to place it
back on the other side of the pad to continue the drag, as long/far as
desired.

When I'm done, I simply tap with the corresponding number of fingers
again, to tell the drag to release, by emitting the button-up event that
corresponds with the earlier button down.

So to do a complete right-button-drag, I 4-swipe-down, 3-tap, to get the
right-button-down event and initiate the drag, then move the mouse with a
single finger, lifting it up and repositioning to drag further as often
as necessary, then when I've dragged to where I want, I simply 3-tap
again to emit the right-button-up event that would correspond to
releasing the drag.

OK, but what happens if I'm doing something that accidentally gets
registered as 4-swipe-down, and I don't realize it?  This is where the
scenario gets back on topic again, as the thing then waits for what I
would think would be a normal click since I didn't know I did the 4-swipe-
down to initiate a drag, and starts a drag.

To whatever I just clicked on, it's a drag, causing most applications to
grab the mouse, only I'm not aware of it.

Then I start trying to do stuff, and the mouse doesn't work like it
should.

If it's just a 1-tap (single-finger-tap), no big deal.  I'll quickly tap
again and I might get an unexpected drag, but things will work again.

But if I somehow managed a 4-tap, it'll consider that a middle-button-
drag, and that's rare enough I'm unlikely to do another 4-tap any time
soon to release it, so the drag continues, and stuff continues to act
weird because whatever I started the drag on has grabbed the mouse and
won't let it go until I complete the drag... that I don't know I'm
doing!  Of course that interferes with normal window activation as well,
typing goes to the wrong window, etc.  Basically, you know something's
badly wrong, but neither the mouse nor the keyboard seem to work
correctly, so you think it's X itself not responding correctly, if at all.


The first few times that happened, days apart so it wasn't often enough
to make the connection at first, I ended up switching to a different VT
and issuing a killall X, or whatever, to kill the entire X session,
because I couldn't get it to work right and that's the only way I knew to
get it to work right again.

Eventually, I figured out what was happening, and now, whenever the mouse
and keyboard starts doing something weird like that, I know to quickly do
a 1-3-4-tap (one of each), to cancel whatever drag I might have
accidentally initiated.  If that works, great.  If not, well, it's some
other problem, not an accidental drag-lock.


All that to basically say, yes, if you either accidentally initiate a
drag-lock, or if you start a drag and the app you started in crashes in
the middle of a drag... X will start behaving *really* weirdly!  Speaking
from the wisdom of personal experience!


Unfortunately, I know of no report to run in another VT to figure out
what has the input-grab.  Before I figured out what was happening I'd
sometimes try killing various X apps at random, and often I'd eventually
get it working again.  But I didn't really know why at the time, tho now
I know it was because eventually I'd happen to kill the app with the drag
and it'd release it.

But if it happens, and if you don't have an obvious source of the problem
like I did with the drag-lock trigger (once I figured it out it was
obvious, not so much before!), you can try the random kill thing and see
if you can get it to work.

In some cases it might be a buggy app, triggering a grab when you didn't
want it.  If so, it might be consistently the same app, so once you
figure out which one, at least then you know which app to kill.  Of
course, with my problem, it didn't happen to work that way, since I was
emitting the triggers artificially, and the app that would then initiate
the drag-lock would thus /appear/ to be random.

Meanwhile, one (typically Duncan-long...) word of caution.

I already mentioned that crashing apps can leave the grab "grabbed",
without much you can do about it.  But killing (using the default SIGTERM
15) doesn't do that.  It allows the app to exit gracefully (if it will),
and normal X apps will release any grabs they have as the exit.

But SIGKILL, 9, is a kernel-forced kill, without letting the app know
first or giving it a chance to do anything.   Similarly some (but not
all) types of crashes.  In these instances the input grab will not be
released as the app didn't get a chance to release it before it crashed
or was force-killed.  That *does* tend to screw X up, to the point where
in my experience at least, there's nothing that can be done but terminate
and restart X, because then there's no way I know to actually trigger
that grab release, /except/ for terminating X itself.  Because the app
that did the grab is now dead and /can't/ trigger the release.

So if you suspect a grab of this nature, be sure and do what should
always be best practice anyway, and try SIGTERM (15), then SIGHUP (1),
SIGINT (2, aka ctrl-C), then SIGQUIT (3), then try faking a less severe
crash with SIGILL (4), SIGABRT (6), SIGBUS (7), SIGFPE (8), SIGSEGV (11),
etc (not all, just pick one or two), and only if all those don't work, as
a last resort, try the kernel-forced-kill SIGKILL (9).  Sometimes an app
will choose to ignore term/hup/int for various reasons, but if it's
ignoring SIGBUS, SIGFPE and SIGSEGV, that probably means it's already
deadlocked or otherwise entirely scrambled and /can't/ respond, which
pretty much leaves having the kernel force-kill and cleanup as best it
can with a SIGKILL, as the only option.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Thanks Duncan. Very helpful.

In this specific case I was, as best I know right now, down to nothing but the 
Windows VM still running in Virtualbox and doing a kill didn't feel right being that
should the VM go down hard I'm left restoring from weekly backups. However It
might not have been out of line to have at least tried a kill -15 to see if I made any
progress.

Again, I appreciate the the response.

Cheers,
Mark