HonkeyKong.Org

Making the world a better place, 8 bits at a time.

[honkeykong]

Introducing KindleShelf: A Better Way to Browse Jellyfin Books on a Kindle

I recently found myself trying to solve a problem that probably affects a fairly small group of people: I wanted a convenient way to browse and download books from my Jellyfin library using the web browser built into an e-ink Kindle.

Jellyfin already handles my book collection through the Bookshelf plugin, but its normal web interface was never designed for the Kindle’s limited experimental browser. Modern web applications tend to depend heavily on JavaScript, dynamic interfaces, large images, and browser features that older or lower-powered devices either handle poorly or do not support at all.

That led me to create KindleShelf.

KindleShelf is a small, self-hosted web frontend for Jellyfin book libraries. It runs alongside Jellyfin and provides a deliberately simple interface for browsing, searching, inspecting, and downloading books from an e-ink Kindle.

The project is available on GitHub:

GitHub - HonkeyKong/KindleShelf: Lightweight web frontend for downloading Jellyfin Bookshelf books from your Kindle.

Lightweight web frontend for downloading Jellyfin Bookshelf books from your Kindle. - HonkeyKong/KindleShelf

Built for a Limited Browser

The Kindle browser is not exactly known for being fast or standards-complete. Instead of fighting against those limitations, KindleShelf embraces them.

Pages are rendered as straightforward HTML on the server. Navigation, sorting, searching, and pagination all use ordinary links and forms. JavaScript is not required, and even images can be disabled without making the interface unusable.

Book covers are requested at a maximum width of 120 pixels, keeping pages lightweight and more appropriate for an e-ink display.

The result is intentionally plain, but that is the point. KindleShelf is designed to remain usable on hardware that struggles with the average modern website.

Jellyfin Remains the Source of Truth

KindleShelf does not maintain a separate book database or require another copy of the library.

It connects to an existing Jellyfin server and reads the Books library managed by the Jellyfin Bookshelf plugin. Metadata, authors, covers, available formats, and downloads all come from Jellyfin.

KindleShelf currently recognizes common book and archive formats including:

EPUB

AZW and AZW3

MOBI

PDF

CBZ and CBR

ZIP, RAR, and 7Z

Actual availability depends on what Jellyfin and the Bookshelf plugin report for each item.

Because KindleShelf is read-only, it stays focused on its primary job: making an existing library accessible from a Kindle.

Keeping the Jellyfin API Key Off the Kindle

One of my main design requirements was that the Kindle should never receive the Jellyfin API key.

The browser communicates only with KindleShelf. KindleShelf then makes the necessary requests to Jellyfin from the server side.

That keeps the API key out of page source, browser history, bookmarks, and download URLs. The application also validates Jellyfin item identifiers and confirms that requested books belong to the configured library rather than accepting arbitrary file paths or upstream URLs.

For a basic trusted home network, KindleShelf can operate without a login. It can also be protected with HTTP Basic Authentication.

For a better multi-user setup, it supports Jellyfin Quick Connect.

Signing In with Jellyfin Quick Connect

Typing a long username and password through a Kindle browser would be miserable, so Quick Connect is a much better fit.

When Quick Connect authentication is enabled, KindleShelf displays a short authorization code. The user enters that code from another browser or Jellyfin application where they are already signed in, then returns to the Kindle and checks the authorization.

KindleShelf never receives the user’s Jellyfin password.

The resulting Jellyfin token is stored in a bounded, server-side, in-memory session. The Kindle receives only a random HTTP-only session cookie. Browsing, covers, and downloads then use that user’s own Jellyfin permissions.

This also means different users can access the same KindleShelf installation without exposing the entire book library to everyone who can reach it.

Downloading Without Loading the Entire Book into Memory

Book downloads are streamed through KindleShelf rather than being completely buffered by the application.

KindleShelf can forward safe HTTP range requests and preserve Jellyfin’s partial-content and file-size headers. This matters for larger books and for devices or browsers that may resume or request only part of a file.

Format support still varies between Kindle models. EPUB and Amazon-compatible formats are generally the best options, but KindleShelf presents whatever compatible files Jellyfin reports.

Easy to Self-Host

KindleShelf is written in Python and can be run directly during development, but Docker Compose is the intended deployment method.

The basic setup consists of providing:

The Jellyfin server URL

A Jellyfin API key

The name of the Books library

Then the service can be built and started with Docker Compose.

No persistent application volume is required. KindleShelf uses a bounded in-memory cache for metadata and covers, while Jellyfin remains responsible for the actual library.

It can connect to Jellyfin over a shared Docker network, through the host machine, or elsewhere on the local network.

Designed for Home Servers

My own use case is a self-hosted media environment, so KindleShelf is designed with that kind of deployment in mind.

A simple trusted-LAN installation can be exposed over local HTTP, which may be necessary for older Kindles that cannot negotiate modern TLS configurations.

For access beyond the local network, KindleShelf should be placed behind a reverse proxy with HTTPS and authentication. A VPN or network allow-list is also a sensible option.

I would strongly advise against weakening the TLS configuration of an otherwise secure public server solely to support an old Kindle browser. A separate, carefully isolated compatibility endpoint is a much safer approach.

What KindleShelf Is Not

KindleShelf is not intended to replace Jellyfin, Calibre, or a full ebook management platform.

It does not currently edit metadata, upload books, track reading progress, or perform library management. Its interface is intentionally narrow and read-only.

That limited scope helps keep the project small, predictable, and usable on the devices it targets.

Future Send-to-Kindle Support

One obvious future feature is the ability to send a selected book through Amazon’s Send to Kindle service.

That functionality is not implemented yet, but the project already includes an extension point for a future delivery service. A complete implementation could eventually support:

SMTP delivery

Per-user Send to Kindle addresses

Approved-sender configuration

Format conversion through Calibre

Delivery history

Duplicate-send prevention

For now, books are downloaded through the browser, but the architecture leaves room for a more convenient delivery workflow later.

Why Build Something This Specific?

KindleShelf is admittedly a niche project.

It exists at the intersection of self-hosting, Jellyfin, ebooks, and aging e-ink hardware. That is also what made it interesting to build.

Modern software often abandons older or less capable devices long before the hardware stops being useful. A Kindle is still an excellent reading device, even when its browser can't cope with modern web applications.

Sometimes the right solution is not to replace the hardware. It is to build a smaller, simpler interface that respects its limitations.

That is what KindleShelf is meant to be: a lightweight bridge between a modern self-hosted book library and a device that is still very good at its primary job: reading books.

[honkeykong]

Introducing QuickType: Text and Emoji Buttons for OpenDeck

I’ve released a new OpenDeck plugin called QuickType.

QuickType lets you assign text, emoji, Unicode symbols, or short reusable snippets to buttons on an OpenDeck-compatible device. Press the button, and the configured text is inserted into whichever application currently has keyboard focus.

My original reason for creating it was simple: I wanted a page of emoji buttons on my Stream Deck. Similar plugins already exist for the official Stream Deck software on Windows and macOS, but I use OpenDeck on Linux and couldn’t find an equivalent that did exactly what I wanted.

So I made one.

What QuickType Does

Each QuickType action has a configurable text field. That text can contain practically anything you may want to type with a single button press, including:

Emoji such as 😂, 🔥, or 👍

Unicode symbols

Frequently used phrases

Chat responses

Code fragments

Commands or other short text snippets

Add the Insert Text action to a button, enter the text you want, and press the button while a text field is focused.

QuickType is designed primarily for Linux and OpenDeck. I haven’t focused on Windows or macOS compatibility because those platforms already have mature alternatives available through the official Stream Deck ecosystem.

Linux Input Support

Linux makes global text insertion slightly more complicated because the available method depends on whether the desktop is running X11 or Wayland.

QuickType supports several backends:

wtype for compatible Wayland compositors

xdotool for X11

ydotool as a broader Linux input fallback

wl-clipboard support for reliably inserting emoji and other non-ASCII text on GNOME Wayland

The plugin can automatically select an installed backend, or you can choose one manually in the button’s settings.

GNOME and KDE Wayland sessions impose additional restrictions on synthetic keyboard input, so some systems may require ydotoold, access to /dev/uinput, or approval of a desktop control permission prompt.

Installation

First, install a text-input backend suitable for your desktop environment.

For X11:sudo apt install xdotool

For wlroots-based Wayland compositors:sudo apt install wtype

