Skip to content

RemoteDesktop: mutter sends old pointer data after input

Issue #1323 (closed) described an issue, where mutter sent old frames when an input event from the client side happened.
This issue is now fixed. However, it seems that the mouse pointer has the same issue.
While !1361 (merged) fixed this for the frames, it seems that the mouse pointer needs another fix.

To the issue itself:

  1. Start a g-r-d session (use either the VNC session on X11 (client side in X11 session, server side shouldn't matter (I used the Wayland session on the server side) or the RDP session (with https://gitlab.gnome.org/jadahl/gnome-remote-desktop/-/merge_requests/15 applied) on X11 (== client side in X11 session), you can enable view-only mode (no input from remote side allowed) as remote input doesn't matter this time).
  2. Open g-t (gnome-terminal)
  3. On the server side move the mouse pointer in a circle
  4. Now leave the mouse alone and and run something in g-t that can trigger frame updates, e.g. journalctl -b
  5. Now move the entries in journalctl with the Up- or Down-key (it doesn't matter which of these keys as long as the entries move to make sure a frame update on the client side happens.

Observation: The mouse cursor on the client side moves, although no input events happened during pressing Up- or Down-key in g-t.

Expectation: Just frame updates should happen here, nothing more.

Screencast with VNC of this issue: Bildschirmvideo_von_12.07.2020_10_38_12

If I apply pnowack/gnome-remote-desktop@dc51f82e on top of the aforementioned RDP branch (which brings custom mouse pointer support to g-r-d), I can now print the X and Y position that is being sent to client when g-r-d sends a pointer position update.

When the g-r-d started, I already saw something suspicious regarding the pointer position update in the log:
Bildschirmfoto_von_2020-07-12_10-15-09

... at least one of those pointer position update shouldn't happen. But after Step 4, I can see something like this in the logs:

Bildschirmfoto_von_2020-07-12_10-16-08

In this situation, none of those pointer position updates in the screenshot above should happen. The interesting part here is the repetition of those events:

X-Pos: 1413 -> 1378 -> 1393 -> 1413 -> 1413 -> 1378 -> ... (and then the sequence repeats)
Y-Pos: 626 -> 627 -> 583 -> 610 -> 626 -> 627 -> (also repeats after 610)

I actually didn't noticed this issue first, it only got my attention, when xfreerdp teleported my mouse pointer back in to the client window after I moved the the pointer out of the window (pointer position update arrived when I just hovered the titlebar of xfreerdp.
Another reason why I found this issue is that g-r-d (at least for the RDP backend) doesn't send pointer position updates when the mouse movement comes from the client side (as the pointer position is already the same).

This issue can also happen with the mouse pointer bitmap, but it is really hard to reproduce it with the mouse pointer bitmap. I ran however into a situation where mutter also sent an old mouse pointer bitmap alongside to the wrong position.
This only came apparent when the mouse pointer was moved by the update from mutter in g-t in the text field where the mouse pointer bitmap actually shouldn't change (obviously in the normal case, when no link is hovered).

This is on mutter/master, g-s/master. mutters latest commit is in my build d67ba3ea (so the fix for the frame part is already applied).