Mouse with forward/back buttons and remote desktop

I have a logitech MX518 that has nice forward and back buttons built onto the mouse directly. They work great locally. However anytime over remote desktop these buttons do nothing. This happens both with the Windows Remote Desktop and the Windows Store / Windows Metro Remote Desktop.

The computer I'm remoting to at work has the same mouse, which when at my desk physically the forward and back buttons work fine.

Is there any way to get remote desktop to respect these commands properly?

Solution 1:

From here: https://community.wyse.com//forum/showthread.php?2398-Additional-buttons-on-mouse-don-t-work

Those buttons are not HID based. They require a driver. Usually that driver is built into Windows, so you don't see it install. Regular RDP cannot tunnel USB devices that are not HID. HID devices, like mouse and keyboard, are directed into the remote session, but the extra buttons aren't. You will need a USB tunnel for that.

So, a driver will be part of your solution, but a USB tunnel will be necessary as well because the Remote Desktop protocol doesn't even send the necessary information the driver will need.

A quick Google search returned this promising result: http://www.usb-over-network.com/

However, I have not used this solution and so cannot speak to its efficacy.

Solution 2:

For what it's worth, I currently use AutoHotKey to do this. Just like with other hotkeys, when the RDP window is active, I cause the XButton2, for example, to Send {XButton2}. Of course, if you're not already using AHK, then it might be too much trouble to get a script together. For whatever reason, it works.

I have a Logitech M510 mouse and luvz it to pieces!

Solution 3:

This isn't the exact same problem, but it's similar enough that I'm explaining my use case and solution in the hopes it will help somebody else. I've got a Logitech Performance MX (which doesn't let you change keyboard shortcuts for specific apps) with Back and Forward buttons which work great on OSX, but not so much when used through Windows RDP.

Back and Forward on OSX is ⌘+← and ⌘+→ respectively, which is the equivalent of Windows Key+← and Windows Key+→ over a remote desktop connection. Windows expects Alt to be used instead of Windows Key and so instead of Browsing back/forward, it will attempt to pin the browser window to one side of the screen or another. Not what we want.

I tried all sorts of work arounds, including changing the keystrokes that got sent with the forward and back buttons and then redefining the Forward/Back for Chrome on OSX, but everything caused problems.

@LordJair's suggestion got me thinking though, and so I installed AutoHotKey on my Windows machine. It's important not to do this on the host machine using an OSX equivalent because the RDP client will be what's interpreting the keystrokes and things get messy otherwise.

I then created the following AutoHotKey script and now everything works flawlessly through RDP and also on OSX:

#Left::Browser_Back
#Right::Browser_Forward