KVM Foot Switch In A Few Steps

[Radishmouse], despite the handle, is not a mouse guy. Give him a keyboard and he will get around just fine in any OS or program. As it is, he’s got a handful of ThinkPads, each running a different OS. He wanted to be able to switch his nice mechanical keyboard between two laptops without the hassle of unplugging and replugging the thing. His solution: a DIY KVM foot switch.

He’s been learning about electronics and 3D design, and this problem was the perfect opportunity to dig in and get his hands dirty. After learning enough about the USB protocol and switches to figure out what had to happen, he made a prototype from a pâte tub. Though undeniably classy, this vessel would never survive the rigors of foot-stomping in feline territory. Fortunately, [radishmouse] has also been learning about 3D design. After some trial and error, he came up with a sturdy, curvy 3D-printed two-piece enclosure. We particularly like the blocks built into the bottom piece that shore up the USB ports.

There are lots of reasons to build input controls for those under-utilized appendages at the ends of your legs. You could control your ‘scope with a probe in each hand, or use a foot switch to relocate an inconvenient power button.

Via [r/functionalprint]

6 thoughts on “KVM Foot Switch In A Few Steps

  1. This is what I’d use for the foot trigger on a 3D printed copy of a 40 mm Bofors automatic cannon. Yup, that’s what I’d use and the selector switch would be a piece of cake. Boston Dynamics could do the gun crew.

    1. No FPGA used here, though? :-)

      I was wondering whether it would be possible to implement 3 (USB hub + 2xGadget interfaces) in an FPGA, along with a host interface for the downstream USB devices, and switch between them as one does with the HDMI signal.

      i.e. Connect a keyboard and mouse to the FPGA either directly or via a hub (up to you), then present the received USB descriptors on each of the 3 “upstream” interfaces. When the host polls for reports, respond with an appropriate null report if the host is not selected, or forward the request through to the relevant downstream device.

      W.r.t. the Host reacting when the display is switched away, surely maintaining the “presence detect” signal at an appropriate level should take care of that?

      1. I built an EDID dongle last weekend with an I2C EEPROM (from old DIMM) and a right angle HDMI adapter. The EEPrOM was reporgrammed with my monitor’s EDID with all of the address pins grounded. I cut off the trace to the I2C clock pin at the socket side and wire it to Gnd.

        It works well as a pass through stopping OS screen shuffles. I should have bought the 270 or straight male-female adapter to solve connector clearance problem.

        The HDMI switch is a MUX and so is the USB switch I use. No protocols are needed. I supposed you could make a hub, but it is a lot of work vs a $1 MUX.

        1. Sure. But treating it as a simple mux means you lose the screen or the device each time you switch whatever is downstream of it. I was contemplating a way that could alleviate this problem. But I guess that is why you pay $300 for a KVM that has these features!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.