BeagleBones And Teensies Become KVMs

[pmf], like most of us, I’m sure, spends most of his days on a computer. He also has a smartphone he keeps at his side, but over the years he’s grown accustomed to typing on a real keyboard. He came up with the idea of making a USB switch that would allow his keyboard to control either his computer or his phone, and hit upon a really neat way of doing it. He’s using a BeagleBone Black and a Teensy to switch his keyboard between his computer and his phone with just a press of a button.

This homebrew smart KVM uses a BeagleBone Black for most of the heavy lifting. A keyboard and mouse is connected to the USB host port of the BeagleBone, and the main computer is connected to the device port. The BeagleBone is set up to pass through the USB keyboard and mouse to the computer with the help of what Linux calls a ‘gadget’ driver. This required an update to the Linux 4.0 kernel.

With the BeagleBone capable of being a USB pass through device, the next challenge was sending keypresses to another USB device. For this, a Teensy 2.0 was connected to the UART of the BeagleBone. According to [pmf], this is one of the few examples of the Teensy serving as a composite USB device – sending both keyboard and mouse info.

There are a few neat features for [pmf]’s build: the keyboard and mouse don’t disconnect when switching, and thanks to a slight modification of the USB OTG adapter, this will also charge a phone as well as allow for the use of a keyboard. Because the BeagleBone Black has more than one UART this build can also switch keyboards and mice between more than two computers. For those of us who invest heavily in keyboards, it’s a godsend.

