The AURGA Viewer Wireless KVM

As much as I love virtualizing machines in my homelab and putting the hardware as far away from my desk as possible, the truth of the matter is that there always comes a time when you need “physical” access to the host to deal with boot issues, change BIOS configurations and other types of housekeeping–and regular remote access just won’t cut it in those times.

In the server world you have IPMI and all sorts of network-based remote solutions for hardware management (often with dedicated Ethernet ports on the motherboard or management cards), but for home and small-office use you’re essentially out of luck, sometimes to the point where you’ll find yourself having to drive off into nowhere just for the sake of hitting F1 on a BIOS and changing a couple of settings.

But even with renewed interest in all sorts of remote access solutions over the past few years, consumer hardware just doesn’t include any of those features, and third-party solutions were still prohibitively expensive–it took a while until the PiKVM made remote management minimally affordable to homelab enthusiasts, and it looks like we’re finally getting some competition in the space.

Also, in a home or homelab setting you often can’t (or don’t want) to devote a dedicated Ethernet port to this kind of a solution.

Which is why, as a stopgap, I ended up building two minimalist Wi-Fi-only PiKVMs based on the aging Raspberry Pi Zero W over the past year, both using an outdated (and now unsupported) software version and my own case design.

They work OK (if sluggishly), but I’ve found myself wanting something better, and I was pleasantly surprised to stumble upon the AURGA Viewer one evening:

So I reached out to AURGA and they sent me a review unit, which I’ve been testing for the past couple of weeks.

Disclaimer: AURGA supplied me with a review unit free of charge, and as usual this post follows my review policy.

This sleek solution is an HDMI dongle that comes with a small set of accessories in the box:

Besides a USB-A to C cable, you get three HDMI adapters (female-to-female, mini-HDMI and micro-HDMI), which I found interesting since they are precisely the ones I use to do my single board computer reviews.

I wouldn’t mind getting a USB-C cable and a C to A adapter instead of the single cable, but that’s a minor quibble–I don’t honestly see the assumption that you’ll have available USB-A ports to be a problem.

When compared to my homebrew solution, the AURGA Viewer is quite shapely and more compact–and my devices are much smaller than a conventional PiKVM…

As you might have figured out by now, the USB cable provides the AURGA Viewer with both power and a USB HID connection to the host it’s controlling, so I spent a bit of time looking into the specifics.

In short, this is what dmesg reports on a Linux system:

[1225111.714545] usb 1-4: new full-speed USB device number 6 using xhci_hcd
[1225111.848487] usb 1-4: not running at top speed; connect to a high speed hub
[1225111.863806] usb 1-4: New USB device found, idVendor=5153, idProduct=0168, bcdDevice=20.03
[1225111.863821] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[1225111.863826] usb 1-4: Product: AURGA Keyboard/Mouse/Touchscreen
[1225111.863831] usb 1-4: Manufacturer: AURGA CO., LIMITED
[1225111.906899] input: AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen as /devices/pci0000:00/0000:00:08.1/0000:c6:00.3/usb1/1-4/1-4:1.0/0003:5153:0168.000D/input/input54
[1225111.959269] hid-generic 0003:5153:0168.000D: input,hidraw0: USB HID v1.01 Keyboard [AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen] on usb-0000:c6:00.3-4/input0
[1225111.967127] input: AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen as /devices/pci0000:00/0000:00:08.1/0000:c6:00.3/usb1/1-4/1-4:1.1/0003:5153:0168.000E/input/input55
[1225111.967623] hid-generic 0003:5153:0168.000E: input,hidraw1: USB HID v1.01 Mouse [AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen] on usb-0000:c6:00.3-4/input1
[1225111.981534] input: AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen as /devices/pci0000:00/0000:00:08.1/0000:c6:00.3/usb1/1-4/1-4:1.2/0003:5153:0168.000F/input/input56
[1225111.981992] input: AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen as /devices/pci0000:00/0000:00:08.1/0000:c6:00.3/usb1/1-4/1-4:1.2/0003:5153:0168.000F/input/input57
[1225111.982193] input: AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen Stylus as /devices/pci0000:00/0000:00:08.1/0000:c6:00.3/usb1/1-4/1-4:1.2/0003:5153:0168.000F/input/input58
[1225111.982853] hid-multitouch 0003:5153:0168.000F: input,hiddev96,hidraw2: USB HID v1.01 Device [AURGA CO., LIMITED AURGA Keyboard/Mouse/Touchscreen] on usb-0000:c6:00.3-4/input2

As you can see, the AURGA Viewer reports itself as supporting keyboard, mouse and touchscreen/stylus input–and you can even configure whether the device will use HID 1.1 or HID 2.0 mode (which is required for multi-touch on Windows 10 devices).

However, it does not emulate gamepads (which means no remote gaming, at least not with remote controllers), or storage devices (so no ability to boot a remote machine off a diagnostic ISO, like I can do with my current PiKVMs).

As to HDMI/EDID negotiation, the device reports a maximum of 1920x1080@60Hz–but, interestingly, it also reports support for many more smaller resolutions (including old-time classic 4:3 ones like 832x624) and refresh rates down to 29.97Hz, which should cover a lot of what you might find if, for instance, you need to plug this into an older machine through a composite-to-HDMI or VGA-to-HDMI adapter.

I happen to have a couple of those adapters, but the machines I used them with have been gone for a while, so I couldn’t really test this.

As the usual multi-language instruction booklet in the box readily will tell you, there isn’t a lot you can do with the device itself–there’s a tiny reset hole and a multi-color LED for status, but the first step is to plug it in to a USB-A port on your host device.

This is a key departure from a PiKVM–you (currently) don’t have a browser-based way to setup the device or access your host machines, and have to use the AURGA client applications for everything, so I spent a good while trying most of them out.

The setup process is pretty straightforward–install the app, have it look for the AURGA Viewer’s Bluetooth beacon, and then try to connect to the device’s Wi-Fi hotspot (which failed for me the first time):

Once I finally connected to it, I told it how to connect to my network and did a firmware upgrade:

Finally, it “just worked” and showed me the server console (tapping the little square on the corner of the image goes full-screen), as well as some guidance on control gestures:

Like I mentioned before, you can then decide whether you want to enable HID 2.0 touchscreen mode–as well as connect the AURGA Viewer to cloud services, etc.

I spent most of my time trying to use the iOS client on my iPhone, iPad and Mac, and I have to say that the user experience was a bit uneven–video rendering and input response times were excellent (more on that later), but I had a few problems:

• I just couldn’t get input to work reliably on my freshly-updated Macs (which are running macOS Sequoia). I granted full keyboard input permissions, restarted the app, etc., but only mouse input worked consistently.
• I could type in just fine on the iPad, but (and this might also be due to iOS 18.0 updates) dismissing the on-screen keyboard didn’t restore the full screen view.
• The iOS app crashed every now and then when I was trying to reconfigure the device (add it to the AURGA cloud services, change settings, etc.)

The reason I was quick to mention Sequoia as a (hopefully temporary) incompatibility factor is that on the very first day I did an outlier test: I got out an old Intel MacBook running Monterey (12.7.6) and had zero issues getting the desktop app off the App Store and connected in under a minute.

In a refreshing turn of events, the desktop app has a very prominent “Skip for now” button when you’re prompted to login to AURGA’s cloud services, so I could just move on with my life and pick out the device on the LAN.

I should point out that I had very little opportunity (or reason) to use the Linux or Windows clients, but the fact that there even is a Linux app is worthy of note–it worked fine and is available for Intel (both as a Debian package and a tar.gz with the binaries and dependencies). You can get it from Github and file issues directly, but it is closed source.

I just unpacked the tar.gz archive into my Fedora laptop, fired it up and… it looked and worked exactly like the Mac and Windows ones.

Note: I did have a couple of minor issues with input handling, but as I went to add the GitHub link to my final draft, I saw that those were apparently fixed by a new release three days ago.

For kicks (and since the packaging actually said the AURGA Viewer was usable from a VR headset), I side-loaded the .apk that AURGA makes available on their website into my Quest 2 and… It nominally worked.

I say “nominally” because I didn’t have a keyboard or mouse configured on the Quest 2 and you can’t really do much with the controllers, but the application ran, connected to the device without any issues, and streaming worked fine, even when multitasking with the new Quest 2 multi-window experience:

I also installed the application on my Logitech G Cloud (which is the closest thing I have to a modern Android tablet) and it worked as expected, with the added bonus that the G Cloud’s software automatically maps some of the game pad inputs to movement keys–but, again, the AURGA Viewer does not support game pad emulation.

However, I spent a lot more time trying different host devices off the beaten track.

The very first device I plugged the AURGA Viewer into was the Geniatech XPI-3566-Zero that I was starting to test at the time, and that didn’t want to provide enough USB power for the AURGA Viewer to work–which is fine, since most single-board computers (even some Raspberry Pi models) don’t expect a lot of power drain in their USB ports and often reboot when you plug more demanding devices in.

The Banana Pi M7 and a Raspberry Pi 4 had no such issues, and worked perfectly–so I suspect I will be using the AURGA Viewer for setting up my next review units.

Since I was quite impressed by the image quality and latency but wanted to test audio/video sync, I decided to try an unholy combination and plugged the AURGA Viewer into my Xiaomi Mi Stick 4K.

But since that required me to use a rather peculiar USB OTG hub and I couldn’t get the AURGA Viewer to work with it (I just couldn’t get input working), that was a bit of a bust.

But it was also a good reminder that HDMI-CEC support might be a good feature to add to the AURGA Viewer (it currently doesn’t supported that). So I moved to my NVIDIA Shield, since, as you might imagine, there was little point in testing this with an Apple TV…

Although an Android TV device isn’t really happy with mouse and keyboard input, things sort of worked and I was able to navigate applications and watch a few videos, although I didn’t try any of the major streaming apps (we use the Apple TV for those).

However, besides the input challenges, HDMI audio was choppy (even with all the devices within 5m of the same 5GHz access point), so I can’t really say it was a seamless TV viewing experience (or any real replacement to using streaming apps directly).

The reason you can see Hades in the picture above is that one of the machines the AURGA Viewer has spent the most time plugged into is my AceMagic AM18, which is currently dual-booting into Bazzite to act as a game streaming/emulation box, and is an excellent way to stress test any kind of remote KVM:

• I need to be able to reboot and pick the right boot volume to start the system with.
• I also need to tweak the BIOS iGPU settings to toggle between playing games and experimenting with ollama.
• I sometimes need to do these setup changes once or twice a day.
• I have also been trying several versions of Steam Link and Moonlight, and that means I need to input pairing codes on the console, use local GUIs, etc.

Plus games are an excellent way to test latency, and even without gamepad emulation, I was able to have the AURGA Viewer and Steam Link apps running at the same time on both my Mac and… the Quest 2, which made for an interesting experience.

Almost. AURGA claims interoperability with game consoles as a key part of their marketing material, so I had to try it even though I already expected it to be display-only given the lack of game pad input support.

And well, you can play PC games remotely from a Mac with a keyboard and mouse, but I found that there was a little more lag and stuttering than I would like, even when downgrading the streaming quality in the client app.

When streaming Hades with Steam Link and the AURGA Viewer app simultaneously to my Mac (which can handle both streams perfectly), there was some noticeable stuttering and pauses I wouldn’t tolerate in a fast paced game, and even then the latency might not be low enough for first-person shooters (at least not if you’re an old Quake hand like me)–however, that doesn’t mean you can’t use it for slower-paced games and stream a console like the Switch to your iPad, for instance.

