Salvaging a broken KVM switch using a Teensy device


...or: what to do on new year's eve afternoon?

In the days after Christmas of 2023 I finally managed to reorganize my home office setup into a decent workplace environment. This in itself might be worth a blog post. While doing this, something really bad happened: I broke one of my KVM switches by accident. My working environment employs two KVM switches with each connected to one monitor, and a total of 6 computers that are somehow connected to these KVMs. One KVM switch, which is not the one I destroyed, is an 8 port switch with analog video signal (i.e. VGA) which all of those 6 machines are using for analog video output. This KVM is connected to one of my two workplace monitors via VGA. The other one (the one I broke), a 4 port switch, uses digital video (i.e. DVI) and is connected to the other monitor via DVI.  So only the four most decent of those 6 computers are connected to this KVM switch, so these four out of six computers can be run in a multimonitor setup and the other two ones, which are rarely used and sort of vintage, are run in a single monitor setup using only analog video output via the 8 port switch.


So, what exactly is a KVM switch?

In case you don't know: KVM is an acronym for "Keyboard-Video-Mouse". A KVM switch is a device that allows to connect multiple computers with their video output and their keyboard and mouse input to exactly one monitor, keyboard and mouse. For a dual monitor setup, you need two KVM switches with one of them switching keyboard and mouse in addition to the video signal. KVM switches allow you to switch channels or ports so different computers attached to the switch can be made the ones whose video output is shown on the monitor and that receive keyboard or mouse input.


What has happened?

For some reason, I virtually managed to physically destroy the push buttons at the front of the 4 port KVM. Maybe the KVM was leaning with the front side turned down and two much pressure broke the push buttons. The next image shows how this KVM looks like:


The broken 4 port KVM switch

 So what can you do, if the push buttons of a KVM switch do not work anymore? I opened the case of the KVM and tried the push buttons without the case and soon realized that channels cannot be switched anymore using them, at least the push buttons for channel 1 and channel 2 were dead as nails. I reassembled the KVM and began to think: "Isn't there always a keyboard key combination that switches channels from a keyboard?". And yes Virginia, there is one for this KVM switch: You need to press Scroll Lock twice, followed by the enter key. So this shouldn't be a problem, right? Just hit Scroll Lock twice followed by the enter key once on the keyboard. Nope: My keyboard for all of those 6 machines is not connected to the 4 port switch, but instead to the 8 port switch, because otherwise the two vintage computers enjoy no keyboard support! So I quickly attached a small size USB keyboard to the 4 port switch and tried if I can use this in the interim for switching ports on the 4 port switch - and it worked. The next image shows this small keyboard hidden under one of the monitors:

The USB keyboard hidden under the analog monitor

 While this works, it is really cumbersome to always exactly hit scroll lock twice, followed by a single press of the enter key and it admittedly looks really ugly. A better solution had to be found...


Hang on, aren't there these Teensy devices and the foot pedals somewhere in a long forgotten box in a long forgotten drawer?

I remembered that something like 12 years ago or so, I bought a couple of Teensy devices and two foot pedals. At that time I used my first bunch of tablet devices running Windows 8 which I thought could make up good digital replacements for paper sheet music that I could use during rehearsals or gigs to demonstrate my uniqueness and technical avantgarde. The problem with having music sheet pages displayed on a tablet device while playing is this: You cannot switch forth and back between pages easily while using both hands to play your instrument, so my idea back then was to implement a USB keyboard with a Teensy device and two foot pedals which would send a Page-Up keystroke or a Page-Down keystroke when pressed. For some reason this project never came to life and I have long since disbanded the stupid idea of playing music from a computer screen. Paper based music sheets are so much more flexible after all.

What is a teensy device?

This is what such a teensy device looks like, in my case it is a quite out-of-date Teensy 2.0 device:

A Teensy 2.0 device

The Teensy has a mini USB port that is used both for programming it via the Arduino IDE and for its operational use when it is programmed to act as an HID (human input) device, namely as a USB keyboard. First of all I quickly soldered two pin header rows to the Teensy board in order to plug it into a breadboard, adding a 10 kOhm pull-up resistor and the foot pedal switch. This is how the breadboard design looks like:

The breadboard approach

 You can see that heavy-duty foot pedal switch to the right of the breadboard. The code I used to program the Teensy is pretty darn simple:



Bounce button0 = Bounce(PIN_D7, 10);

