However, as stated, there are some drawbacks. That's it! You now have a hardware mouse attached "directly" to your VM, which allows the 3D games to pull out the relative mouse movements directly from the mouse driver (-ish.) Select your mouse (or other appropriate entry). Under that you should see an entry for your mouse it might be a bit ambiguous such as: You can use this setting to map through many types of USB hardware that you couldn't with vanilla RDP USB redirection, as shown below. Once it's enabled, access the Local Resources tab, click More under Local devices and resources, and you'll see a new Other supports RemoteFX USB devices setting. Step 3: Set the RDP client to redirect the mouse. "GUID_DEVINTERFACE_MOUSE"=""ĭepending on your mouse, you might need a different identifier, so YMMV. You can add a string value with the device identifier.įor example, under this key I added the following string value: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client\UsbSelectDeviceByInterfaces Step 2: Enable the redirection override for the mouse.Īs this MS KB article explains, you can set a registry key to enable a specific device (or class of device) for USB Redirection. Well, the final answer, as it turns out, is that there is an override mechanism to this block.īasically, on the client machine, you use either Local Policy or Group Policy to set RemoteFX USB Device Redirection to Enable, and allow users (or just admins) the rights. Consequently, these devices are not offered via RemoteFX USB redirection. 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. 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). 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |