Multiple Frame buffer beta testers wanted

[jamesh]

Probably just a typo in this thread, but @JamesH said 'dpi-timings' and @aBUGSworstnightmare used 'dpi_timings' ??

Its a typo, should be

`dpi_timings`

Good spot.

[aBUGSworstnightmare]

Probably just a typo in this thread, but @JamesH said 'dpi-timings' and @aBUGSworstnightmare used 'dpi_timings' ??

Sorry, but I can't follow your comment.

oh man ... I'm getting old! I either need to get a bigger screen or better glasses! took me a few minutes to spot the '-' vs '_'

o.k. let me see if that makes any difference ...

[procount]

Probably just a typo in this thread, but @JamesH said 'dpi-timings' and @aBUGSworstnightmare used 'dpi_timings' ??

Sorry, but I can't follow your comment.

Don't worry - I tried to identify differences between what you said didn't work and what James said to do. You got it right. James made a small typing error in the thread (not in his code). All good.

[aBUGSworstnightmare]

To me 'dpi-timings' gives the same result as dpi_timings': DPI Screen is not working.

So maybe there's more than this typo in 'the thread'..

Anybody else here who got it working with an dpi_timings entry in their config.txt?.

[jamesh]

Here's the latest builds, might be worth trying these.

https://drive.google.com/open?id=1At1jm ... FYE_HxOa9Z

This is for kernel 4.14.61 - so the current rpi-update.

[aBUGSworstnightmare]

o.k. ... here is what I did:
- fresh Raspbian on uSD
- boot,configure, update/upgrade, rpi-update (all done on 19in screen)
- copy files from here (posting.php?f=63&mode=reply&t=216399&si ... #pr1351325) to the uSD
- reboot and create xorg.conf settings
- enable DPI in config.txt
- boot to CLI
- start with: 'startx -- -layout Multihead'

--> gives me HDMI + DPI display

Now change 'hdmi_timings' line to 'dpi_timings' line --> all fine.

Change config.txt for Manga Screen 2 connected to HDMI (see below):

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#max_framebuffer_width=1920
max_framebuffer_height=1920

#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1
hdmi_ignore_edid=0xa5000080

# uncomment to force a specific HDMI mode (this will force VGA)
# XGA settings
#hdmi_group=2
#hdmi_mode=35

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
gpu_mem=208

# ---------------------------------------------
# Enable DPI
# --------------------------------------------- 
dtoverlay=dpi24
enable_dpi_lcd=1

# ---------------------------------------------
# Make DPI default output
# ---------------------------------------------
#display_default_lcd=1

# ---------------------------------------------
# custom DPI mode
# ---------------------------------------------
dpi_group=2
dpi_mode=87

# ---------------------------------------------
# DPI output format definitions
# ---------------------------------------------
dpi_output_format=461847

# ---------------------------------------------
# DPI timing definitions
# ---------------------------------------------
dpi_timings=1280 1 40 1 1 800 1 12 2 1 0 0 0 60 0 83500000 5


# settings for MANGA SCREEN 2
hdmi_force_hotplug=1
hdmi_ignore_edid=0xa5000080
# ---------------------------------------------
# custom HDMI mode
# ---------------------------------------------
hdmi_group=2
hdmi_mode=87

# ---------------------------------------------
# HDMI timing definitions
# ---------------------------------------------
hdmi_timings=1080 1 100 10 50 1920 1 2 2 2 0 0 0 60 0 144400000 3

start_x=1

Shutdown, connect Manga Screen 2 instead of 19in monitor, reboot and see this (note: Manga Screen is still in portrait mode!):

SUCCESS!!

IMG_0568.jpg (92.4 KiB) Viewed 1780 times

Here's a screenshot of the framebuffer

Screenshot of framebuffer. Manga Screen 2 is FHD, 12.1in is WXGA Resolution --> total framebuffer is 2360x1920 pixels

2018-08-10-133204_2360x1920_scaled.jpg (79.49 KiB) Viewed 1780 times

Now it's time to figure out which performance one can achieve (also when displays are rotated or video is played 'full screen').
Big THANK YOU! to jamesh for this!

[aBUGSworstnightmare]

tested with 'display_hdmi_rotate=3' which rotates Manga Screen to landscape mode.

Now I made some test with OXMplayer, with omxplayer always on DPI screen!
tested the window option like below:

Code: Select all

omxplayer --win "0 0 1280 800" -o both -b /home/pi/Videos/trailer_1080p.mov

Result: HDMI screen goes all-black, Video is full-screen on DPI display

Code: Select all

omxplayer --win "500 0 1780 800" -o both -b /home/pi/Videos/trailer_1080p.mov

Result: HDMI screen is fully visible, Video is shifted on DPI (as expected)

Code: Select all

omxplayer --win "1280 0 2560 800" -o both -b /home/pi/Videos/trailer_1080p.mov

Result: HDMI screen is fully visible, DPI screen is all black as video is shifted 'beyond visible resolution'

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?

[jamesh]

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

You need to specify which screen OMXPlayer outputs to, using the --display option. Takes numbers from 0 to 6 as follows

DISPMANX_ID_MAIN_LCD 0
DISPMANX_ID_AUX_LCD 1
DISPMANX_ID_HDMI 2
DISPMANX_ID_SDTV 3
DISPMANX_ID_FORCE_LCD 4
DISPMANX_ID_FORCE_TV 5
DISPMANX_ID_FORCE_OTHER 6 /* Note sure what this is

[6by9]

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).

[aBUGSworstnightmare]

@6by9: Need to think about your replay...

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 ..

[6by9]

No.

Code: Select all

video_decode -> video_scheduler -> video_splitter -> video_render (HDMI)
                                                 +-> video_render (DPI/DSI)

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.

[6by9]

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?)

[aBUGSworstnightmare]

Hi jamesh,

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.

[jamesh]

Hi jamesh,

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.

[incognitos]

Hi all,

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.

Best regards

[aBUGSworstnightmare]

Hi all,

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.

Best regards

this is still beta! So why not try yourself and report back? Others here also test and spend their time...

[DirkS]

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

[aBUGSworstnightmare]

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.

EDIT:

Code: Select all

omxplayer --display=2 --win "0 0 1280 800" -o both -b /home/pi/Videos/trailer_1080p.mov

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.

[DirkS]

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.

Hmmm... why are you quoting my post?
As I mentioned OSMC doesn't use framebuffer so this beta will not be of any use. So why quote it and then rambling on about some other stuff...

Looks to me you're responding to @incognitos

[aBUGSworstnightmare]

Made some further tests on two different platforms:

Unit1:
RPi 3 + Adafruit DPI Kippah (5in, 800x480pixels) + 19in SXGA Monitor

Unit 2:
RPi3 + 7in DSI + Manga Screen 2

Test setup:
Play video on each display. I've installed 'screen' and started below script file from desktop:

Code: Select all

screen -dmS vid1 sh -c 'omxplayer --display=4 --win "0 0 800 480" /home/pi/Videos/trailer_1080p.mov; exec bash'
screen -dmS vid1 sh -c 'omxplayer --display=2 --win "0 0 1280 1024" /home/pi/Videos/trailer_1080p.mov; exec bash'

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).

[magichalo]

Hello,

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!

[aBUGSworstnightmare]

Hello,

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?

[magichalo]

Hi, thanks for the response!

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.

Thanks for the help, I appreciate your support on the rpi

[aBUGSworstnightmare]

Hi jamesh,

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?

[jamesh]

Hi jamesh,

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.