Мышь с кнопками вперед / назад и удаленным рабочим столом

Question

У меня Logitech MX518, у которого есть приятные кнопки «вперед» и «назад», встроенные непосредственно в мышь. Они отлично работают на местном уровне. Однако в любое время через удаленный рабочий стол эти кнопки ничего не делают. Это происходит как с удаленным рабочим столом Windows, так и с удаленным рабочим столом Windows Store / Windows Metro.

Компьютер, к которому я подключаюсь на работе, имеет ту же мышь, которая, когда физически на моем столе нормально работают кнопки вперед и назад.

Есть ли способ заставить удаленный рабочий стол правильно соблюдать эти команды?

Answer 1

Отсюда: https://community.wyse.com//forum/showthread.php?2398-Additional-buttons-on-mouse-don-t-work

Эти кнопки не основаны на HID. Они требуют водителя. Обычно этот драйвер встроен в Windows, поэтому его не видно. Обычный RDP не может туннелировать USB-устройства, которые не являются HID. HID-устройства, такие как мышь и клавиатура, направляются в удаленный сеанс, а дополнительные кнопки - нет. Для этого вам понадобится USB-туннель.

Таким образом, драйвер будет частью вашего решения, но также потребуется USB-туннель, поскольку протокол удаленного рабочего стола даже не отправляет необходимую информацию, которая понадобится драйверу.

Быстрый поиск в Google дал этот многообещающий результат: http://www.usb-over-network.com/

Тем не менее, я не использовал это решение и поэтому не могу говорить о его эффективности.

Answer 2

Это не совсем та же проблема, но она достаточно похожа, поэтому я объясняю свой вариант использования и решение в надежде, что это поможет кому-то еще. У меня есть Logitech Performance MX (который не позволяет менять сочетания клавиш для определенных приложений) с кнопками «Назад» и «Вперед», которые отлично работают на OSX, но не так много, когда используются через Windows RDP.

Back и Forward в OSX - это ⌘+← и ⌘+→ соответственно, что эквивалентно Windows Key+← и Windows Key+→ через подключение к удаленному рабочему столу. Windows ожидает, что вместо клавиши Windows будет использоваться Alt, и поэтому вместо просмотра назад / вперед она будет пытаться закрепить окно браузера на одной стороне экрана или на другой. Не то, что мы хотим.

Я перепробовал все возможные способы обхода, включая изменение нажатий клавиш, отправляемых с помощью кнопок «вперед» и «назад», а затем переопределение функции «Вперед / Назад» для Chrome в OSX, но все вызывало проблемы.

Предложение @ LordJair заставило меня задуматься, и поэтому я установил AutoHotKey на свой компьютер с Windows. Важно не делать этого на хост-машине с использованием OSX-эквивалента, потому что RDP-клиент будет интерпретировать нажатия клавиш, и в противном случае все будет не так.

Затем я создал следующий скрипт AutoHotKey, и теперь все работает без проблем через RDP, а также в OSX:

#Left::Browser_Back
#Right::Browser_Forward

Answer 3

Что бы это ни стоило, я сейчас использую AutoHotKey для этого. Как и в случае с другими горячими клавишами, когда окно RDP активно, я заставляю XButton2, например, отправить {XButton2}. Конечно, если вы еще не используете AHK, собрать сценарий может быть слишком сложно. По какой-то причине это работает.

У меня есть мышь Logitech M510, и я разрываю ее на куски!