For GNOME or KDE Wayland:sudo apt install ydotool wl-clipboard

Then:

Download or clone the QuickType repository.

Make text_inserter.py executable.

Open OpenDeck’s settings.

Click Open config directory.

Copy or symlink the org.honkeykong.QuickType.sdPlugin directory into the OpenDeck plugins directory.

Restart OpenDeck.

Add QuickType → Insert Text to a button.

Configure the text and input backend in the property inspector.

The source code and full installation notes are available on GitHub:

GitHub - HonkeyKong/QuickType: Insert text, emoji, and Unicode symbols into the active application with a single button press.

Insert text, emoji, and Unicode symbols into the active application with a single button press. - HonkeyKong/QuickType

QuickType is open source, so bug reports, testing results, and contributions are welcome—especially from people using different Linux desktop environments and Wayland compositors.

[honkeykong]

GlowBridge: A Lightweight, Open Ambilight Alternative Using WLED

For a long time I’ve wanted a clean, low-latency way to drive ambient LEDs from HDMI video without relying on heavyweight desktop software, proprietary stacks, or fragile screen-capture hacks.

So I built GlowBridge.

GlowBridge is a small Python project that runs on Linux (tested primarily on Raspberry Pi) and does one thing well: capture video from a V4L2 device, sample the edges, and stream colors to WLED over UDP in realtime.

This is not meant to replace commercial Ambilight systems or full-featured PC software like SignalRGB. Instead, it’s designed for people who want something:

simple

predictable

low-latency

easy to customize

and built entirely from open tools

What GlowBridge Does

GlowBridge:

Captures HDMI video from a standard USB capture dongle (V4L2 / MJPEG)

Crops and downsamples frames aggressively for performance

Samples edge colors using small patch averages (not single pixels)

Suppresses shimmer in dark scenes

Detects scene cuts and allows faster transitions when needed

Smooths color changes to feel natural rather than twitchy

Sends colors directly to WLED using its UDP Realtime (DRGB) protocol

The result is a responsive, stable ambient lighting effect that feels “attached” to the image instead of lagging behind it.

No screen scraping. No GPU dependency. No Windows required.

Why Not Just Use SignalRGB / Hyperion / etc.?

Those tools are great — but they weren’t ideal for my setup.

In my case:

I wanted to remove the PC from the loop entirely

I didn’t want to fight GPU drivers, capture latency, or AVX requirements

I already had Raspberry Pi and ESP32 hardware

I wanted something I could tweak and tune line-by-line

GlowBridge runs happily on a Raspberry Pi and talks straight to WLED. Once it’s configured, it just… works.

Hardware Setup (Typical)

GlowBridge doesn’t require anything exotic:

Raspberry Pi (3 or newer works fine)

Cheap HDMI-to-USB capture dongle (UVC compliant)

ESP32 running WLED

WS281x LED strip (layout is configurable)

Decent power supply for the LEDs

Everything here is inexpensive and widely available. I've also tested the software on a Raspberry Pi Zero 2 W and Orange Pi 800, and I got good results with both.

Current Status

This is not v1.0.

GlowBridge is best described as:

Public alpha, feature-complete for its intended use case

It works well, it’s stable in daily use, and it’s already replaced other solutions in my setup — but there’s still room for:

cleaner configuration

more layout options

better documentation

feedback from other setups I don’t have access to

That’s exactly why I’m open-sourcing it now.

Who This Is For

GlowBridge is probably a good fit if you:

already use WLED

are comfortable editing config files

want ambient lighting for consoles, set-top boxes, or PCs

prefer simple systems over massive frameworks

enjoy tinkering and tuning

If you want a polished GUI, cloud sync, or per-game profiles — this probably isn’t it (yet).

Get It Here

The project lives on GitHub:

👉 GitHub - HonkeyKong/GlowBridge: WLED + Raspberry Pi Ambient TV Lighting System

The README includes:

setup instructions

configuration options

test modes for LED mapping

a systemd service example

If you try it, break it, or improve it — I’d love to hear about it.

[honkeykong]

Connecting a MiSTer FPGA to an iiRcade Cabinet with the GRS Viper KVM Switcher (Step‑by‑Step)

