Nieregularny ruch myszy w grach 3D przez RDP z RemoteFX

Wygląda na to, że domyślny sterownik myszy podczas łączenia z RDP nie działa dobrze w przypadku niektórych aplikacji, takich jak gry 3D.

Moja konfiguracja:

• Windows 2012 R2 z funkcją Hyper-V i mocną kartą graficzną
• VM z skonfigurowanym Windows 8.1 Enterprise, RemoteFX i vGPU
• Łączenie z RDP przez szybkie łącze.

Wydajność wideo 3D jest świetna dzięki RemoteFX / vGPU. Zdecydowanie pozwala to na bardzo łatwą rozgrywkę przez RDP (gdyby nie mysz).

Problem polega na tym, że mysz reaguje dość szalenie podczas gry - ale całkowicie normalnie poza środowiskiem 3D. (Np. W menu gry mysz jest w porządku).

Najbliższe, co mogłem powiedzieć, zarówno z eksperymentów, jak i poszukiwań w Internecie (wiele innych osób miało ten sam problem, ale nie znaleziono rozwiązania) - wygląda na to, że sterownik myszy przekazuje swoją względną lokalizację zamiast ruchu.
Ta „teoria” dobrze koreluje z niektórymi objaśnieniami, w jaki sposób wskaźnik myszy wskakuje i wychodzi z okna RDP (np. Przesuwa go z okna po lewej, z powrotem po prawej - i zachowuje się idealnie, tj. Mysz oparta na lokalizacji i nie oparte na ruchu), a także z zachowaniem w grze - np. jeśli przesunę mysz o kilka w lewo, widok przeskakuje szaleńczo w lewo; jeśli następnie przesunę go nieco w prawo, ale nadal nie do końca z powrotem do środka (tj. mysz nadal znajduje się na lewo od środka, ale przesuwa się w prawo), nadal przeskakuje w lewo. (Tzn. Wydaje się, że nadal zgłasza swoją lokalizację „na lewo od centrum” zamiast „przesuwania się w prawo”).

Mam nadzieję znaleźć JAKIEKOLWIEK rozwiązanie tego problemu. Pomysły ktoś?

Wow, po mnóstwie badań i nieudanych próbach, faktycznie to rozwiązałem!
Cóż, w większości rozwiązany - jest funkcjonalny, ale nie bez wad.

Dzięki odpowiedzi @ JourneymanGeek, a w szczególności postowi, do którego prowadził link, mogłem podążać za przykładem i ostatecznie odkryłem, że spośród wielu interfejsów zaimplementowanych przez ActiveX Client ActiveX jeden z nich obsługuje właściwość RelativeMouseMode ! To brzmi dokładnie tak, jak potrzebuję, zmusi RDP do obsługi względnych ruchów myszy!

Jednak zauważyłem w tym poście na forach MSDN, że „RelativeMouseMode nie jest obsługiwany w scenariuszach RDP RDSH / RDVH i nie powinien być używany”, ale pomyślałem, że mogę się z tym pogodzić, nie jest to prawdziwe środowisko produkcyjne, i dobrze mi było, używając funkcja, która nie jest obsługiwana. Był również słabo udokumentowany, ale wydawało się, że mam to, czego potrzebowałem - to pytanie na StackOverflow dało mi również nadzieję, że jest wykonalne.

Zacząłem więc wdrażać prostą aplikację WinForms do obsługi formantu ActiveX z ustawionymi właściwościami interfejsu „... Niebezpieczna”.

Tyle że, jak się okazuje, przez „nieobsługiwany” tym razem Microsoft miał na myśli „nie działa”.
Cóż, jeśli tak, to pytanie SO, przepraszam, że cię poprowadzę (ale myślę, że dobrze jest gdzieś to udokumentować ...)

Jednak nie wszystko poszło na marne, podczas całego kopania protokołu RDP spojrzałem na przekierowanie USB RemoteFX - i wyglądało to jak ślepy zaułek, ponieważ podstawowe urządzenia wejściowe (takie jak mysz, klawiatura, drukarka) są wyraźnie zablokowane z mechanizmu przekierowania USB:

Domyślnie urządzenia z wyżej wymienionych kategorii są dostępne w sesji zdalnej przy użyciu metod przekierowania urządzeń na wysokim poziomie. Te metody przekierowania umożliwiają optymalną wydajność i kompatybilność wsteczną urządzenia w większości scenariuszy użytkownika. W związku z tym urządzenia te nie są oferowane przez przekierowanie USB RemoteFX.

Cóż, ostateczną odpowiedzią, jak się okazuje, jest to, że istnieje blokowanie tego bloku.

Krok 1: Włącz przekierowanie USB RemoteFX.
Ładne opracowanie: http://windowsitpro.com/virtualization/q-how-do-i-enable-remotefx-usb-redirection . Zasadniczo, na komputerze klienckim, należy użyć Polityka lokalna lub zasad grupy do zestawu RemoteFX USB Device Redirectiondo Enablei pozwalają użytkownikom (lub tylko adminów) prawa. Następnie gpupdate /forceuruchom ponownie.

