Its a typo, should be
`dpi_timings`
Good spot.
Its a typo, should be
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 '_'
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.
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
Code: Select all
omxplayer --win "0 0 1280 800" -o both -b /home/pi/Videos/trailer_1080p.mov
Code: Select all
omxplayer --win "500 0 1780 800" -o both -b /home/pi/Videos/trailer_1080p.mov
Code: Select all
omxplayer --win "1280 0 2560 800" -o both -b /home/pi/Videos/trailer_1080p.mov
Correct. The dispmanx resource specifies a display, and will have cropping parameters set up based on that.
Code: Select all
video_decode -> video_scheduler -> video_splitter -> video_render (HDMI)
+-> video_render (DPI/DSI)
Odd, I don't get that behaviour. Omxplayer writes directly to the display, not via any framebuffer, so not sure what could cause that.aBUGSworstnightmare wrote: ↑Sat Aug 11, 2018 8:23 amHi 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.
this is still beta! So why not try yourself and report back? Others here also test and spend their time...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
As the previous poster says it still beta / experimental.incognitos wrote: ↑Sun Aug 12, 2018 8:20 amthanks 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.
You can use OMXplayer for displaying a different video on each screen (fully HW accelerated). OMXplayer is not using any 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
Code: Select all
omxplayer --display=2 --win "0 0 1280 800" -o both -b /home/pi/Videos/trailer_1080p.mov
Hmmm... why are you quoting my post?aBUGSworstnightmare wrote: ↑Mon Aug 13, 2018 7:10 amYou can use OMXplayer for displaying a different video on each screen (fully HW accelerated). OMXplayer is not using any 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
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'
have you followed the entire post? Using the files only is just part of it!magichalo wrote: ↑Wed Sep 05, 2018 5:04 amHello,
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!
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.aBUGSworstnightmare wrote: ↑Fri Sep 07, 2018 6:58 amHi 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?