Web lists-archives.com

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




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