So Daniel sent us this one, and it is a classic power-user conundrum. A listener has a Raspberry Pi currently driving a dashboard display, but since the Pi has two outputs, they want to use the second one for Kodi or a media center. The catch is they want a very reliable binding, maybe even a virtual machine bound to a specific output, so one Pi can drive two different display surfaces without them stepping on each other's toes.
Herman Poppleberry here, and man, this is such a great prompt because it hits that intersection of hardware capability versus software legacy. We have had dual micro-HDMI ports on the Pi since the Model Four, and now with the Pi Five, we actually have the horsepower to drive two four-K displays at sixty hertz. But the Linux display stack often acts like it only has one eye.
It is like having a car with two steering wheels but only one driver who refuses to sit in the middle. By the way, quick shout out to our sponsor, Modal, for the GPU credits, and a fun fact for the day: today’s episode is actually being powered by Google Gemini Three Flash. So, Herman, the listener mentioned a VM. Is that even a thing on a Pi? Can we actually pin a virtual machine to an HDMI port?
In a literal sense, yes, but it might be overkill. Using KVM, which stands for Kernel-based Virtual Machine, on a Raspberry Pi Five is surprisingly performant. You could technically run a guest OS and use what we call PCI passthrough or specialized Virt-I-O GPU drivers to map an output. However, the Pi’s Broadcom GPU, the VideoCore Seven, isn't a discrete card you can just "slice" in half easily for two different operating systems. Usually, when people ask for a VM in this context, what they’re really asking for is "isolation." They don't want the media center crashing and taking down the dashboard, or vice versa.
Well, not "exactly" as in the forbidden word, but you know what I mean. The fear is that "Kodi-itis" where the media center decides it’s the king of the castle, grabs the focus, and suddenly your dashboard is just a black screen or a giant mouse cursor. If we aren't doing a full VM, how do we trick the Pi into thinking it’s two separate computers?
There are three main ways to skin this cat. You’ve got the Native Windowed approach, the Separate X-Screens approach, and the Containerized path. Each one has a different "reliability" score.
Let’s start with the one most people probably try first and fail at. The native approach. Why is it harder than it looks to just drag a window to the second screen and hit "fullscreen"?
Because of how full-screen applications interact with the compositor. On the newer Raspberry Pi OS, which uses Wayland and a compositor called Wayfire, the system sees one giant "virtual desktop" spanning both monitors. When you tell an app like Kodi to go "Fullscreen," its internal logic often says, "I will now occupy the primary display at the highest priority." If your dashboard is on that primary display, it gets buried.
And if you move it to the second display, does Kodi just follow you like a needy puppy?
Often, yes. Or worse, it uses a feature called "blanking." In Kodi’s settings, there’s a notorious toggle called "Blank other displays." It’s designed to give you a "theatre experience" by turning off your other monitors so you aren't distracted by your desktop while watching a movie. For our listener, that would mean the dashboard goes dark the second they start a video.
That sounds like a nightmare for a "reliable" setup. So, if we stay native, we have to go into the Kodi System settings, hit Display, set it to "Windowed," move it to HDMI-one, and then toggle that blanking setting off. But is that "reliable"? If the Pi reboots, does it remember where it was?
Left to its own devices? No. It’ll probably boot up and stack both apps on HDMI-zero. This is where we get into the "secret sauce" of window rules. Since the Pi Five moved to Wayland, we use Wayfire configuration. You can actually write a rule in the wayfire.ini file that says: "Any window with the title 'Kodi' must be placed at coordinates nineteen-twenty by zero." If your first screen is ten-eighty-p, those coordinates force it onto the second screen instantly.
But wait, what if the dashboard browser launches before the window manager is fully ready? Could they still end up fighting for the same coordinate space?
That is the risk. You usually have to build in a "sleep" command in your startup script. You let the desktop environment breathe for five seconds, then launch the dashboard, wait another three, then launch Kodi. It feels a bit like building a house of cards, but with the Wayfire rules, the compositor acts as the enforcer. If Kodi tries to jump back to the first screen, the compositor essentially says, "No, your home is at nineteen-twenty, get back over there."
Okay, so that’s the "software-tweak" version. But the listener mentioned a VM. Let’s talk about that Separate X-Screens idea. That sounds more like the isolation they’re looking for.
This is the old-school "power user" way, and frankly, it’s the most robust if you can handle the setup. In the old X-eleven display system, you could define "Screen Zero" and "Screen One." These aren't just displays; they are entirely separate instances of the display server.
So if I move my mouse to the edge of Screen Zero, it doesn't just slide over to Screen One?
Not unless you specifically configure a mouse-sharing tool. They are islands. To the Pi, Screen Zero is at the address "colon-zero-dot-zero" and Screen One is "colon-zero-dot-one."
I love that. It’s like a digital Berlin Wall for your apps. So I could launch Chromium for my dashboard on display "colon-zero-dot-zero" and then launch Kodi on "colon-zero-dot-one," and Kodi literally cannot see the dashboard. It can’t blank it, it can’t overlap it, it doesn't even know it exists.
Precisely. It’s the closest you can get to a VM without the overhead. Think of it like a duplex apartment. They share the same foundation—the Linux kernel—but they have separate front doors, separate utilities, and the neighbors can't see what's on each other's TVs. The problem is that Raspberry Pi OS "Bookworm" and later versions use Wayland by default, and Wayland doesn't really do the "Separate X-Screens" thing in the same way. To get this working in twenty-twenty-six, you’d have to use raspi-config to force the system back to the legacy X-eleven backend.
Is that a bad move? Are we losing performance by ditching Wayland on a Pi Five?
You lose some of the hardware-accelerated window flicking and the smooth tearing-free desktop, but for a dedicated dual-surface appliance? It’s arguably more stable. If you’re running a kiosk dashboard on one side and a media player on the other, you aren't exactly doing a lot of "window management." You just want the pixels to stay where you put them.
Let’s talk about the hardware side for a second. The Pi has two micro-HDMI ports. Does it matter which one is which? I remember something about HDMI-zero being the "alpha" port.
It matters immensely. HDMI-zero is the port closest to the USB-C power input. During the boot process, the Pi’s firmware looks to HDMI-zero for the initial display signal. If you have your dashboard on HDMI-one and your media center on HDMI-zero, and the media center TV is off when you reboot, the Pi might get confused about which screen is the primary. Always put your "always-on" display, like the dashboard, on HDMI-zero.
That’s a pro tip. It’s the "anchor" for the whole system. Now, what about the "VM-ish" approach using containers? You mentioned Docker with display passthrough. How does that work without making the Pi sweat?
This is actually my favorite way to do this if you want that "clean" isolation without the overhead of a full Virtual Machine. You can run Kodi inside a Docker container. Now, normally, a container doesn't have a "screen." But you can map the hardware device nodes from the Linux kernel directly into that container. Specifically, you map /dev/dri/card-one which represents the second HDMI output’s rendering pipeline.
Wait, so the container thinks it has its own dedicated graphics card?
Functionally, yes. You give the container access to the Direct Rendering Infrastructure, or D.R.I., for the second port. Then, when Kodi starts up inside that container, it only sees one output. It thinks it’s the only app in the world. It can’t see the "host" OS running the dashboard on the first port.
That sounds like the "reliable binding" the listener is dreaming of. If Kodi hangs or the container crashes, your dashboard keeps humming along because the host OS is still in control of HDMI-zero. But how hard is that to set up? Mapping G.P.U. nodes into Docker sounds like a "Friday night ruined" kind of project.
It’s a bit of a climb. You have to deal with permissions, making sure the user inside the container has access to the "video" and "render" groups on the host. And you have to handle the sound—don't forget that HDMI carries audio. You’d need to map the specific ALSA or PulseAudio device for HDMI-one into the container as well. If you don't, you’ll have a beautiful movie playing in total silence.
Or worse, the movie audio starts playing out of the dashboard’s speakers and scares the life out of you.
Which is a very real possibility! But once it’s set up, it’s bulletproof. You can even set the container to "always restart," so if Kodi gets weird—which, let’s be honest, media centers sometimes do—it just reboots itself in the background while your dashboard stays perfectly static.
I want to circle back to the listener's mention of a VM. Let’s say they’re dead set on it. Maybe they want to run a completely different OS, like a specialized LibreELEC build, alongside their dashboard. Is there any world where Proxmox for ARM makes sense on a Pi Five?
It "makes sense" if you’re a hobbyist who loves the pain. Proxmox on the Pi Five is actually quite impressive. The Pi Five has four lanes of P.C.I. Express two-dot-zero, and the C.P.U. has decent virtualization extensions. But here’s the bottleneck: the G.P.U. virtualization. Most "standard" VMs use a virtual G.P.U. like virtio-gpu. That’s fine for a desktop, but it’s not great for four-K video decoding in Kodi.
Right, so you’d be asking the C.P.U. to do all the heavy lifting for the video decoding instead of the specialized hardware on the chip. Your Pi would turn into a very expensive space heater.
Literally. You’d see the "thermometer" icon on your screen within minutes. To make a VM work "reliably" for media, you need G.P.U. passthrough, and that is still the "holy grail" that is very difficult to achieve on single-board computers. The hardware just isn't designed with an I.O.M.M.U.—an Input-Output Memory Management Unit—that can cleanly separate the G.P.U. into independent chunks for different VMs.
So the consensus for the listener is: you probably don't want a VM, you want "Logical Isolation."
Use the Raspberry Pi Five. Use the official twenty-seven-watt power supply—because driving two screens and a G.P.U. workload will trigger under-voltage warnings on a standard phone charger—and then choose your level of "Linux wizardry."
If we’re talking about "reliability," we have to talk about what happens when things go wrong. What if one of the screens gets unplugged or the power cycles on the TV? In my experience, Linux loves to "helpfully" re-arrange all your windows onto the one remaining screen.
Oh, the "helpful" window manager. It’s the worst. You turn off the TV to go to bed, the Pi realizes the HDMI-one clock signal is gone, and it says, "Oh! Let me move this giant Kodi window over to your tiny dashboard screen for you!"
And then you wake up and your dashboard is gone, replaced by a frozen frame of Shrek. How do we stop that?
This is where udev rules and xrandr scripts come in. You can actually write a script that monitors the "hotplug" events of the HDMI ports. When it senses that HDMI-one has reconnected, it can automatically trigger a command to "re-bind" the apps. For example, you can use a tool called wlr-randr for Wayland or just plain xrandr for X-eleven to force the display mode back to what it should be.
But wait, how does a script know which window is which? If I have three Chromium windows open, how does it know the "Kitchen Dashboard" goes on the left and the "Weather Station" goes on the right?
You have to get surgical with window classes. Most browsers let you launch with a specific "app-id" or "class name." So you launch your dashboard with --class=Dashboard. Then your script looks for that specific class. It’s like putting a name tag on every guest at a party so the bouncer knows which room to shove them into when the power comes back on.
I’ve also seen people use "E.D.I.D. emulators." Those little fifteen-dollar HDMI plugs that ghost the signal so the Pi thinks the monitor is always on. Would that be a "hardware hack" for reliability?
It’s actually a very smart move for this specific use case. If you put an E.D.I.D. ghost between the Pi and the media center TV, the Pi will always see a "ten-eighty-p sixty-hertz" display, even if the TV is unplugged and thrown in a lake. It prevents the display stack from ever trying to re-calculate the desktop layout. It keeps the "binding" physically locked.
I love a good hardware solution to a software headache. It’s like putting a physical lock on a digital door. So, let’s break down the "Takeaways" for our listener. If you’re starting today, what’s the "Herman Poppleberry Recommended Path"?
Step one: Get a Raspberry Pi Five. Don't try this on a Three, and even the Four might struggle with four-K dashboarding plus media. Step two: Install the standard sixty-four-bit Raspberry Pi OS. Don't go for a specialized media OS like LibreELEC because they are designed to be "Just Enough OS" and they hate sharing the G.P.U. with a dashboard.
Step three: The display setup.
Use the Screen Configuration tool to set the displays to "Extended." Put the dashboard on HDMI-zero. Now, for the "Binding," I would actually recommend the Wayfire "Window Rules" approach. It’s the most modern. You open your wayfire.ini, you find the window-rules section, and you pin Chromium to one set of coordinates and Kodi to the other.
And then for the "Reliability" part?
Go into Kodi’s settings, turn off "Blank other displays," and set the display mode to "Windowed Fullscreen." That way, Kodi behaves like a good citizen on the desktop but still looks like a dedicated appliance. And if you really want to be pro? Use that E.D.I.D. emulator on the media center port so the Pi never feels the "heartbreak" of a disconnected TV.
What about the resource hit? Is a Pi Five going to scream if I’m running a heavy Chromium dashboard—you know how much RAM those things eat—and a high-bitrate video at the same time?
The Pi Five has a much better V.3.D. engine, but Chromium is a beast. If your dashboard is just a bunch of static charts, you’re fine. If it’s a bunch of live-streaming WebGL animations? You might see some dropped frames in Kodi. This is where you might want to look into "Kiosk" mode for Chromium, which strips away all the browser UI and reduces the overhead.
Does the RAM choice matter here? Should our listener go for the eight-gigabyte model, or can they get away with the four?
For dual-display 4K, I wouldn't touch anything less than the eight-gigabyte model. Video buffers, browser caches, and the Wayland compositor all want their slice of the pie. If you start swapping to the SD card because Chromium decided to eat three gigs of RAM, your video playback in Kodi will stutter every time the dashboard refreshes.
And maybe a little active cooling?
Oh, absolutely. If you’re driving two displays and a G.P.U., you need the Active Cooler. If that Pi hits eighty degrees Celsius, it will throttle the C.P.U. and G.P.U., and your "reliable" media center will suddenly start stuttering like an old scratched D.V.D.
I want to circle back to the "Kodi-itis" thing. What if they want to use a remote control? If Kodi is on the second screen, does the CEC—Consumer Electronics Control—still work? Can they use their TV remote to control the Pi?
Yes, but it can be finicky. CEC signals usually travel over the HDMI cable. The Pi Five supports CEC on both ports, but the Linux kernel has to know which "screen" the remote is talking to. Usually, Kodi is smart enough to grab the CEC device associated with its HDMI port. So you could actually have the dashboard on a non-interactive monitor and use your TV remote to navigate Kodi on the other, and they won't interfere. It’s actually a very slick setup once the CEC drivers are mapped correctly.
That really completes the "appliance" feel. One side is a passive data radiator, the other is an active entertainment hub. I think the listener’s idea of a VM was a search for "isolation," and we’ve shown that you can get ninety-nine percent of the way there with window rules and maybe some Docker containers if you’re feeling spicy. It’s really about knowing the quirks of the Linux display stack.
It really is. We’ve come a long way since the days when getting a second monitor to work on Linux required editing a text file for three hours and praying to the kernel gods. The Pi Five makes this a "one-afternoon" project rather than a "one-week" project.
One afternoon if you listen to Herman. Three weeks if you try to do it by yourself.
Hey, that’s why we’re here! I remember back in the Pi Two days, we were struggling just to get a single 720p video to play without tearing. Now we're talking about multi-seat, multi-display 4K environments on a board the size of a credit card. It’s a testament to the community and the hardware engineers.
It’s also a testament to how much we hate buying two of something when one can theoretically do it. Why buy two Pis when you can spend ten hours configuring one to act like two?
That is the tinkerer's credo, Corn. "Why buy it for fifty dollars when I can spend three hundred dollars in labor and parts to build it myself?"
Well, I think we’ve covered the technical landscape there. It’s a fascinating look at how far these little boards have come. From being a "one-task-at-a-time" toy to a "dual-head-multitasking" workstation.
What’s wild is thinking about where this goes. By twenty-twenty-seven or twenty-twenty-eight, we might have even more I.O. lanes. Imagine a Pi driving a four-monitor array for a home command center.
Don't give Daniel any ideas, Herman. He’ll have his whole house running on one Pi by next Tuesday.
Ezra would probably appreciate a dedicated "Bluey" screen while Daniel tracks his automation logs on the other three!
Honestly, that’s the dream. A dedicated Bluey portal that's physically impossible for Dad to accidentally close while he's checking the server temperatures.
That’s the ultimate reliability metric. If the toddler can’t break the display binding, no one can.
Alright, I think that’s a wrap on the dual-display Pi challenge.
Thanks as always to our producer, Hilbert Flumingtop, for keeping the gears turning behind the scenes.
And big thanks to Modal for providing the GPU credits that power this show. If you want to dive deeper into our past technical deep-dives, you can find the full archive at my-weird-prompts-dot-com. We’ve got transcripts, R.S.S. feeds, and all that good stuff over there.
We are also on Spotify if you haven't followed us there yet—hit that follow button to get the latest episodes as soon as they drop. We've been seeing a lot of new listeners from the UK and Germany lately, so welcome to the fold!
This has been My Weird Prompts. I’m Corn.
And I’m Herman Poppleberry.
See ya.
Goodbye!
