Bug 1212035

rxvt-unicode is not ported to the Wayland protocol and therefore relies on Xwayland.

In theory, rxvt running under XWayland should make no difference with rxvt running under the Xserver so I thought this might be an Xwayland bug (this is why I am looking into this actually).

On further investigation, though, it doesn't seem to be the case, it's rather a timing issue in the X event handling code of rxvt-unicode.

rxvt-unicode has some code to work around jumpy pointers and it uses timestamps to detect that:

in rxvt-unicode/src/command.C:

1368 /*{{{ process an X event */
1369 void ecb_hot
1370 rxvt_term::x_cb (XEvent &ev)
1371 {
[...]

1630                 XQueryPointer (dpy, vt,
1631                                &unused_root, &unused_child,
1632                                &unused_root_x, &unused_root_y,
1633                                &ev.xbutton.x, &ev.xbutton.y,
1634                                &ev.xbutton.state);
1635 #ifdef MOUSE_THRESHOLD
1636                 /* deal with a `jumpy' mouse */
1637                 if ((ev.xmotion.time - MEvent.time) > MOUSE_THRESHOLD)
1638                   {
1639 #endif
[...]

1648                     selection_extend (ev.xbutton.x, ev.xbutton.y,
1649                                       ev.xbutton.state & Button3Mask ? 2 : 0);
1650 

The problem occurs on Wayland because we hit this case. i.e.  ((ev.xmotion.time - MEvent.time) > MOUSE_THRESHOLD) and so we call selection_extend() which will actually shrink the selection up to the separator.

Further debugging shows that, although we miss the MOUSE_THRESHOLD which default to 50ms, it's not by far.

Increasing MOUSE_THRESHOLD in  to 100 solves the issue in my reproducer.

In src/feature.h line 163:

159 /*
160  * Time factor to slow down a `jumpy' mouse.  Motion isn't recognised until
161  * this long after the last mouse click [default: 50 milliseconds]
162  */
163 #define MOUSE_THRESHOLD         100


So for now, I am not leaving this bug in rxvt-unicode as I don't think Xwayland is the problem here.

Sorry, last sentence should read "So for now, I _am_ leaving this bug in rxvt-unicode as I don't think Xwayland is the problem here."

Thanks a lot for looking at this so quickly. I can confirm that bumping to 100 fixes the issue for me!

I wonder if removing support for "jumpy pointers" wouldn't be the best thing. I'd think that pointer jumps happened in old mice with a roller.

Created attachment 1015867 [details]
remove support for jumpy pointers

I'll be running this to see if any problems crop up, but it seems to work so far.

I have been running urxvt for a week with patch from comment #c5 without any adverse effects.

First, the proposed patch removes selection extension support altogether (not just the jumpy mouse protection), which has the obvious effect of avoiding the problem, as would be ignoring clicks or movement altogether, so this is not a solution.

Second, things don't add up here - if *increasing* the jumpy mouse protection interval helps, then your mouse is even more jumpy than normal: the point of the threshold is to ignore mouse movement caused by clicking for a short time after the click, and if you need to inctrease it, it means you get mouse movement events a long time after the click.

Therefore, removing the mouse threshold would make the problem even more severe.

The question is why xwayland has this jumpy mouse behaviour when standard x servers don't - apparently, xwayland either generates spurious mouse movement events, or delays them to more than 50ms.

Since 50ms works fine even on servers and hardware from decades ago, it's not clear to me why event processing in xwayland must be of such low quality, when standard x servers have no problem delivering the correct events, and in time.

It wouldn't be a good idea to increase the threshold further to 100ms, because thats a pretty noticable time for the user, thus increasing the risk of ignoring valid user input.

I think this is a quality of implementation issue - the event processing issues of xwayxland should not be detrimental to users on x-servers with better event processing (virtually every other x server). Decades of experience have shown that better/more timely event processing is certainly possible on very slow (by todays standards) and low quality hardware, so there is absolutely no excuse to deliver events correctly and/or faster than within 50ms.

Summary: increasing the time where urxvt is blind for pointer movement by the user just for one x server which can't deliver events fast enough is not a good idea. Instead, the x server should be fixed. If xwayland can't be fixed, it's design should be rethought, as even the x-server on my 4MB 486 box was fast enough.

(In reply to redhat-bugzilla from comment #7)

Xwayland is an X server but also a Wayland client (see [1]) and relies on the Wayland compositor to handle and dispatch the input events first.

In this case, I doubt the problem comes from Xwayland, the delay seem to come from the Wayland compositor (mutter) in the first place - Using weston as a Wayland compositor does not seem to exhibit the same delay.

I'm looking into mutter to see where that could come from.

[1] http://wayland.freedesktop.org/xserver.html

So it seems the problem comes from mutter which generates a motion event for every button event.

This is what is causing trouble to the rxvt "jumpy mouse detection" code which receives a spurious xmotion event with the timestamp of the button release event - Since this is a user interaction, it's not guaranteed to be within any time limit and therefore chances are high that it occurs after 50ms.

See the call to notify_motion() in handle_button_event():

https://git.gnome.org/browse/mutter/tree/src/wayland/meta-wayland-pointer.c#n336

Removing that motion_notify solves the issue.

=> Moving to mutter;

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I don't know when exactly, but this got fixed a while ago. Works fine in F24.