- #CHROME REMOTE DESKTOP NO MOUSE VISIBLE DRIVER#
- #CHROME REMOTE DESKTOP NO MOUSE VISIBLE WINDOWS 8.1#
These methods of redirection enable optimal performance and backward compatibility of the device in the majority of user scenarios. However, not all was for naught, during all that digging into the RDP protocol, I looked at the RemoteFX USB Redirection - and that looked like a dead-end, since basic input devices (such as mouse, keyboard, printer) are explicitly blocked from the USB Redirection mechanism:īy default, devices in the aforementioned categories are accessible in the remote session by using high-level device redirection methods. Well, if it did, this would be an SO question, sorry to lead you on (but I think its good to have it documented somewhere.) So, I set to work implementing a simple WinForms app to host the ActiveX control, with the ".Unsafe" interface properties set.Įxcept that as it turns out, by "unsupported", this time Microsoft meant "it does not work". It was also poorly documented, but it seemed that I had what I needed - this question on StackOverflow also gave me hope that it was doable. However, I did note on this MSDN Forums post that "RelativeMouseMode is not supported in RDP RDSH/RDVH scenarios and should not be used", but I figured to heck with it, it's not a real production environment, and I was fine using a feature that is not supported. Thanks to answer, and in particular the post he linked to, I was able to follow the lead, and eventually discovered that amongst the many interfaces implemented by the Remote Desktop Client ActiveX, one of them supports a RelativeMouseMode property! That sounds like exactly what I need, it will force the RDP to support relative mouse movements! Well, mostly solved it - it is functional, but not without drawbacks. Wow, after a ton of research and failed attempts, I actually solved this! I am hoping to find ANY kind of solution to this. it seems it is still reporting it's location "left of center" instead of "moving to the right"). the mouse is still to the left of center, but moving to the right) it continues to jump left. if I move the mouse a bunch to the left, the view jumps crazily to the left if I then move it a bit to the right, but still not all the way back to center (i.e. location-based mouse and not motion-based), and also with the in-game behavior - e.g. move it out the window on the left, back in on the right - and it behaves perfectly, i.e. This "theory" correlates well with some explanations of how the mouse pointer jumps in and out of the RDP window (e.g.
#CHROME REMOTE DESKTOP NO MOUSE VISIBLE DRIVER#
in the game menus the mouse is just fine).Ĭlosest I could tell, from both experimentation and much searching online (many other people had the same problem, but no solution found) - it seems the mouse driver transmits its relative location, instead of movement. The problem is that the mouse reacts quite crazily when in game - but completely normal outside of the 3D environment. It definitely allows games to be very playable over RDP (if it weren't for the mouse).
#CHROME REMOTE DESKTOP NO MOUSE VISIBLE WINDOWS 8.1#
VM with Windows 8.1 Enterprise, RemoteFX and vGPU configuredģD video performance is great, thanks to RemoteFX/vGPU.
Windows 2012 R2 with Hyper-V and strong graphics card.It seems that the default mouse driver when connecting with RDP does not work well with certain applications, such as 3D games.
0 kommentar(er)
