In this guest blog post from Integrated Computer Solutions (ICS), the authors delve into the intricacies of mirroring displays with varying resolutions using Yocto on Variscite’s popular DART-MX8M-PLUS SoM based on the NXP i.MX8M Plus SoC. Navigating through the complexities of compositor choices, they emphasize the efficacy of a simplified solution.
By Lisandro Pérez Meyer and Michael Dingwall, ICS
Ever had one of those moments when your routine embedded device setup gets a jolt of unpredictability? We recently encountered such a scenario on a project where the client dropped the bombshell: “We’ve got an LVDS display, but we want users to plug in an HDMI monitor at their convenience and get a mirrored display of the application.”
Sounds simple, right? Not so fast. Sure, back in the X server era, achieving this mirrored display was a walk in the park. Set up the right configuration, and voila, the X server would seamlessly mirror the main display onto the newly plugged one. It would look like this:
Graphic 1
But as tech has evolved – bye, bye X! – a monkey wrench has been tossed into the process, preventing the second monitor from handling the same resolution as the main monitor. As a result, you might see something like this:
Graphic 2
Not great. Fortunately, there’s a solution: use the native resolution of each monitor and adjust the window’s content. Doing so can help achieve something like this:
Graphic 3
Ah, that looks much better! But arriving at this solution was a journey requiring a lot of trial and error as we experimented with a variety of compositors.
Journey from Complexity to Simplicity
For today’s tech, X is old news. The popular NXP i.MX8 family of processors is now all about Wayland, a protocol dancing between a compositor and one or more clients. Weston, Wayland’s reference implementation, is certainly adequate for many situations. But if you’re using Qt for your project you should consider using the Qt Wayland Compositor.
In general, it will make your life easier. But – there’s always a but – Wayland’s default spec doesn’t allow clients to dictate their positioning. That’s the job of the window manager, which is part of the composer.
Fortunately, the Wayland protocol can be expanded. Enter the In-Vehicle Infotainment (IVI) extension, which lets clients provide an ID so that the composer knows where to place the window. We found this to be promising – but turns out that it leans toward layouts on the primary screen. Sure, we could modify the composer, but that’s extra time we’d rather not spend.
Instead, we could create two windows and let the composer put them where they belong. Since we’re using Qt, we’ll first try via the Qt IVI Compositor.
Nope. Turns out that’s not possible because while requirements specify that the user must be able to plug in an HDMI monitor, they do not define which specific monitor or at what resolution. (Currently, Qt can handle multiple displays only when their resolutions are hardcoded in a configuration file.)
So, we’ll circle back to Weston since it has an IVI extension – Weston IVI-shell.
And…. once again, no luck. At least by default, the Weston compositor only handles layouts on the primary screen. That means we would have to modify the compositor in order to use the IVI shell. That’s possible but would take a lot of extra time, so we’ll keep exploring alternatives.
What about Sway? This tiling Wayland compositor might just be the ticket – and since we’re using Yocto on our Variscite DART-MX8M-PLUS board, based on NXP i.MX 8M Plus, it is a real option. By pairing it with wl-mirror, we could sidestep the hassle of creating two windows.
Excitement builds as we try this approach.
It’s definitely workable (yay!) but a little too complicated for our tastes (boo!). So now we’re on the lookout for a more streamlined solution. What if we simplify the entire display game with just one window to rule them all?
A Single Window
Weston can handle multiple displays. When a new display is plugged in Weston will expand the desktop to the right of the original LVDS display. So, picture this: a single window with a width equal to the combined widths of both the LVDS and HDMI displays and a height matching the taller display. Imagine the application effortlessly showcasing the same content on both the LVDS and HDMI areas, responding to interactions seamlessly. Sounds too good to be true, right?
Well, surprise – it works like a charm! With this nifty approach, Qt does the heavy lifting, informing us about the screen sizes and adapting on the fly. We used the DART-MX8M-PLUS for our explorations, but this solution will work with any of Variscite’s i.MX8-based SoM. While this approach potentially requires a memory area larger than the sum of both displays – a minor drawback – we don’t need to tinker with the compositor’s code to mirror the displays. That’s a win!
While all along we had the tools for a “proper” solution – juggling multiple displays, maneuvering windows on the compositor – opting for a straightforward fix ultimately proved faster and just as effective. Sometimes, keeping it simple is the real game-changer.
About Integrated Computer Solutions (ICS):
ICS develops best-in-class software applications and touchscreen interfaces for embedded and connected medtech, industrial and commercial products.
About the authors:
Lisandro Pérez Meyer and Michael Dingwall are software engineers at ICS (www.ics.com).