Krok 2: Włącz funkcję przekierowywania myszy.
Jak wyjaśnia ten artykuł MS KB , możesz ustawić klucz rejestru, aby włączyć określone urządzenie (lub klasę urządzenia) dla przekierowania USB.

Ponownie na kliencie, pod

HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows NT \ Terminal Services \ Client \ UsbSelectDeviceByInterfaces

możesz dodać wartość ciągu za pomocą identyfikatora urządzenia.
Na przykład pod tym kluczem dodałem następującą wartość ciągu:

„GUID_DEVINTERFACE_MOUSE” = „{378DE44C-56EF-11D1-BC8C-00A0C91405DD}”

W zależności od myszy może być potrzebny inny identyfikator, więc YMMV. Ale zacznij od tego.

Krok 3: Ustaw klienta RDP tak, aby przekierowywał mysz.
Zgodnie z artykułem z kroku 1:

Po włączeniu przejdź do karty Zasoby lokalne, kliknij Więcej w obszarze Lokalne urządzenia i zasoby, a zobaczysz nowe ustawienie Inne obsługuje urządzenia USB RemoteFX. Możesz użyć tego ustawienia, aby zmapować wiele rodzajów urządzeń USB, których nie można było zastosować przy przekierowaniu waniliowym RDP USB, jak pokazano poniżej.

Poniżej powinieneś zobaczyć wpis dla myszy; może być nieco niejednoznaczny, na przykład:

Wybierz mysz (lub inny odpowiedni wpis).

Otóż ​​to! Masz teraz sprzętową mysz podłączoną „bezpośrednio” do maszyny wirtualnej, co pozwala grom 3D wyciągać względne ruchy myszy bezpośrednio ze sterownika myszy (-ish ..)

Jednak, jak stwierdzono, istnieją pewne wady.

1. Mysz zostaje przekierowana na maszynę wirtualną RemoteFX'd - innymi słowy, komputer kliencki nie ma już myszy , przynajmniej gdy sesja pulpitu zdalnego jest otwarta.
   Możliwym rozwiązaniem byłoby podłączenie drugiej myszy i przekierowanie tylko jednej z nich. (Muszę jeszcze tego spróbować, ale powinno działać dobrze).

2. Z jakiegoś powodu po przekierowaniu mysz nie pokazuje bezpośrednio kursora w sesji zdalnej. Mimo że nadal działa, nieco mylące jest celowanie myszą.
   Prostym rozwiązaniem jest włączenie szlaków myszy przy zmniejszonej długości do końca.
   Spowoduje to wyświetlenie lokalizacji myszy, ale jest nieco powolny.

3. Ogólnie rzecz biorąc, chociaż to rozwiązanie działa dobrze, mysz jest nadal nieco powolna i powolna.
   Można włączyć się prędkość myszy, bawić się z dokładnością wskaźnika (czasem wyłączając go będzie rzeczywiście pomóc z tym), a nawet kręcić z ustawieniami rejestru przyspieszenie pod mysz HKEY_CURRENT_USER\Control Panel\Mouse( Mouse Speed, MouseThreshold1, i MouseThreshold2, odpowiednio).
   Pomoże to złagodzić problem, ale nie sprawi, że zniknie.

Ogólnie rzecz biorąc, może to sprawić, że nawet gry 3D będą bardzo grywalne - do zwykłych gier, niestety nie świetne do gier typu twitch. (Chociaż jeśli potrzebujesz, możesz po prostu załadować metal bezpośrednio do tego dysku VHD i mieć obie opcje ...)

Najwyraźniej remotefx robi tylko tryby wprowadzania „absolutne” w stylu tabletu , co jest źródłem problemu. Nie mogę znaleźć żadnej dokumentacji dotyczącej jej zmiany.

Być może trzeba rozważyć alternatywny tryb zdalnego dostępu - Steam działa dla mnie dobrze (za pomocą procesora graficznego nvidia na „hoście” i dinky małej zatoczce na drugim końcu). Nvidia ma opcję dla swoich kart, ale tak naprawdę nie próbowałem tego.

Krótko mówiąc, nie ma oczywistego sposobu, aby to naprawić za pomocą remotefx, chyba że w grze można ustawić tryb wprowadzania używany przez remotefx.

Pulpit zdalny przesyła bezwzględne ruchy myszy, jako sposób na zmniejszenie liczby pakietów ruchów myszy, które muszą być wysłane z klienta na serwer. To ustawienie działa dobrze w przypadku większości aplikacji Windows (e-mail, przeglądanie stron internetowych itp.). Wiele gier 2D jest również w porządku. Jednak gry FPS zazwyczaj wymagają względnych ruchów myszy, aby kontrolować wygląd myszy, którego Pulpit zdalny niestety nie przesyła. Utrata względnych danych ruchu myszy powoduje, że gra niespodziewanie obraca rzutnię. Microsoft będzie musiał zmodyfikować Pulpit zdalny, aby ten scenariusz gry zadziałał. Jednak użycie kontrolera XBOX na PC z przekierowaniem USB może być dla Ciebie alternatywą.