I’ve always loved tinkering with arcade games, from my childhood, to my teenage years when my mom operated an arcade, and beyond. So, when the idea came up to connect my MiSTer FPGA setup to my iiRcade cabinet, I had to make it happen. The solution ended up being the GRS Viper KVM switcher, and here’s exactly how I wired it and configured MiSTer so you can replicate it.

Why Do This?

The iiRcade cabinet is great, but I wanted flexibility. The MiSTer opens up a massive library of classic arcade and console cores, and with the Viper KVM I can switch between the iiRcade’s stock system and the MiSTer with the press of a button. No unplugging cables, no mess, just seamless switching.

What You’ll Need

DE10‑Nano + SDRAM add‑on (MiSTer). The USB hub and I/O board aren’t strictly necessary, but they don’t hurt.

iiRcade cabinet

GRS Viper KVM switcher (handles video, controls, and audio routing)

HDMI cable (keep it short for tidiness)

USB‑A ⇄ USB‑C cable (for controls via the KVM's USB‑C Input B)

Optional: Keyboard for initial MiSTer configuration

Optional: Ethernet if you’re using a NAS (I use RetroNAS)

Power: I use a Raspberry Pi 3B+ PSU with an inline switch (micro‑USB) and a micro‑USB→DC barrel converter. You could pull 5V from the KVM with a buck converter (12/24V→5V) to keep it self‑contained, but I stuck with a known‑good supply.

Wiring Overview (TL;DR)

HDMI (video): MiSTer HDMI → KVM HDMI Input B

USB (controls + internal hub): MiSTer USB‑A → KVM USB‑C Input B (this attaches joysticks, buttons, trackball, and spinners to MiSTer)

Power: MiSTer powered by external PSU; KVM powered per its install guide

Step 1: Mount & Place Hardware

Mount the Viper KVM where you can reach the switch but it won’t snag wires.

Tuck the MiSTer somewhere with airflow.

(Optional) Route an Ethernet cable into the cab if you’re using RetroNAS or want easy updates.

Yep, this is what the KVM board looks like.

Step 2: Connect Video

Run MiSTer HDMI → KVM HDMI Input B.

Ensure the KVM's LVDS harness is seated and going to the iiRcade display as per the KVM's instructions.

Don’t worry about scaling yet, we’ll set MiSTer to the iiRcade panel’s sweet spot in software.

HDMI from MiSTer connected to Viper KVM

Step 3: Hook Up Controls

The iiRcade panel is GPIO internally, but the Viper KVM includes a USB encoder that exposes the sticks/buttons as an Xbox 360 (XInput) controller.

Run MiSTer USB‑A → KVM USB‑C Input B.

That single cable attaches the internal hub (sticks, buttons, trackball, spinners) to MiSTer.

We’ll tweak MiSTer so it treats the two sticks as separate pads instead of a merged controller.

Disconnect the USB-C cable from KVM Input B and connect your MiSTer as shown.

If all went well, you should have something like this now.

Step 4: Software (MiSTer.ini)

This is where it all comes together. We’ll set the panel’s resolution, un‑merge the two gamepads, and (optionally) make the panel’s volume buttons work in XInput mode.

4.1 Set the iiRcade Panel Resolution

The iiRcade’s panel is happiest at 1280×1024 @ 60 Hz. In MiSTer.ini:

; 1280x1024 @ 60 Hz video_mode=4

Tips:

If you see scaling quirks, verify your core’s video settings aren’t forcing a different mode.

After saving, reboot MiSTer to apply.

4.2 Treat Both Sticks as Separate Controllers

By default, the KVM's encoder can present both control halves under a single VID/PID (merged). Tell MiSTer not to merge these so each side becomes its own pad:

; Prevent merging of the two XInput pads from the KVM encoder no_merge_vid=0x045E no_merge_pid=0x028E

After this change, reboot so MiSTer re‑enumerates devices.

4.3 Make Volume Buttons Work in XInput Mode (Optional but Recommended)

In XInput mode, the iiRcade panel’s volume keys don’t emit standard keyboard scancodes; they show up as analog axes. I patched MiSTer to add INI keys that let us bind these to volume up/down without breaking other 360 pads.

Add this block to MiSTer.ini:

; Some arcade panels expose volume through analog axes (XInput). ; Enable per‑device mapping by VID/PID and chosen axes. ; GRS Viper KVM (Xbox 360 encoder): volume_abs_vid=0x045E volume_abs_pid=0x028E volume_abs_down=2 volume_abs_up=5

This requires a MiSTer build that includes my patch. PR: https://github.com/MiSTer-devel/Main_MiSTer/pull/1029 If you’re on a stock build without this patch, you can still adjust volume via the OSD or map alternative keys, but this makes the panel’s dedicated buttons work like they should.

EDIT: This part isn't necessary. The MiSTer dev doesn't want this cluttering up the main release, apparently we give this controller "too much attentions". So, I forked it with a patch specifically for this deck.

Step 5: First Boot & Input Mapping

Turn on the MiSTer before powering the iiRcade cabinet. I recommend this because the KVM will backfeed 5V power through the HDMI port to the MiSTer, and this minimizes the risk of hardware damage.

Open the OSD (F12 or the MiSTer button) → Define joystick buttons and walk through binding for Player 1 and Player 2.

Test: Trackball/spinners should enumerate as separate HID axes through the same hub.

If either stick doesn’t show up: re‑seat the USB‑C cable, confirm no_merge_* is in place, and unplug/re‑plug so MiSTer re‑scans USB.

Step 6: (Optional) Network Storage with RetroNAS

I use RetroNAS to serve my cores/ROMs/artwork centrally. On MiSTer, enable CIFS/SMB and mount your shares. Keeping everything on the network simplifies updates and keeps the SD card clean.

Troubleshooting

No picture / wrong aspect: Double‑check video_mode=4 and that the HDMI is on Input B. Reboot after INI edits.

Only one controller detected: Ensure no_merge_vid/pid are set and match 0x045E/0x028E. Power‑cycle MiSTer.

Volume buttons don’t work: Confirm you’re running a build with the volume button patch.

Lag or jitter on spinners/trackball: Use a short, good‑quality USB‑C cable for Input B; avoid cheap hubs between MiSTer and the KVM.

How It Plays

Honestly, it feels like the MiSTer was meant to live in the iiRcade. The controls map over beautifully, video is crisp, and audio is solid. One moment I’m playing the iiRcade’s native library, the next I’m deep into arcade‑perfect classics on the MiSTer.

Final Thoughts

If you’ve got an iiRcade and a MiSTer sitting around, the GRS Viper KVM is hands‑down the cleanest way to bring them together. It isn’t complicated, and once you’ve got it set up, you’ll wonder why you didn’t do it sooner.

Appendix: Full MiSTer.ini Snippet (copy/paste)

; === iiRcade + GRS Viper KVM === video_mode=4 ; Treat both sticks as separate pads (don’t merge the Xbox 360 VID/PID) no_merge_vid=0x045E no_merge_pid=0x028E ; Optional: map iiRcade panel volume axes in XInput mode (requires patched Main_MiSTer) volume_abs_vid=0x045E volume_abs_pid=0x028E volume_abs_down=2 volume_abs_up=5

EDIT: Forget the volume_abs_* parts. Apparently this is "too niche" for a "poorly designed" controller that "didn't even succeed its kickstarter". Soooo... Here's a fork with hardcoded PID/VID for the deck. UPDATE: I mentioned previously that it would be possible to power the MiSTer internally using a buck converter, but opted not to at the time for simplicity's sake. Yesterday I decided I wanted to do something about this, so I constructed a power cable from a pair of male and female DC power connectors and an LM2596 Buck Converter.

I then connected a DC power splitter to the cable going into the iiRcade motherboard, with one end going to the iiRcade mobo, and the other end to this cable and into the MiSTer. The results so far have been just as I expected, it's been running all day yesterday and all night last night with no problems.

[honkeykong]

JavaScript Jive This is one I started work on a month or so ago and forgot about until today, so I decided to give it an intro and outro. I may revisit and refine it later.

[honkeykong]

Segfault Slam

Here's a song I threw together with Udio a few months back. I've been considering making a full album of songs like this, talking about things like common programming errors and such. So far I have two songs, the other is coming next. This one's my favorite though.

[honkeykong]

Honkey Pong Future

A couple of weeks ago I received the GRS Ultimate Control Deck for iiRcade, and after testing performance with the original Pong, I was severely disappointed. So, I did what I always do when some software disappoints me. I wrote my own! I figured it was about time I tried writing a modern version of Honkey Pong that used SDL2, and this was as good of an excuse as any. It was designed around the spinners on the GRS control deck, but any USB spinners should work. If you don't have spinners, don't worry. The game supports the standard iiRcade joysticks as well. As a happy side effect to producing this game for iiRcade, despite being a dead platform, is that it was extremely easy to bring it over to Android, for all your pirate emulation boxes and such. I also have a Linux version that I'm tweaking (that's how I did most of my testing during development), and if I have the patience, I may try again at a Windows port. Who knows what the future holds for this game? (No pun intended) Download the game here.

