Dual monitors? Pointers?
-
Merry Christmas all, I'm looking for any pointers to doco, discussions or anything about dual monitors and feasible configurations? Day job as a Senior Linux Engineer so feel free to go full Torvalds at me straight off the bat. ;^)
Background: I have an RPI4 running Buster connected to a table top chassis into which I've mounted two 14" laptop monitors. OS installed, screens rotated and configured, RetroPie installed and running, bluetooth controllers sync'ed, audio out to cheapo speakers. Lovely and all good! Light up joysticks, I-PAC 2, wiring kit and USB board on-order etc...
Searched around and can I find anything about how to use two monitors... nope, basically zilch? I can see some discussion around banner displays and one about a Nintendo DS but they don't really go anywhere. I was looking for some documentation about configuration to use the second monitor as just the menu, as a single extended display, for static artwork, as a rotated mirror or really, ideally depending on the emulator (?) as a full blown separate monitor for player two?
The stock answer seems to be be "use another pi with a patch cable" and yes, that's sort of plan b but now the rpi 4 can drive two monitors I suspect people will start baulking at that answer as there is extra cost and I can already drive two joysticks from one pi with one i-pac 2 kit so just wondering if I've missed a link or discussion about driving two displays with separate content in any manner or whether here and now is the time and place to start one?
I'm willing to write stuff up, expiriement and commit it to git/a wiki but I was expecting some PC people to have already tried and proven having two independent displays even if it's new to the Pi people to have two monitors? I'm guessing running two instances (even in say docker) would still kill even an overclocked 4GB rpi4 (which is what I have)?
-
At the moment there's no such provision for the PI4 and since there was no support for dual monitors on previous models, I'd say it's normal there are no docs or instructions for such setup.
Given that RetroPie doesn't use X.org for the video output, I'm not sure how that would work in a pure KMS/DRM context.EDIT: you can play with the runcommand's onstart/onend scripts - see here - and try to display something on the 2nd screen or run commands (like starting
omxplayerwith a video, or showing an image with the game's controls/manual). -
Yup fair enough, thanks for at least confirming I'm off in to vaguely uncharted territory and I've not missed some obvious link to the answers.
I see you can at least start two instances of ES on one pi, so as all my orders for DIN rails, Pi holders button caps, light up joysticks etc... are waiting in Santa's sack I might have a look down that path but presume it'll destroy performance. Might be good enough for some really basic games, pong etc... ;^)
-
Rough notes so far for those following a similar path. I'm using lr-boom/Doom as the basic benchmark of play-ability. EmulationStation and Retroarch both seem to have options for running in "windowed" modes. ES uses the "--windowed" commandline option and RetroArch I think it was video_windowed_fullscreen (to false) setting in it's cfg config file somewhere under /opt/retropie/configs/all/retroarch/.
Buster/raspbian seems to be using openbox and lxde as window managers so you can consistently set the location using either wmctrl options of a window that's already running or ~/.config/openbox/rc.xml and following the idea from https://classicforum.manjaro.org/index.php?topic=10493.0Once both are windowed you can stretch them about (both es and lr windows) across both monitors, and lo... your performance will die horribly. You can tweak this around to achieve a reasonable placement but I didn't go any further as Doom was running like a dog. I notice when leaving the retroarch menu after quitting Doom that it would bring ES back in to focus on the desktop but in the wrong location as well. Didn't bother fixing this. I guess as a hideous hack you could have a script running with a "while true; sleep 1; wmctrl $moveWindowBack; done" but meh.
Having been sat at my cocktail format arcade machine at one end for a while now I also realize this isn't ideal. The joysticks are on the other sides facing each other if you know what I mean and from the current seating position the two TFT panels are too far away and the edge of the cabinet buts against my knees so I'm going to my arse 90 degrees around the corner to align with with the original design and configure the desktop to have the two TFT panels as a "top" and "bottom" rather than "left" and "right". In one player configuration I may leave the regular desktop on the top panel or use it for artwork etc as others have and full-screen the game onto the bottom one.
For two player mode I'll see about starting two instances of ES on each different panel and see how bad the performance is there.
With a lot of Linux applications it's possible to specify the config file as a command line option, this doesn't seem to be the case with ES or RetroArch?
I don't fancy scripting moving/copying different configs around so may just go and install a whole other installation.
I notice RetroArch has a bounty system in place, do ES and RetroPie go in for this?
-
Given that all kinds of programs use all kinds of backends and not all of them support dual-monitors (or are even aware of them), dual-monitor support is unlikely any time soon, I would guess.
I have an RPi4 cocktail cabinet but I learned within minutes that trying to get anything other than X to even mirror the onboard displays is a damn nightmare, and every time you switch from boot console to emulationstation to libretro games to SDL games and back and forth and back and forth? Not a chance.
I mirror the cocktail output to an external projector (for the audience, or to help the side-on 3rd and 4th players see better) but I do that with an HDMI splitter on the original HDMI output. Anything else is a nightmare of configuration, far worse even than trying to configure all the joystick button etc. inputs.
If you want to mirror, do it on the HDMI - a splitter is about £20 off Amazon. If you want anything more complex, I'd honestly forget it. And I spent most of my youth on Slackware configuring XFree86 via manual modeline configurations (and if you don't know what that means, take that as a hint), and programming SDL games. Sure, it's all theoretically possible. You will literally hate the resulting mess, though, even if you can get it working.
Here's me still trying to figure out how to distinguish between four identical joystick adaptors (with identical USB serial, etc.)... and having to fudge workarounds like encoding the joystick number into two of the button inputs permanently and then playing udev games to get them to line up as allocated. I didn't even try to use the second HDMI output on the RPi seriously for anything Retropie related.
-
@philipmather said in Dual monitors? Pointers?:
With a lot of Linux applications it's possible to specify the config file as a command line option, this doesn't seem to be the case with ES or RetroArch?
RetroArch does have an option for a command line (
--configI think), EmulationStation does not. However, for Emulationstation you can set $HOME to another folder and the config file will be picked from$HOME/.emulationstation/es_settings.cfg.I notice RetroArch has a bounty system in place, do ES and RetroPie go in for this?
No, but there's always a first :).
-
@ledow yeah my graphics subsystem knowledge is a bit patchy as it's outside the scope of my $DayJob but I'm happy trying a few avenues out in a hobby level interest kind of way. Just got totally side tracked for 30m discovering people are multi seating pi4s already... https://www.raspberrypi.org/forums/viewtopic.php?t=243572. Pointless right now without something more being added to fkms to split the one GPU as far as my understanding goes but interesting anyway.
I had a bit of expirience with Slack, ran it as a commercial OS for online gambling companies before they all moved to CentOS.
Also all of this is keeping me distracted from eating more mince pies so... 😆 good for the diet. -
@mitu yeah I sort of worked that out a minute ago. I spun up two other complete users, player1 and player2 and installed again (for my own documentation process as well TBH) with $rootdir as /opt/retropie-player1/ and ""-player2/ is there a way to stop the first full screen loosing focus and vanishing when I click back on the still exposed desktop of the second display? I used xhost + and export DISPLAY=:0.0 to grant player1 and player2 access to the display running as my own user, maybe a bit heavy handed but it works.
-
@philipmather note for anyone else, you need to add extra users to the render group in /etc/group so that it can access /dev/dri/renderD128 as whilst xhost + manages perms for the display I'm guessing logind gives your actual graphically logged in user access to that directory. This is confirmed when I do a geftfacl on it. My user is there but the user I justed su'ed into from the term is not.
Should probs use setfacl as well rather than groups if this all works out.At the moment I can now start ES as two seperate users with config that push one instance to screen 1 and the other to screen 2 but when starting lr-boom it complains about not having perms to /opt/retropie/ when it should be using /opt/retropie-player1/??
-
@philipmather /opt/retropie-player1/supplementary/runcommand/runcommand.sh has hard coded itself to assume ROOTDIR="/opt/retropie/" which is no longer true for my case.
-
@philipmather ditto /opt/retropie-player1/e...s.../scripts/inputconfigurations.sh has hard coded rootdir.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.