This is a good moment to explain what the testing conditions looked like.

I have 5GHz 802.11n throughout the house (with five independent base stations connected via a minimum of 1Gbps) and consistently get over 300Mbps either way on every Wi-Fi device (with my Quest 2 reporting 530Mbps physical link speed).

And from a Wi-Fi coverage perspective the AURGA Viewer was in its Goldilocks zone–it was sitting 30cm away from one of the base stations, and most of the devices I connected from also had excellent coverage.

I did try to use a couple of 2.4GHz devices to access it, but didn’t notice any difference at any of the video quality settings, so I left it always on “Best” except when comparing it to the Steam Link.

And I must say the video and audio quality was very good–especially when compared to a PiKVM.

As to regular application use, given that I spend 80% of my working hours inside Remote Desktop services, I can say that everything I did through it was very snappy–on my home network.

This was a bit more challenging. In short, I couldn’t get the AURGA cloud service to work to access the device from a 5G network.

AURGA says remote access won’t work for “devices behind part of Restricted Cone NAT and Symmetric NAT.”, and that may be the case for me, but the attempts I made were nevertheless interesting.

Before trying it, and since the entirety of my entire remote access setup revolves around Tailscale and I didn’t want to create yet another cloud service account, I simply fired up Tailscale on my phone and opened AURGA Viewer, only to find that I couldn’t input an IP address to connect to.

I wasn’t expecting discovery to work, of course, but I found that odd, since the desktop app does have the option to input an IP address, so AURGA seems to assume that, on a mobile device, you will either always be on the same LAN as the device or using their redirection service.

This feels like an easy shortcoming to fix, but in this case it meant I had to register an account and try their cloud service.

This was kind of important, since later on I decided to actually create a login in the AURGA service, register the device on it, and try to access it via 5G on my phone–which didn’t work. I checked that everything was working on my LAN, switched off Wi-Fi (center shot), and…

Also, the iOS application crashed a few times in the process–I had to create my account on the desktop application.

As I was testing the AURGA Viewer, I took the opportunity to take some notes on the overall security approach (mostly the procedural part) and a bit of the networking aspects behind their cloud service.

After all, plugging something into hardware you (or your company) own is a sensitive matter, so I was happy to see that:

• There were no generic passwords or tokens (and you needed physical proximity to the device when setting it up).
• The device shut off Bluetooth and its own Wi-Fi hotspot once I connected it to my network.
• You get a confirmation code via e-mail that you need to input when you create or remove an AURGA account–which is a step above most of what I usually see in consumer-grade solutions.

As to cloud services and general outbound traffic, I saw that the login and account services are US-based:

…and that the app uses a number of public STUN services to do NAT traversal, including one in China:

I didn’t have time to do any packet sniffing¹ or see if there is any telemetry, but to be honest this is quite good as far as consumer solutions go these days.

I like it. I think The AURGA Viewer is a polished KVM device that brings the right kind of consumer-focused simplicity to setup and use, and is only let down by fast evolving software and the lack of a few features that more technical folk like me take for granted (like having a fallback web interface and enough storage to hold a mountable recovery ISO).

But most of those should be easily fixable–even if I have to review the status quo, I was always impressed by how quickly the remote display would show up on my phone immediately after launching the app.

And I attribute a lot of that to the hardware, which is is very nice. Video quality is one measure of it, but 5GHz Wi-Fi support is what makes it truly usable and snappy. An Ethernet port would always be desirable, but they’ve demonstrated to my satisfaction that (at least in a network like mine) it is clearly optional, and that also makes it easier for consumers and travel use (I never tested using the AURGA as a “second monitor” with a tablet, but yes, it will work fine).

As to remote connectivity, I hope AURGA will consider integrating with Tailscale as an alternative to their current STUN-based approach, or at least let me input an IP address on iOS.