[honkeykong]

Honkey Pong Redux

As some of you know, one thing I’ve always wanted to do is take my stupid games and put them on physical cartridges. I first tried this years ago with the original Honkey Pong, but didn’t get far with the Chinese manufacturers. 

Recently, I decided to try again, and again got the run-around from manufacturers in China. The ones I could find were ridiculously expensive, and come to find out, it’s because most of the NES carts sold on global marketplaces are cheap Famicom boards with a 72-pin adapter included.

Anyway, after a bit of debating, I decided to make the initial investment and start producing cartridges myself. Thanks to Muramasa Entertainment, I was able to get my hands on some new blank NES cartridge PCBs, and after more run-around from China, some EPROMs.

I knew if I was going to produce and sell a run of cartridges, I couldn’t get away with the old, crappy Honkey Pong, so I cleaned up Honkey Pong Redux for release. I’m posting both the 1.0 and 1.1 versions of the ROM that I put on the carts, but really there’s little difference between the two.

The code for 1.0 and 1.1 is identical with the exception of the arrangement of the ROM. 1.0 was designed for the NROM-256 board configuration, but I was only shipped two 32K EPROMs and a dozen 16K EPROMs which I’d planned on using for CHR ROM.

1.1 has all the features and code of 1.0, but packed down into 16 kilobytes of space to fit on a 27C128 EPROM. Nothing ripped, nothing removed, just removing a few .advance directives that I used to separate PRG pages.

