On Sun, Mar 5, 2017 at 9:09 PM, Duncan <1i5t5.dun...@cox.net> 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
