clicks not registering

[wearpants]

I need to hit the mouse click key many times before it's detected - feels like some sort of race condition? XFCE on Ubuntu 19.10

[wearpants]

So this works fine under twm, which makes me think warp & XFCE are competing for the keypress... Probably time for me to switch window managers anyway

[rvaiya]

Yes this is a known bug. X uses a client-server model which is abstracted from the client perspective by Xlib. Xlib calls transparently send requests to the core X server which then relays those requests to other clients (i.e windows/window managers). It appears that the simulated mouse events getting sent to the server are being processed after the mouse indicator is being remapped preventing the target window from processing the click. It is unclear why this is happening given that the requests appear to be sent in the correct order (verified using xtrace) which indicates that there is either a bug in the X server (which causes it to process map events before simulated click events) or else certain window managers are doing strange things with pointer grabs. Properly discovering the root cause is quite involved (and possibly beyond my ken). My suspicion is that it has some to do with the way the window manager handles events (I was able to reproduce the issue on fluxbox but not on dwm). It is unlikely anything can be done about it short of adding an artificial delay or else simply not remapping the mouse decorations after each click. Presently I have chosen the former option to preserve existing functionality, but it is a bit of a kludge and may not work across all window managers.

TLDR: It was a race condition. Try the latest commit :P.

[rvaiya]

I've done some basic testing on fluxbox and most of the kinks seem to have been ironed out (double click now works). Let me know if you discover any other issues. I suspect compositing window managers (typically found on heavier DEs) may introduce some complications but I haven't tried any. Feel free to report back with any problems or close the issue once you feel things are working.

Thanks

[rvaiya]

I got around to installing XFCE (all 2+GB of it!) and did a bit more testing. It turns out there is another issue which prevents certain programs from working properly. X uses a model in which only one client can have control of the keyboard at a given time. Unfortunately since warp needs access to the keyboard in order to process input events this effectively means that pointer actions which result in programs attempting to grab the keyboard will fail (and conversely any attempts by warp to grab the pointer if another program has already done so will also fail). This is most notable on the XFCE top bar but also appears to be true of many graphical program menus which silently fail when they can't grab the keyboard to implement menu shortcuts (interestingly Chrome does not suffer from this issue). Since I principally use chrome, urxvt and a fairly spartan window manager I have managed to remain blissfully ignorant of these issues :P. This is obviously a major problem for anyone who uses GUI oriented setup (and who would consequently most likely benefit from a program like this). It probably also explains the conspicuous lack of such programs already in existence.

Potential Solutions

As far as I can tell there doesn't exist a way to properly implement something like this in X. There was an attempt to introduce an extension for accessibility related key interception some time ago (XEviE) but it appears to have been abandoned. The following are potential workarounds.

Yield the keyboard grab upon click (stop drop and roll).

Pros

• Trivial to implement
• Allows for popup boxes to be opened (but not subsequently navigated with warp)
• Potentially solves many use cases.
• Possible to achieve with pure X.

Cons

• Inconsistent behaviour (clicks which trigger pointer grabs will close the movement session, others will not)
• Cannot be used while dialog boxes (or anything else which grabs the keyboard) are open.
• Encourages a hybrid approach (warp to select the menu item/menu item shortcuts for selection).
• May affect other things like DE widgets which grab the keyboard.

Use uinput

Pros

• Doesn't have any of the above limitations since it operates below the X layer.
• Basic functionality works everywhere (i.e like keyboard firmware).
• Key interception logic can be partially recycled from a keymapper I wrote.

Cons

• Requires root
• Involves a complete rewrite + server/client model to realize graphical features.
• Less elegant :P

Resources

https://freedesktop.org/wiki/Software/XEvIE/
https://cgit.freedesktop.org/xorg/xserver/commit/?id=f4036f6ace5f770f0fe6a6e3dc3749051a81325a

Conclusion

Presently I favour the first option but if your main use case involves interacting with a lot of graphical program menus then I am willing to undertake the second (I may eventually end up implementing it as an exercise anyway). Let me know how you want to proceed.

[rvaiya]

Followup:

I went ahead and implemented the first solution along with a few other improvements (see the latest commit and updated readme). This is as far as I can take the current implementation. If you are interested in a uinput version which works with popup menus feel free to create another issue or email me directly :P. I'm closing this for now since there is nothing else which can be done.

[wearpants]

Played around with this under XFCE, and behaviour seems reasonable enough, gonna switch to a minimal WM soon enough anyway

[rvaiya]

Update: After some experimentation it appears it is indeed possible to improve upon the existing implementation by abusing xinput slave devices to undermine standard X grabs. This is not perfect since it is theoretically possible for another client to grab exclusive control of the same devices but most application toolkits seem to use the higher level APIs. This represents a nice middle ground between an input layer solution and the current one and should hopefully slake the thirst for a complete rewrite.

[rvaiya]

Implemented in f762bad