If you’ve read this far, I’m assuming you’re actually interested in playing this stupid little game I made and would like to download the ROM. Well, here are the ROMs.

Honkey Pong Redux v1.0

Honkey Pong Redux v1.1

Edit: I forgot to mention, the source code for this release is available in the  examples folder of my libKong repository.

[honkeykong]

So, if I were to produce a run of Honkey Pong Redux cartridges, who would be interested in purchasing one?

[honkeykong]

When someone notices you're doing well, and they choose to remind you of your past mistakes, just remind them that the proper term for that is Personal Growth.

[honkeykong]

Hey, look! Another stupid game!

The title pretty much summarizes it. I’ve been playing around with the PICO-8 Fantasy Console lately, and decided to try making a game for it. This was the result. I may make more later if I feel like I can.

[endofeva1997]

Smash mouth has a song about a guy realizing the girl he’s dating is still in love with her ex girlfriend and he encourages said ex to come back and rekindle their lesbian romance

[endofeva1997]

[thefingerfuckingfemalefury]

Maybe the real All Star was the bisexuals we met along the way

[animar-seal-of-elephants]

this is like… the exact opposite of Jolene

[honkeykong]

The fact that this is seen as some kind of revelation boggles my fucking mind. Did people buy their album Fush Yu Mang and only listen to Walking on the Sun?

FLO IS LITERALLY THE FIRST TRACK ON A DOUBLE PLATINUM ALBUM. HOW DID EVERYONE MISS THIS?!

Also, I just have to say this: I wish Smash Mouth would ignore label pressure and go back to their punk rock roots like they wanted to.

</rant>

[weirdlandtv]

Concept and manual art for 1986 Nintendo game, METROID.

[30-minute-memes]

Happy birthday Minecraft

[30-minute-memes]

IT chapter 2 leaked footage

[we-love-gaming]

Trooo

[honkeykong]

I've been saying this for years. It's nice to see I'm not the only one who shares this sentiment.

[ntip]

[honkeykong]

I'm totally fine with my kid being punk. I was a punk when I was her age. Now I'm just a crippled punk with short hair. 😂