Question(s):
- why is omxplayer outputting on DPI display? Is it because of the 'testing' (framebuffer assignment) order
DPI
DSI
HDMI
Composite
- how the direct oxmplayer output to a dedicated screen? Is '--display=x' still working now?
- how to play a video over both screens?

Not sure you can play a HW decoded video over two screens...in fact I think that might be impossible from a HW perspective.

Correct. The dispmanx resource specifies a display, and will have cropping parameters set up based on that.

You could use video_splitter to send to two independent video_render components and then set the crop parameters to glue produce an overall combined image, but it won't happen magically. If using MMAL_ENCODING_OPAQUE or IL tunnelling then there is no performance penalty in doing so as they will use the same block of memory for both displays (no copying required).

Question simply came into my mind because I've used 'scrot' without the '-m' option and ended up with a big screenschot showing both framebuffers.

Coming back to 6by9's statement ... so if I split my video into two segments (using other software, which must not be running on the Pi) it should be possible to run two instances of omxplayer - displaying each half on their assigned screen - with HW acceleration, correct?

Starting both playbacks may not have any delay ... o.k. let me make some tests to see how far i can/want to get ..

and give the two video_render components different src_rect parameters via MMAL_DISPLAYREGION_T or the IL equivalent.

You are limited that the output resolution of video_decode can be a maximum of 1080P, so you're not going to be able to decode 3840x1080 and stretch it over the two displays.
You will get a tiddly bit of discrepancy as the VSYNCs on the two displays won't be locked together, but we're talking <16ms.

Oh and scrot is just looking at the two framebuffers and glueing them together to create an image. The firmware has no notion of which way round the displays are mounted, so how would it know which was on the left and which on the right? Or are they top and bottom? (Does scrot handle that, or does it make assumptions?)

Made some further tests yesterday where I was simply running omxplayer in window mode (outputing to DPI or HDMI). As already reported in an earlier post this may result in the other screen going all black, or not working at all (irregular display due to screwed-up timings).
What I want to understand now is how the second framebuffer is calculated/generated.

