-
Notifications
You must be signed in to change notification settings - Fork 946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REQUEST] Mouse synchronization/grabbing/capture/wrapping #619
Comments
XWayland has pointer warping detection/emulation that could be used as a reference: https://lists.x.org/archives/xorg-devel/2016-April/049351.html We also need to look at a VNC protocol extension for this. |
Worth mentioning that the current mouse handling breaks more than just games. For example both PCem and FS-UAE end up with the mouse shooting towards the bottom right-hand corner as soon as you move the mouse and there's nothing you can do to prevent it. |
I've requested this as well, on sourceforge's tigervnc issue tracker. Glad to see someone posting it here too. It probably has a better chance of getting noticed here. |
QEMU has an extension for this called "Pointer Motion Change" that might fit. |
The QEMU extension lets ONLY the server request for relative mouse movement messages. The client cannot send relative mouse movements without being requested. But how is the server to know if relative mouse movements are required or not? Only the person using the client can know ... |
It is the server that best knows what type of input it needs. If the VNC server is a proxy to real hardware, it knows what hardware is being used. If this is a normal relative mouse it will be easier to request relative events. I'm not theorizing, I just really have this situation. My server that I wrote can pretend to be relative mouse and wants to receive relative events. It would be great if TigerVNC could capture exclusive access to the mouse. |
How is the server to know if a game is behaving strange because it only works with relative mouse movements? Only the user knows that. There must be a way for the user to switch from relative to absolute mouse movements or vice versa. This is how it is implemented in RealVNC as well ... |
This is a different situation. QEMU pointer change is needed when the server is not able to handle absolute events. The client does not have a choice, it must give relative events. We have slightly different cases. In my case, the VNC server is something like a proxy and converts events in VNC to hardware events, emulating a real input device. That is, if it emulates absolute coordinates (such as a Wacom tablet) that's all right. But I want to emulate a normal mouse, and for this I need QEMU pointer change. Actually, this extension exists for this purpose, so that QEMU can emulate hardware for the OS inside itself. |
Patches are always welcome, so if you want to try adding this to the TigerVNC client yourself then please submit a PR and we can have a look. |
@CendioOssman I'm not very good at developing desktop cross-platform software. I guess I could make a patch for Linux, but will you require me to implement for OS X and Windows to take it to the upstream? |
We'll need all three to get this fully merged, but start with the Linux code and we can see if we can help out with the other two. |
This change adds support for the VMware Mouse Position pseudo-encoding[1], which is used to notify VNC clients when X11 clients call `XWarpPointer()`[2]. This function is called by SDL (and other similar libraries) when they detect that the server does not support native relative motion, like some RFB clients. With this, RFB clients can choose to adjust the local cursor position under certain circumstances to match what the server has set. For instance, if pointer lock has been enabled on the client's machine and the cursor is not being drawn locally, the local position of the cursor is irrelevant, so the RFB client can use what the server sends as the canonical absolute position of the cursor. This ultimately enables the possibility of games (especially FPS games) to behave how users expect (if the clients implement the corresponding change). Part of: TigerVNC#619 1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding 2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html 3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804
This change adds support for the VMware Mouse Position pseudo-encoding[1], which is used to notify VNC clients when X11 clients call `XWarpPointer()`[2]. This function is called by SDL (and other similar libraries) when they detect that the server does not support native relative motion, like some RFB clients. With this, RFB clients can choose to adjust the local cursor position under certain circumstances to match what the server has set. For instance, if pointer lock has been enabled on the client's machine and the cursor is not being drawn locally, the local position of the cursor is irrelevant, so the RFB client can use what the server sends as the canonical absolute position of the cursor. This ultimately enables the possibility of games (especially FPS games) to behave how users expect (if the clients implement the corresponding change). Part of: TigerVNC#619 1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding 2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html 3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804
This change adds support for the VMware Mouse Position pseudo-encoding[1], which is used to notify VNC clients when X11 clients call `XWarpPointer()`[2]. This function is called by SDL (and other similar libraries) when they detect that the server does not support native relative motion, like some RFB clients. With this, RFB clients can choose to adjust the local cursor position under certain circumstances to match what the server has set. For instance, if pointer lock has been enabled on the client's machine and the cursor is not being drawn locally, the local position of the cursor is irrelevant, so the RFB client can use what the server sends as the canonical absolute position of the cursor. This ultimately enables the possibility of games (especially FPS games) to behave how users expect (if the clients implement the corresponding change). Part of: TigerVNC#619 1: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vmware-cursor-position-pseudo-encoding 2: https://tronche.com/gui/x/xlib/input/XWarpPointer.html 3: https://hg.libsdl.org/SDL/file/28e3b60e2131/src/events/SDL_mouse.c#l804
#1198 is now merged, so this should be fixed. |
This is great news! I'll try the latest build. |
I would argue that this issue was a bit eagerly closed. From what I can Raw mouse input supportFirst and foremost, we currently lack support for raw mouse input, In the case of SDL, raw mouse input is the default over the hacky way Worth noting is that this can be worked around, at least for SDL, if [1] https://github.com/libsdl-org/SDL/blob/b7a0200aab8088e04800d33cc88fee384df0d78c/include/SDL_hints.h#L896 Tolerance to large RTTsAnother issue in the current implementation is that it is not The above scenario is slightly relieved by the fact that we grab the |
No, it is not. Hence why this issue is open again. It only works in some cases unfortunately. |
actually it already able to run some game that can disable "raw input" (such as minecraft). but maybe due tigervnc/vncviewer/DesktopWindow.cxx Line 1129 in 969f927
this line of code not working under wayland. pointer will only be grabbed under fullscreen (controlled by these two lines of code) tigervnc/vncviewer/DesktopWindow.cxx Line 841 in 969f927
tigervnc/vncviewer/DesktopWindow.cxx Line 914 in 969f927
|
@CendioOssman @mdevaev I would really like this functionality. Is there any updates or reasons we aren't proceeding? |
There is simply no developer currently working on this. |
It would be nice if there was even just a button in the client to lock the cursor to the center and send relative movements to the server rather than absolute ones. That might work for most use cases. (No idea if the server would support tht, though.) |
+1 for this feature. Huge step forward for piKVM |
+1 for this feature! I just tested the Parsec app and it works GREAT for Windows hosts. However, my machines are all Linux hosts with NVIDIA/AMD/Intel cards, and Parsec does not host (share) a Linux screen, only Windows, which is a shame. Otherwise, Parsec would be the final solution for me. So, now, I'm looking forward to testing Sunshine/Moonlight BUT, there's also PiKVM v4 coming out soon! And this feature might be the only missing thing so we can use PiKVM for gaming or other 3D-based work. Please, implement this! |
i am also having issues here on debian bookworm. vnc session works flawlessly as long as the host doesnt use any application that grabs the cursor. if something does need to grab the cursor, its completely unusable. |
A solution i find was use a script with "xdotool mousemove --sync X Y", running in loop, so i can use the vnc to play minecraft lol |
my awful current workaround is to use usbip. |
using TigerVNC 1.12.0. mouse grabbing doesnt work. despite support for this feature being in the release notes. |
I'm trying to develop an alternative for Nvidia GameStream or Steam In-Home Streaming, but using VNC (+ PulseAudio) due to the architecture/hardware/OS limitations of the former technologies.
I've been able to run CS:GO and BioShock Infinite perfectly inside
vncserver
(using VirtualGL/optirun
+ some hacks on Steam command launcher), but unfortunately these FPS games (and probably most of FPS games) are known to use the following steps to allow 360° view rotation:Without being able to reposition the mouse to the center, the game will spin endlessly because the relative distance of the mouse to the center of the screen will always be enormous.
I've been reading on the internet reports of other VMs/VNCs lacking this feature and I found some relevant discussions (Parallels, Splashtop, Splashtop again, Splashtop AGAIN, Synergy conflict) about these implementations (or lack of).
Anyway, my feature request is the same as all of these linked topics: Is it possible to sync/grab/capture/wrap the mouse inside the VNC viewer? This feature is implemented for keyboard on fullscreen mode only, but doesn't apply to mouse movements.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: