dual screen output on C1

Troubleshooting
1

Hello.

I have been trying, without success, to make current version of DietPi build for Odroid C1 run with two screens:

  • Kodi in X should go to HDMI output (TV), using /dev/fb0
  • my python program should go to FBTFT device, which is LCD attached to GPIO, like original Odroid’s touch screen, using /dev/fb2

The LCD works without a problem when I manage to direct the output to it.

Now, this setup did work on my previous distro, which was Odrobian, using simple dual-head xorg.conf.
Although, I had to change Kodi and Mali drivers from Xorg to fb versions, and that did the trick, with only small hiccup: after starting the program on /dev/fb2, primary screen on /dev/fb0 (HDMI output) would go blank, but after 5-10s it would go back and continue happily to work in parallel with the one on TFT LCD.

Now, with DietPi, it does not happen - the moment I start my python program on /dev/fb2, primary HDMI output goes blank and stays that way. If I stop my python program, Kodi/X return to HDMI output.

In Xorg logs I have seen the complaint like “VGA arbiter not found in kernel” saying something like “I can’t run two different video cards” (if I understood correctly) and X spits error on the TFT LCD section in xorg.conf and skips past it (something like “screen 1 not configured”).

It is interesting that even if I do not use dual-head xorg.conf setup, but keep the original single-head (with output only over HDMI /dev/fb0) I still can get output on /dev/fb2, but same behaviour for /dev/fb0 - it goes blank while anything is shown on /dev/fb2.
At the same time, xorg log file shows something like “leaving VT” when HDMI switches off, and “returning to VT” when it get back on.
So I tried xorg.conf options that might be related to VT switching, and got nowhere.

I have looked in kernel doc’s and as far as I can see, VGA arbiter is in use only for normal VGA outputs and just on some platforms - ARM not being one.
So, how come it worked on Odrobian?

I tried fiddling with con2fbmap and fbset, but it got me nowhere as well.

My question is - is this even possible without recompiling Kodi (and Xorg?) to work on FB?
Should I go back to Odrobian, even though it is not maintained anymore?
Is there another way, maybe through USB port, using some “translator” chip? What are my options, in general…?

I know this is a long and messy question, but I’m in a messy situation and I have to get this working somehow… :cry:

Thanks.

2

Well, I have found the answer my self, and it is not a big deal - just have to look in the Xorg log file…to put it mildly…

Here we go: for some reason, X has been compiled/configured with the default setting of not sharing the starting VT and switching on and off of it when it starts/stops (suspends) output to a certain display (device).

Generally, this is what happens: xinit starts X server, which reads xorg.conf, and then it starts the program given as argument to xinit.
If the program is given with full path, it is started on its own, otherwise, xterm is started and in it, using default shell, the program is started.
But, X server is started with default parameters, and in DietPi installation, it does not want to let go nor share the controlling terminal (VT) it is started from (here it is /dev/tty1) - instead it runs on display :0 and default device of /dev/fb0.
So, the moment you start another program on another frame buffer device like /dev/fb2 (even if it not a X program), running X server switches to the other VT and shuts down the display output on the first device - effectivelly disabling HDMI output.
The moment your program that is running on other device ends, X retakes the control on the VT and shows Kodi on the HDMI output.

So, in effect,

/DietPi/misc/start_kodi

script should be changed to has the following startup line:

xinit /usr/local/bin/kodi-standalone -- -novtswitch -sharevts

(this also avoids starting xterm which then starts Kodi - saves some memory)

Of course, this is for the option of autostarting Kodi, and not having it start from X session with desktop manager like LXDE/Mate etc.
In that situation, you have to change the startup script for the X on another place.

Why is it different than in Odrobian, where everything worked without a problem, I have no idea.

Options

-novtswitch

and

-sharevts

prevent X from that switching/shutting down one display output when another is activated, and thus, you can have two independant displays with their own frame buffer drivers.
Even better, one of them does not have to be driven by X server at all - such is my case where X is running on /dev/fb0 (HDMI output/TV) showing Kodi, and another is PyGame program on /dev/fb2 running on small TFT LCD.

Of course, you can have X running with two screens/displays so that each one of them is configured with xorg.conf for a dual-head setup, or you can even have two X servers, one running on display :0 and another on display :1, each one showing different things and be configured with two xorg.conf files - one for HDMI and one for TFT LCD in my case…

I hope this helps somebody wanting to add some sort of monitoring (or whatever) display to Odroid/RPi/etc in parallel to the main output and not loose hair to figure it how - all you need is a proper connection and a driver for the other display.

3

Hello

I know this is a very old post, but I’m hoping you still get the alerts, or someone else has time to reply.


I’m trying to achieve something similar with an ODroid C2, where I want to run Chromium on the HDMI touch screen and a terminal on the LCD screen.

Unfortunately I’m not entirely sure where to change the settings you talk about.

I’m happy to keep exploring, now that I know it’s possible, I’m just hoping you can push me on the right direction.

Many thanks,

Stuart