jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20067
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:19 am

procount wrote:
Fri Aug 10, 2018 9:07 am
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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:28 am

aBUGSworstnightmare wrote:
Fri Aug 10, 2018 9:18 am
procount wrote:
Fri Aug 10, 2018 9:07 am
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
Posts: 1149
Joined: Thu Jun 27, 2013 12:32 pm
Location: UK

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:31 am

aBUGSworstnightmare wrote:
Fri Aug 10, 2018 9:18 am
procount wrote:
Fri Aug 10, 2018 9:07 am
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. :D
PINN - NOOBS with the extras... https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=142574

aBUGSworstnightmare
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:32 am

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20067
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 9:57 am

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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

aBUGSworstnightmare
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 11:47 am

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!):
IMG_0568.jpg
SUCCESS!!
IMG_0568.jpg (92.4 KiB) Viewed 346 times
Here's a screenshot of the framebuffer
2018-08-10-133204_2360x1920_scaled.jpg
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 346 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
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 12:34 pm

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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20067
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 1:11 pm

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
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 1:27 pm

jamesh wrote:
Fri Aug 10, 2018 1:11 pm
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).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 1:38 pm

@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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 1:46 pm

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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5372
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Multiple Frame buffer beta testers wanted

Fri Aug 10, 2018 1:48 pm

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?)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

aBUGSworstnightmare
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sat Aug 11, 2018 8:23 am

:D 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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 20067
Joined: Sat Jul 30, 2011 7:41 pm

Re: Multiple Frame buffer beta testers wanted

Sun Aug 12, 2018 7:40 am

aBUGSworstnightmare wrote:
Sat Aug 11, 2018 8:23 am
:D 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.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

incognitos
Posts: 1
Joined: Sun Aug 12, 2018 8:15 am

Re: Multiple Frame buffer beta testers wanted

Sun Aug 12, 2018 8:20 am

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
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Sun Aug 12, 2018 6:39 pm

incognitos wrote: 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
Posts: 8505
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Multiple Frame buffer beta testers wanted

Sun Aug 12, 2018 7:00 pm

incognitos wrote:
Sun Aug 12, 2018 8:20 am
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
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Mon Aug 13, 2018 7:10 am

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.

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
Posts: 8505
Joined: Tue Jun 19, 2012 9:46 pm
Location: Essex, UK

Re: Multiple Frame buffer beta testers wanted

Mon Aug 13, 2018 8:52 am

aBUGSworstnightmare wrote:
Mon Aug 13, 2018 7:10 am
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.
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
Posts: 768
Joined: Tue Jun 30, 2015 1:35 pm

Re: Multiple Frame buffer beta testers wanted

Tue Aug 14, 2018 11:22 am

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

Return to “General discussion”

Who is online

Users browsing this forum: DirkS and 65 guests