Closed Pokechu22 closed 6 months ago
After some further testing, there are two issues. One is that MOUSE_VIRTUAL_DESKTOP
is weird, but that's not all. I've implemented the same thing from the DirectXTK commit (Pokechu22@92380fa), but that doesn't actually work right. The cursor moves fine for a bit, but when it gets to the edge of the monitor, it stops.
It seems that SetCursorPos
doesn't work right when the cursor is hidden via SetCursor(NULL)
, so the re-centering logic isn't working. I've verified that by adding another key to the cursor test (this is not in the previously linked commit):
case GLFW_KEY_M:
{
int width, height;
glfwGetWindowSize(window, &width, &height);
glfwSetCursorPos(window, width / 2, height / 2);
break;
}
When the cursor is visible, it moves back to the center and moving it around starts from the center. However, when it is hidden (not disabled), the tracking lines move to the center but the actual cursor does not. I suspect that this is a special behavior for the NULL
cursor, and will try using an invisible custom cursor instead.
Hey, is it still being worked on?
I tired using the master branch version of glfw and the problem is still there! As my software is used over RDP a lot (Chrome Remote Desktop shows similar problem) this is a big bummer!
It seems as if my absolute mouse position was mapped the values dx
and dy
instead of x
and y
. When I rotate my 3D camera that is controlled by the disabled cursor, I keeps spinning faster and faster. The problem is not as extreme when I start from the middle of the screen, but the behavior is still erroneous there.
I haven't worked with RDP in several years. However, the changes in #1279 may still be relevant.
Note that the behavior of a NULL
cursor causing cursor position updates to not be sent is possibly specific to Windows' Remote Desktop Connection, and Chrome Remote Desktop might have a different behavior (or might not support cursor position updates at all).
What I found is that setting cursor position does not work at all with RDP, regardless of the cursor mode. When beginning dragging (left mouse click) I did the following:
GLFW_CURSOR_NORMAL
, never change itglfwSetCursorPos
At this point I don't care about subpixel precisionThe setting of cursor position simply didn't work. The 3D camera was rotating faster when moving away from the initial drag point and slower when the mouse pointer was returning to it (some space simulator games come to mind)
I found that glfw does similar thing under the hood when using the disabled cursor, but it is comparing against virtual mouse position that does not match the initial mouse position and so the numbers get huge really fast.
I don't have anything set up to test anymore, but both "The setting of cursor position simply didn't work" and "but it is comparing against virtual mouse position that does not match the initial mouse position" sound like things I fixed in #1279, so it may be useful to try to rebuild that.
Hi @Pokechu22 , @elmindreda ,
Are there any plans to update this issue going forward? The latest master (56a4cb0) still seems to have this behavior over RDP.
I tried integrating the changes from PR #1279 into the above commit, but it seems I'm missing something as I could not get it working.
Thank you!
I have replicated this issue with RDP, but I have also discovered that it also appears when using a VM - in particular I tested with Windows 8 x64 Pro with VMWare Player and this issue was present.
After some experimentation the VM issue appears to be a different problem with a very similar effect. The main differences are that the solution #2431 doesn't fix the issue, and if the cursor is held stationary for a while after switching to disabled cursor it behaves as expected - so it's likely this is a separate issue potentially due to a delayed mouse message appearing to cause a large virtual position change (I will investigate this later).
OS and version: Windows 10 64-bit Release or commit: Tested both 617a322bd88c1b27f1fd7d05dc3723b6c5461a68 and the version comes with LWJGL 3.1.2 (2f5e2303380d084ab9b097765d34f98504324d65 it seems)
When connected over RDP, disabled cursor input doesn't work correctly; the cursor goes far off the screen (causing rapid rotation if mouse input is being used for that -- e.g. the
wave
example program). (This was originally reported as MC-126875).To reproduce:
cursor
test. Enable RDP connections to your machine.cursor
test.This doesn't happen when connected locally.
Here's the output provided by the program:
I did do some debug logging of what the raw
WM_INPUT
event looked like. On my local machine, the flags value is0
and the positions are0 4
or similar. However, when connected via RDP, the flags value is3
and positions are very large (e.g.9984 12588
).3
isMOUSE_MOVE_ABSOLUTE | MOUSE_VIRTUAL_DESKTOP
per the documentation on the RAWMOUSE structure, but unfortunately it doesn't explain howMOUSE_VIRTUAL_DESKTOP
is supposed to be handled.I have found some other sources though. This StackOverflow post gives an example of what works for them (but the author admits that it's not from any documentation). I also found Microsoft/DirectXTK@ef56b63f3739381e451f7a5a5bd2c9779d2a7555 which seems to be a case of them fixing the same issue. However, I haven't had time to experiment with this yet (if I do get it working, I'll try to submit a pull request).