As there is no entry for framebuffer widths/heigths, but you can see some 'scaling' happening after boot (i.e. Wallpaper get's scaled to fit) I want to know how this is working.

Same problem happens when using 'screen' starting omxplayer, displaying independant video on both screens.

Made some further tests yesterday where I was simply running omxplayer in window mode (outputing to DPI or HDMI). As already reported in an earlier post this may result in the other screen going all black, or not working at all (irregular display due to screwed-up timings).
What I want to understand now is how the second framebuffer is calculated/generated.

As there is no entry for framebuffer widths/heigths, but you can see some 'scaling' happening after boot (i.e. Wallpaper get's scaled to fit) I want to know how this is working.

Same problem happens when using 'screen' starting omxplayer, displaying independant video on both screens.

Odd, I don't get that behaviour. Omxplayer writes directly to the display, not via any framebuffer, so not sure what could cause that.

Framebuffer sizes are determined by the display size they are assigned to, same for all fbs.

I'm away for next couple of weeks so won't be able to work on this. Might be able to comment.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

thanks for this valuable contribution. Does it also work with OSMC? I would like to have kodi mirrored on both the HDMI output and on the 7 inch DSI touch-display.

As the previous poster says it still beta / experimental.
One of the potential problems (for now at least) is that OSMC does not use the standard Raspbian kernel, so it may have unexpected effects when running OSMC.

You can of course try it, but make sure you have a backup of your current OSMC setup

PS: I'm not sure if this has any advantage on OSMC. OSMC uses HW accelerated video (including for the GUI).
This beta is for use of multiple screens using the framebuffer

DirkS wrote:
PS: I'm not sure if this has any advantage on OSMC. OSMC uses HW accelerated video (including for the GUI).
This beta is for use of multiple screens using the framebuffer

You can use OMXplayer for displaying a different video on each screen (fully HW accelerated). OMXplayer is not using any framebuffer.

I've experienced some Problems when playing two Video files as one of my screen goes black, dependant on where the OMXplayer window is located. Still Need to figure out what is causing this at my end as jamesh doesn't see such a Problem.
That's why I will makes some Trials with:
- DSI + Adafruit 5in DPI (connected to Kippah) (as jamesh posted he has a Kippah available)
- DSI + HDMI
- HDMI + DPI (that's where I noticed the problem)

Let me mention again: this is BETA, so no distro/SW will make use of it atm unless you instruct it to do.

Plays a Video file in a window which is 1280x800pixels big, located on HDMI screen
Use the numbers from this post viewtopic.php?f=63&t=216399&start=150#p1351400 to have the OMXplayer window on another screen. You can adjust the window size/Position as you need. Refer to OMXplayer manual for details on how to use.

Sample above is for Unit1 (from Resolution POV), both videos in full-screen window. Played the same video for this test as this file is the shortest that I've had on hands.

Findings:
Playing full-screen on both monitors of Unit1 works fine. 19in monitor has problems when video is played in some smaller Windows/certain positions (some settings are fine (?), so did not figure out root cause yet). 19in monitor then displays 'unsupported resolution warning' and needs to be power cycled to resume operation.

Problem described above could not be observed with unit2. Here playback window can have any size Position.

Conclusion:
Problem seems to be related to display timing. As full-screen is always fine - and that's what most people seem to prefer - this should be rare case to happen (and if: timing needs to be evaluated/modified --> so not a real problem as HDMI and DPI timings are now fully customizable).

I've decided to take this beta out for a spin as I am looking to have a display work on a custom DSI LCD. So far, I'm working with the Raspi Official Touch Screen and utilising this beta project, I get the following results.

I've updated to latest rpi-update for Jamesh's files (4.14.61) and added the kernel7.igm and start_x.elf files to boot. What results is the displays showing on both my monitor and my touch display.

However on boot, I get the splash screen on my touch screen, but boot and desktop on my monitor. My touchscreen doesn't change from the splash screen, but I can use everything via monitor. Also, looking into /dev/fb*, I only have the data for fb0, maybe the absence of fb1 is causing the touch to not display anything.

If there's any help I can get to extend the display for both, I'd like to help out if this gets solved. Thanks!

I've decided to take this beta out for a spin as I am looking to have a display work on a custom DSI LCD. So far, I'm working with the Raspi Official Touch Screen and utilising this beta project, I get the following results.

I've updated to latest rpi-update for Jamesh's files (4.14.61) and added the kernel7.igm and start_x.elf files to boot. What results is the displays showing on both my monitor and my touch display.

However on boot, I get the splash screen on my touch screen, but boot and desktop on my monitor. My touchscreen doesn't change from the splash screen, but I can use everything via monitor. Also, looking into /dev/fb*, I only have the data for fb0, maybe the absence of fb1 is causing the touch to not display anything.

If there's any help I can get to extend the display for both, I'd like to help out if this gets solved. Thanks!

have you followed the entire post? Using the files only is just part of it!
- how did you start? Fresh (clean) install are used system?
- as you see fb0 only you should ckeck if there is 'start_x=1' in your config.txt
- do you have 'xorg.conf' settings as per this post https://www.raspberrypi.org/forums/view ... 0#p1346976
- boot to CLI
- start with i.e. : 'startx -- -layout Multihead' for dual display

And: your talking about custom DSI display! Is this already proved working or do you try to connect a random display thinking this beta will bring it to life?

I've missed out on the xorg file, I've added that in to the etc/X11 directory, and I forgot to mention that I did enable start_x=1 in my config.txt file. I've booted into CLI and started the command as you mentioned, but no changes, still only see the rpi display on my monitor while my touchscreen is still idling in boot splash.

Also, for the custom display, AFAIK, there is no real easy interface for custom displays, which is why I'm experimenting with the touchscreen display to at least work with a DSI output. What I'm trying is to find a way to force display some data on the display channel, and then wiring the display pins directly to the custom screen. I figured I'd try to use this beta as a way to see if it gives me what I'm looking for (I've also looked into using a raspi2raspi display clone to have the HDMI output to DSI). The screen in question is a MIPI DSI connecting to the display D0 & CLK lines, but I'm having trouble getting the rpi treating it like a display.

Just to have this questions asked:
1) Any chance to get multiple framebuffer support for two DSI displays (DSI0 + DSI1)?
2) will it allow to use DSI0 instead of DSI1 (as DSI one is the only possibility atm)?
3) when will it be released?

Just to have this questions asked:
1) Any chance to get multiple framebuffer support for two DSI displays (DSI0 + DSI1)?
2) will it allow to use DSI0 instead of DSI1 (as DSI one is the only possibility atm)?
3) when will it be released?

DSI1 is the only DSI port exported on the standard Pi's. Only the CM exposes DSI0. I am actually not sure whether this will work with two displays on a CM3, never tried it. I suppose I should! DPI+DSI doesn't work due to a HW limitation but two DSI should be OK.

No idea of a release date. Need to talk to the boss about the level of testing required - this is a big change to the underlying firmware.

I think I will need to add a backwards compatibility mode, i.e. to force only one display support which gets us back to the current scheme. Or perhaps have that as a default, and have a config item to enable multiple FB's. Hmm, think that's probably the best approach.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."