voidsetup() {
  pinMode(PIN_D7, INPUT_PULLUP); // Pushbutton



voidloop() {
  // put your main code here, to run repeatedly:

  if (button0.risingEdge())
    Serial.println("key pressed");


 The foot pedal switch  has its contacts closed when in its normal position, but opens the contact, if the pedal is pressed. So all the code does is detect the event when PIN_D7 is raised from GND (0V) to +5v DC via the 10 kOhm pull-up resistor and then it executes the function PressScrollLock twice and the function PressEnter once. Both functions do what their names suggest: They press and release their respective keyboard key with an arbitrary delay of 100ms inbetween. DISCLAIMER: I know I could optimize this code, it is not DRY, but that was not the point of this experiment.

Getting into production mode

Having this breadboard design was fine and after attaching it to the KVM it actually worked instantly, I could switch KVM channels via the foot pedal switch, hooray! But having a breadboard design on my desk was none the better than the interim approach using the small USB keyboard. So I quickly soldered the Teensy with its pin header rows and the pull-up resistor onto a somewhat larger hole-matrix board along with the connectors to the foot pedal. I chose an old DRAM package plastics case where everything would fit in quite neatly:

The final board with its case

 Some glueing later this piece of hardware looks like this:

The board glued into its case

Looks quite nice, doesn't it? But it only gets better: The complete device with the casing closed with the help of two wire straps looks like this:

The final product

Doesn't that look almost... professional?

 And as a final picture this one: it shows how the switch is sitting on my desk at the same position as the small USB keyboard before. Definitely an improvement and worth spending an otherwise boring new year eve's afternoon.

The working device under the analog monitor



Building OpenSSL 3.1.4 for Android with the MS Visual Studio 2022 native toolchain and cygwin

Building OpenSSL has gotten really easy these days and a lot of arcane things that I had to do to build version 1.1.x with cygwin and Visual Studio 2017 or version 1.0.2x are now a thing of the past. However, one thing I first had to do to build version  3.1.4 for android was updating cygwin to a more recent version than in the past, because  the old version I used before has some trouble using the configure script from version 3.1.x, most probably because the version of perl was too old. So I installed the most  current x64 version of cygwin at the time of writing  (3.4.9) into c:\cygwin64 and besides from a default install I added the following components  to the install:

automake, patch, perl, dos2unix, make, makedepend

You can download the full list of components in my cygwin installation here.

Since the build scripts for OpenSSL on Linux make heavy use of symbolic links for header files, you should also turn on "Developer Mode" on your build and development host (which should be Windows 10 10.0.15063 or later), otherwise the build scripts cannot be executed successfully by a standard user. From Windows 10 10.0.15063 on, symbolic links can be created on Windows machines without administrative permissions if the box is running in "Developer Mode".

In the following I assume that cygwin is installed into c:\cygwin64. In case your installation directory is different, set an environment variable named "CYGWIN_PATH" that points to your installation directory of cygwin prior to invocation of my build scripts, or edit the file named createcfg.bat among the script files in the zip for this article and set the value of "INTERNAL_CYGWIN_PATH" in this file to your cygwin installation path.

I further assume that the NDK that comes with Visual Studio 2022 is installed in c:\Microsoft\AndroidNDK\android-ndk-r23c. In case it is someplace else, set an environment variable named "OPENSSL_ANDROID_NDK_ROOT" that points to your NDK installation prior to invocation of my build scripts, or edit the file named createcfg.bat among the script files in the zip for this article and set the value of "INTERNAL_OPENSSL_ANDROID_NDK_ROOT" in this file to your NDK installation path.

In  order to build version 3.1.4 of OpenSSL for Android first download this zip file containing my scripts onto your Windows box with Visual Studio 2022 and the native Android build tools installed. Unpack the file into a directory and a subdirectory named "androidopenssl3.1.x" will be created. Open a command prompt and navigate into this directory. Now download version 3.1.4 of OpenSSL here (in case this link doesn't work, try this one which should point to the archive of old builds) and copy it into that directory as well.

After all that, run the build.bat batch file within the command prompt and sit back. On my Ryzen 5 5600X it takes something like 25 minutes to build the whole shebang. You will find 4 subdirectories (arm, arm64, x86 and x86_64) for the 4 supported processor architectures that each contain a directory with the name of the openssl file name (without the extension tar.gz, so in case of version 3.1.4 of OpenSSL this directory name is "openssl-3.1.4"). Within that directory you will find libssl.a and libcrypto.a built for the corresponding processor architecture.

In case you would want to build dynamic libraries as well, edit the file and remove "-no-shared" from the configure options.

And finally: If you want to build a newer version of OpenSSL than 3.1.4, download its tarball into the directory where you unpacked the build scripts and change the value of "OPENSSL_VERSION" in createcfg.bat from "openssl-3.1.4" to the name of your tarball (but without the extension ".tar.gz"). Do the same for "ANDROID_API" (which is set to the value 23 in my scripts) if you want to target a different Android API version than 23.

 The license for these shell scripts of mine is the same as for OpenSSL, so nothing should change for you.


Building OpenSSL 3.1.3 for iOS and iPadOS

In order to keep up-to-date I have  rewritten my scripts for an OpenSSL build for iOS/iPadOS. You can find them here and here. Download these files into an empty directory on your Mac and add a decent OpenSSL tarball into this  directory. After that execute

chmod +x

in this directory followed by


In case you want to build a newer or different version of OpenSSL 3.1x, edit and change the value for OPENSSLVERSION on line  4 which currently looks like this:


 Change this line to the file name of your tarball without the trailing .tar.gz extension.

I do not know if these scripts also work on an ARM based Mac, I am still working with an Intel based Mac running Mac OS Ventura with XCode  14.3.1. These scripts only build libraries for the two remaining processor architectures relevant for iOS/iPadOS today: x64 and arm64.

The license for these shell scripts of mine is the same as for OpenSSL, so nothing should change for you.


"True story, true story!"

There are two jazz musicians who are great buddies. They hang out and play together for years, virtually inseparable. Unfortunately, one of them is struck by a truck and killed. About a week later his friend wakes up in the middle of the night with a start because he can feel a presence in the room. He calls out, "Who's there?  Who's there?  What's going on?" "It's me  --Bob," replies a faraway voice. Excitedly he sits up in bed. "Bob!  Bob!  Is that you?  Where are you?" "Well," says the voice, "I'm in heaven now." "Heaven!  You're in heaven!  That's wonderful!  What's it like?" "It's great, man. I gotta tell you, I'm jamming up here every day. I'm playing with Bird, and 'Trane, and Count Basie drops in all the time! Man it is smokin'!" "Oh, wow!" says his friend. "That sounds fantastic, tell me more, tell me more!" "Let me put it this way," continues the voice. "There's good news and bad news. The good news is that these guys are in top form. I mean I have *never* heard them sound better. They are *wailing* up here." "The bad news is that God has this girlfriend that sings..."

Building OpenSSL 1.1.1 for Android on Windows with the Visual Studio 2017 native toolchain and cygwin


Disclaimer: The build scripts outlined in this post have been created in my own spare time. The license of the code is the same license as is used for OpenSSL.

A while ago I wrote about Building OpenSSL 1.0.2 for Android on Windows with Visual Studio 2017, and also how to build OpenSSL 1.1.1 for iOS/iPadOS. This time, I will show how to build OpenSSL 1.1.1 for Android on Windows with the Visual Studio 2017 native toolchain and cygwin.

The procedure outlined here produces actually working static or dynamic libraries and has the same prerequisites as in the article before on how to build version 1.0.2 of the libraries, but with one addition: The cygwin install will also require the installation of gnu make and patch.


Using the scripts

In order to use the scripts I have written, follow theses steps:

  • Make sure all preconditions are fulfilled, as described above (cygwin with make and patch) and in the article on building version 1.0.2
  • Unpack the zip File (Download) into a writable directory, make sure that you have the "Change permissions" right for the directory and all its files and subdirectories granted, otherwise the calls to chmod in the build scripts will fail (cygwin places some strange NULL SID ACEs into the DACL of files that are granted execution right using chmod which requires the "Change permissions" access right)
  • Download openssl-1.1.1l.tar.gz from (Download) and copy it into the directory created in the previous step.
  • Open a windows command prompt and change the current directory to the directory from the above steps
  • Execute "build.bat" and wait
  • Find the header files or the build under platform specific subdirectories like arch-x86, arch-arm in the subdirectory openssl-1.1.1l/include and find the libraries (libcrypto.a, libssl.a, and directly in the subdirectory openssl-1.1.1l.
If you need some more information on how the build scripts work, please refer to my article on building OpenSSL 1.0.2, the very same basic principles apply here as well. In case you want to build a newer version of OpenSSL than version  1.1.1.l, all you have to do is change the reference to the name of the openssl tarball in in the following line:
By default the build scripts only build the static libraries libcrypto.a and libssl.a. If you want to create the dynamic libaries as well (i.e. and locate the following lines in
# in order to build with dynamic libraries (i.e. and in addition to
# only libcrypto.a and libssl.a, remove the -no-shared flag from the following command line:
perl Configure $SSL_TARGET $OPTIONS $ADD_CFLAGS -I$NDK_PATH/sysroot/usr/include/$TRIBLE $ADD_LIB_FLAGS -no-shared
Follow the advise of the comment and remove the -no-shared flag, rebuild and you will also get the shared libraries.


:: Next >>

Free Blog Themes and Free Blog Templates