41 thoughts on “BeagleBones And Teensies Become KVMs

  1. It’s surely a very nice thing, and I liked all the trouble he went thru to make it work. But there’s a cheaper software solution…

    I use Android on my phone, and Linux on all my desktops. My Linux is a hotspot too, and I connect my phone to it. On my phone, I use a special keyboard, Remote Keyboard, that spawns a telnet server on the phone and “types” everything I send to it.

    On the Linux side, I just open a terminal, telnet to the phone, and use my keyboard to input text on the phone. My phone is just an alt-tab way. No mouse anyway, but using the keyboard is more than enough for me.

    1. Hi thoriumbr, great setup!

      I’m not a big mouse fan either, but I find that without it, it’s quite difficult to effectively navigate in Android. In fact some applications seem to be practically unusable without a mouse.

      Another reason for this design is that I tend to work in environments where the desk workstations are completely locked down, so it’s impossible for me to connect to a personal device over the network.

      Thanks for sharing!

        1. I have used Synergy2 since ’03, more or less, and it’s great! I don’t use it now because I have only one computer around me most of the time.

          I tried the last installment of the Android client but it does not liked the ROM on my OnePlus One.

    2. A simpler solution (than the BBB) taking this approach is to marry a teensy and a USB-serial adapter. USB serial adapter takes keystrokes e.g. via a terminal emulator and passes them to the teensy, which emits them as scan codes. No network required between the two devices, and this can then be applied to any type of computer, in any stage of booting. Of course, your solution has no hardware required, so it has that benefit, of course.

        1. Sure, fair enough. If you need something more advanced, write a somewhat more intelligent program that sends scancodes over the serial port. The “terminal emulator” approach may be enough for many purposes, and could even work alternately. e.g. the Teensy supports both modes.

        1. for future references. An another valid usecase is remote camera shutter.
          You need two smartphone. One with remote keyboard installed, on other a telnet client.
          You create a hotspot, and connect the telnet to the remote keyboard. Start the camera, and you can remotely activate the camera via the ENTER key (Send button on telnet client).

          No more selfie stick :) But really it is a valid usecase. Setup takes about 20 sec, so not that much of a hassle.
          I will try out next weekend, I will hitchhiking somewhere with my wife,
          just to see how it works in real life (I played it the whole afternoon:)

  2. Very cool project, particularly if automatic VID/PID masquerating works (wasn’t clear to me), but as the author states, it doesn’t handle the “monitor” part of “KVM”.

    1. Yeah I’m totally guilty of abusing the term. The problem is I couldn’t find a better short name which would allow people to understand what the thing is. I’d love to hear ideas for a better name.

      1. Is adding video a plan for the future? Android can do it. Either through USB (I think), and do they have some option that somehow lets HDMI out of it somewhere? Last, there’s the wireless display option, works over Wifi. It’s good enough to send video over. As you might be able to tell, I’m not overflowing with the names of all these gadget things. Point is though, you could add video with the hardware you have now (assuming Beaglebone has wifi, or get a wifi adaptor). It would add value to your project, using Android with a proper mouse and keyboard deserves a proper display too.

        1. Wireless display is called Miracast. The alternatives for video out are MHL or Slimport (using a wired connection).

          Depending on the implementation, MHL can support simultaneous HDMI and USB otg (11-pin devices only), but slimport cannot, it seems. They can both charge the device, however. You’d still need something to process the video signal into something that the BBB can handle. Given that both “computers” in this case have their own display, the benefit may not be that substantial, unless your goal is to use the phone as a desktop replacement, and want a bigger screen for it.

          That leaves Bluetooth as an option for connecting a mouse and keyboard to a generic phone. In theory, the BBB with a Bluetooth (LE?) adapter should be able to connect to the phone and present itself as a bluetooth keyboard/mouse in much the same way as it does in the above article.

          1. I just thought, if you’re gonna use a mouse and keyboard on your phone, may as well go the whole hog if there’s a screen in front of you. Probably gonna be the difficult part. That said my sister has a Bluetooth keyboard for her phone, if you type a lot it can be worth it, and as a backup for the PC. Though I’m surprised how fast I am with Swype, aside from it guessing the wrong word 50% of the time. Definitely get Swype for your phone if it doesn’t come with it.

      2. Maybe call it a HID switch?

        I could see this being a really useful solution in combination with something like a Monoprice HDMI matrix switch. Many of those are controllable via RS232, and they’re a fraction of the cost of DisplayPort KVMs.

    1. Thanks for pointing out the Synergy for Android project, TJ.

      Yeah reading the comments I see that the term KVM is somewhat misleading. Any ideas for a better name for the device?

    1. happy hacking keyboard. Professional 2. $250, which is a bit high for a torpre board, but you’re paying for minimalism here. Looks like he has a clack, too.

      If you want the same feel for less, I’m loving my CM Novatouch w/ symbiosis caps:

    1. Ha, indeed I did! The main issue with using a mechanical switch with USB is the latency you incur at switch time. The OS has to detect and install the device, which can easily take the better part of a second or more. That gets somewhat annoying if your workflow requires going back and forth quickly. On the other hand, with this design, all computers (and phones) think they are continuously connected to a keyboard and mouse so they are ready to go the instant you switch.

      Thanks for your comment!

  3. Neat! Instead of using a Teensy for Serial-to-USB HID, I want to use an iPod running Rockbox.

    It’s already possible to use the iPod as a USB volume/track/presentation controller, using hard-coded USB keystrokes.
    http://download.rockbox.org/manual/rockbox-sansafuze/rockbox-buildch8.html#x11-1500008.5.7

    There is a serial port already coded in Rockbox, but it only supports Tx from the iPod to a computer for logging. I need help to code serial Rx. Then I’ll make a plugin to take a serial input stream and copy the characters to USB keyboard/mouse.

    The final setup will look like this: iPhone app -> DIY dock-connector serial male-male cable (parts from Ridax) -> iPod serial input -> Rockbox -> iPod USB HID output. Then I can use my phone or any other serial device as a USB keyboard!

  4. I’d still love to see someone make a video input cape for the BBB, using something like the TVP7002 VGA converter chip. I’m half tempted to try to cobble something together with the BeagleLogic Logic analyser, just as a proof of concept. The BBB could also respond to the host computer using I2C when it queries the “display” for its capabilities.

    Then, in combination with the USB gadget Keyboard and Mouse implemented here, you could have a complete KVM solution, which could be accessible over the network if needed. I’m thinking that the video input could be presented as a V4L device, and the display then made available using VNC or RDP.

    1. Yes! I’ve been thinking about a very similar project for a while. Every now and then, I come across some vintage device that wants to output to a VGA monitor. Instead of keeping one of those around, it would be fantastic to have a special BBB cape + VNC to view the display.

      I’ll be very interested if you put something together.

      1. So, this is what I’m thinking of, just as a cape for a BBB, rather than requiring the CPLD and extra RAM. The BBB should be able to sample the output from the TVP7002 using the PRU, much as the BeagleLogic cape does, and convert that into a framebuffer that gets switched/updated at whatever frame rate is desired/feasible.

        The alternative is to reverse engineer one of these: http://www.ebay.com/itm/141636644299?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT or similar (there are a bunch of people selling variants, e.g. HP, Dell, etc), and figure out the protocol required to make it emit VGA data over the network interface. As well as how to send keystrokes, obviously.

        1. According to the TrippLite engineers, this Minicom dongle simply emits analog RGB over 3 pairs of the Ethernet cable, and use the 4th for keyboard and mouse events. So it is still a pure analog device, and not useful as a solution for this purpose.

        2. An interesting challenge here is the PRU’s limited bandwidth for digitization. During my previous experiments using the PRU as a logic analyzer (http://hacks.pmf.io/2015/04/03/the-beaglebone-black-as-a-logic-analyzer/), I got about 7 million 8 bit samples/sec. I estimated that I could double that with a more complex architecture that uses both PRUs in series.

          The limiting factor is the bandwidth between the PRU and the main memory of the BeagleBone. The PRU has very fast access to a small amount of memory dedicated to to it, but access to the bulk of memory, essential to digitize lots of data, is slow.

          So for full framerates, I don’t believe it’s feasible to go much higher than 320×240, 16 bit color, 60 Hz with the PRU. However, by capturing at lower frame rates, it should be possible to go up to high resolutions. For instance, 1024×768, 24 bit color might yield about 5 fps.

          1. I think the real problem with this approach is that the PRU operates at a fixed frequency, specifically 200MHz. The only way to realistically use the PRU to capture video is then to make sure that the input data is generated at a factor of that frequency, where the factor is such that the PRU has enough cycles to capture the data. e.g. make the video card emit data at precisely 100MHz. I dunno if it is possible to create a useful video mode that uses that output frequency.

            My latest thinking is to interface a suitable A/D convertor to a webcam controller chip, and have it present the video as a UVC device, or alternatively, to an IP camera SoC. I see no reason why that should not work (so far!)

Leave a Reply

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