Mouse host mouse is drawn in wrong place when display is flipped with -rotate

[stanford-scs]

If you'd like to put out an incentive for fixing this bug, you can do so at https://issuehunt.io/r/LibVNC/x11vnc

Describe the bug

I'm hoping to use x11vnc with a teleprompter (displaying my screen, flipped, on a tablet). When I use the -rotate y option, the screen is correctly flipped so that it looks good on a mirror angled above the tablet. Unfortunately, I can't get the host X server's cursor to display in the right location. The shape of the cursor is rotated, but it shows at the same place as on the non-flipped screen. In other words, when the host X server is at the top of the screen, it is also at the top of the flipped screen.

Note that on the VNC client machine, the mouse also moved backwards by default, but the -nocursorshape option seems to fix that problem. However, I don't plan to provide any input from the client machine, and plan to use only the main keyboard and mouse connected to the X server. If I'm dragging a window, it works correctly, but if I'm just trying to move the mouse, it shows up at the wrong height of the screen and so I can't see where I'm clicking.

To Reproduce

Run: x11vnc -rotate y -nocursorshape
Now using the host machine (the one running x11vnc, not the one running vncviewer) move the mouse around and try to click on something while looking at the inverted window on your VNC client.

Expected Behavior

When you click, the click event goes to the window under the displayed mouse, not to the window at vertical position 1080-y (if y is the current mouse position). Moreover, when you move the host mouse up or down, you expect to see the upside-down cursor move in the opposite direction, so as to stay over the same region of the screen as in the non-flipped version.

Screenshots

A screen shot shows that the cursor appears to be in a different part of the screen when in fact it's near the word cursor in the xterm.

Desktop (please complete the following information):

• arch Linux recent, with x11vnc 0.9.16
• Xorg version used: 1.20.10
• Wayland version used: none

Additional context

Ideally it's easy to reproduce and a simple fix, but happy to provide any additional information that could be helpful.

---

IssueHunt Summary

Backers (Total: $50.00)

• stanford-scs ($50.00)

Submitted pull Requests

• #163 display cursor in correct position when using -rotate and moving cursor on host

---

Become a backer now!

Or submit a pull request to get the deposits!

Tips

• Checkout the Issuehunt explorer to discover more funded issues.
• Need some help from other developers? Add your repositories on IssueHunt to raise funds.

[issuehunt-oss]

@stanford-scs has funded $50.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[darksworm]

@stanford-scs I've implemented the fix in #163.
Sadly, there's no progress for the PR and I can't foresee when or whether someone is going to approve it.
If you'd like to use the fix earlier, i suggest you pull my fork and use that instead. https://github.com/darksworm/x11vnc

[bk138]

I've got an alternative, shorter solution in #165, please test @stanford-scs @darksworm. If that one works out over #163, I'm of course willing to split the bounty @darksworm ;-).

[darksworm]

@bk138 I'll find some time to check it out this week. I hope it works - your solution is way more elegant!

[darksworm]

I've got an alternative, shorter solution in #165, please test @stanford-scs @darksworm. If that one works out over #163, I'm of course willing to split the bounty @darksworm ;-).

These vertical rotations do not work correctly on your branch:

• -rotate 90y
• -rotate 270
• -rotate 90

My best guess was that the rotate_coords function assumes dxi, dyi are already swapped when you're rotating to a vertical orientation, but oddly enough -rotate 90x works correctly though..

It sort-of smells like there has been a bug in rotate_coords which was patched externally...

---

However it came to be, I've adapted my PR thanks to your suggestions @bk138 and think you'll find it a most appropriate solution.