Page 5 of 15

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 9:09 am
by jamesh
DougieLawson wrote:
Tue Jul 31, 2018 9:18 pm
jamesh wrote:
Tue Jul 31, 2018 9:20 am
Ah, for those wanting to use the latest kernel image, probably best to rpi update

`sudo rpi-update d985893a`

Will get you a 4.14.56 level set of kernel modules which should match the kernel linked above. Sorry, I forgot I had rebased my frame buffer tree which bumped the kernel version.

Only do this on systems you can afford to break! But I suppose since you are using beta software, you have already taken that in to account...haven't you?
Can you rebuild it on 4.14.58 as that was released yesterday by Popcornmix?
OK. Will do that today. Probably.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 12:34 pm
by jamesh
New kernel image just for Dougie (and relocated the one above, so link will now fail)

This one is for the latest rpi-update (4.14.58), so you can simply do an rpi-update, then copy over this file and start_x.elf to the boot folder.
https://drive.google.com/open?id=1I7kbX ... qqQhnUnVe3

This one is for 4.15.56 (ie the previously posted one)
https://drive.google.com/open?id=1f-f5c ... cOI4FbGgxL

start_x.elf can be got from here if you havent already.
https://drive.google.com/open?id=1sT902 ... gRGAjrjrWA

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 1:28 pm
by aBUGSworstnightmare
Hi jamesh,

first of all a big 'THANK YOU' for your work! Highly appreciated.
As mentioned yesterday I've started some tests today.

Here are some infos on the setup I'm using:
- official 7in DSI display
- RPI3B
- Dell 19in Monitor, SXGA, connected via HDMI
- 12.1in TFT-module (LQ121K1LG52), connected via LVDS4Pi to DPI Interface
- all required changes applied, latest xorg.conf Settings, booting to CLI and issuing 'startx -- -layout Multihead' command

Here are my findings (so far):
1) all displays connected --> DPI and HDMI get picked-up for framebuffers

2) HDMI monitor disconnected --> only DPI is working, DSI stays silent

3) disable DPI in config.txt (you can find my config below) --> DSI and HDMI are working as expected (as I've started with this configuration before connecting the DPI display)

Questions:
- what is 'ranking' for assigning framebuffer to Interfaces?
- any idea why DSI + DPI is not working simultaniously (as this would be my preferred HW setup)?

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.
#framebuffer_width=1280
#framebuffer_height=720

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

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# 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
start_x=1
gpu_mem=208

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

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

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

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

# ---------------------------------------------
# HDMI timing definitions
# ---------------------------------------------
#hdmi_timings=1280 1 40 1 1 800 1 12 2 1 0 0 0 60 0 83500000 5

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 2:03 pm
by jamesh
Don't know about DSI+DPI, will need to put together a setup to test it. I don't beleive there is a technical reason why this won't work, but might be down to some configuration somewhere. Might take a while to find a DPI display - the guy who lent me his last time is out of the office. I'm going to be looking at the config.txt entries for displays tomorrow so expect some changes in there to help with this sort of configuration.

I think the allocatons of FB is the order they are detected in the VC4, with exception of the composite case, which is always moved to the end of the list. So HDMI->DSI->DPI->Composite I think. But only two displays supported at the moment (easy increase if there is a use case), and they are always numbered contiguously.

Although note the DPI displays are not detected as such - the system need to be told they are there.

Edit: OK, found some odd code in the VC4 platform startup - basically you can have DPI or DSI but not both. However, I see no reason why it is done like that, so am going to shuffle things around a bit to see if I can make it work,. I suspect its simply code that was written when the Pi first launched and we only supported one screen, of whatever sort.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 5:54 pm
by DougieLawson
jamesh wrote:
Wed Aug 01, 2018 12:34 pm
New kernel image just for Dougie (and relocated the one above, so link will now fail)

This one is for the latest rpi-update (4.14.58), so you can simply do an rpi-update, then copy over this file and start_x.elf to the boot folder.
https://drive.google.com/open?id=1I7kbX ... qqQhnUnVe3
Thank you. I'll give that a go later tonight.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 6:50 pm
by DougieLawson
My 3B with the RPF display doesn't want to play nicely. I got the rainbow splash screen on both the RPF LCD and the TV, but it wouldn't go beyond that. Switched it all back to normal and it won't boot (working on fixing that).

This one normally boots from a Sandisk USB stick.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:04 pm
by jamesh
DougieLawson wrote:
Wed Aug 01, 2018 6:50 pm
My 3B with the RPF display doesn't want to play nicely. I got the rainbow splash screen on both the RPF LCD and the TV, but it wouldn't go beyond that. Switched it all back to normal and it won't boot (working on fixing that).

This one normally boots from a Sandisk USB stick.
Would not have thought the boot media would effect things, but I haven't tested anything like that, so maybe. Sounds like the kernel image is not loading.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:15 pm
by aBUGSworstnightmare
Edit: OK, found some odd code in the VC4 platform startup - basically you can have DPI or DSI but not both. However, I see no reason why it is done like that, so am going to shuffle things around a bit to see if I can make it work,. I suspect its simply code that was written when the Pi first launched and we only supported one screen, of whatever sort
sounds promising!
Let me know when you made the changes and I will test it.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:17 pm
by DougieLawson
jamesh wrote:
Wed Aug 01, 2018 7:04 pm
Would not have thought the boot media would affect things, but I haven't tested anything like that, so maybe. Sounds like the kernel image is not loading.
I've got a bootable SDCard for that Raspberry now. Because I'm using that to repair my non-bootable USB stick. So may have more playtime later.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:29 pm
by jamesh
aBUGSworstnightmare wrote:
Wed Aug 01, 2018 7:15 pm
Edit: OK, found some odd code in the VC4 platform startup - basically you can have DPI or DSI but not both. However, I see no reason why it is done like that, so am going to shuffle things around a bit to see if I can make it work,. I suspect its simply code that was written when the Pi first launched and we only supported one screen, of whatever sort
sounds promising!
Let me know when you made the changes and I will test it.
I'll probably do a build tomorrow with the proposed fix, but I don't have aything to test with - I'll make it available for you if you want it.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:43 pm
by aBUGSworstnightmare
Sure, let me have it! I have some Raspberries and quite a lot of DPi displays to test with (some of them are real DPi, others are used with LVDS transmitter).
Pictured setup is still sitting on my desk, ready for some more test-runs

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 7:54 pm
by AiRSpectruM
One issue I've had with latest update is that the overscan appears to stay enabled. On first boot I had a black border around the screen but when I went to go disable overscan it was already disabled, so i enabled (restarted pi) and the disabled(restarted again) yet still have to border.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 9:06 pm
by aBUGSworstnightmare
Have you disabled it via config.txt already (rather than using the GUI)?
Be sure to disable pixeldoubling as well as this gave me a 'cinemascope' view (black border too+bottom) when I tried this first time

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 01, 2018 10:05 pm
by jamesh
aBUGSworstnightmare wrote:
Wed Aug 01, 2018 9:06 pm
Have you disabled it via config.txt already (rather than using the GUI)?
Be sure to disable pixeldoubling as well as this gave me a 'cinemascope' view (black border too+bottom) when I tried this first time
Simon did say that pixel doubling would cause chaos! Not sure about the overscan issues, did look at it yesterday, and it seemed OK.

Note everyone this is not an standard update, this is a beta test which is likely to have a load of issues popping out of the woodwork - that's why it's a beta!

Re: Multiple Frame buffer beta testers wanted

Posted: Thu Aug 02, 2018 9:04 am
by jamesh
ONLY FOR PEOPLE USING A DSI AND A DPI SCREEN AT SAME TIME
(Although it should work under all circumstances, so try if you want)

OK, here is a link to a start_x.elf that I hope will fix the DPI/DSI coexistence issue. However, I am not entirely sure whether the HW will be able to cope, so use at peril.

https://drive.google.com/open?id=15_fwv ... 3k9OlmtIcL

Re: Multiple Frame buffer beta testers wanted

Posted: Thu Aug 02, 2018 11:16 am
by aBUGSworstnightmare
jamesh wrote: ONLY FOR PEOPLE USING A DSI AND A DPI SCREEN AT SAME TIME
(Although it should work under all circumstances, so try if you want)
Well, I experience something different!

What is working is:
- HDMI only
- DSI only
- DPI + HDMI (DSI display disconnected!)
- DSI + HDMI (DPI disabled in config.txt; btw. still uisng the one postd abvove)

What is not working is:
- DSI + HDMI (DPI display enabled in config.txt)
- DSI + DPI (HDMI disconnected)

For the non-working setups Raspberry is not booting at all (only one blink of the green LED and a slight flicker of the DSI display). Changing the config (disabeling DPI) brings the System back to working condition.

Re: Multiple Frame buffer beta testers wanted

Posted: Thu Aug 02, 2018 12:21 pm
by jamesh
aBUGSworstnightmare wrote:
Thu Aug 02, 2018 11:16 am
jamesh wrote: ONLY FOR PEOPLE USING A DSI AND A DPI SCREEN AT SAME TIME
(Although it should work under all circumstances, so try if you want)
Well, I experience something different!

What is working is:
- HDMI only
- DSI only
- DPI + HDMI (DSI display disconnected!)
- DSI + HDMI (DPI disabled in config.txt; btw. still uisng the one postd abvove)

What is not working is:
- DSI + HDMI (DPI display enabled in config.txt)
- DSI + DPI (HDMI disconnected)

For the non-working setups Raspberry is not booting at all (only one blink of the green LED and a slight flicker of the DSI display). Changing the config (disabeling DPI) brings the System back to working condition.
Hmm. You can have (currently) a maximum of two displays., The order in which they are tested is

DPI
DSI
HDMI
Composite

So if you have DPI and DSI enabled then it will won't even startup the HDMI. I wonder if that is an issue for later things.

That explains DSI+HDMI (DPI enabled) not working - it never gets to HDMI as it already thinks DPI and DSI are running (Note, DPI displays cannot be detected, so if they are enabled in config, then it is assumed they are there)

Doesn't explain why DSI+DPI doesnt work. DSI and DPI do use different pixel valves, so that should be OK. I really need to try this out myself but cannot do that right now.

I wonder if increasing the number of displays would help, but I suspect then we would start to hit pixel bandwidth limitations, and probably run out of pixel valves anyway. (pixel valves are HW blocks that do a load of pixel processing, I think you need one per output device, they do timing of the pixels, things like fps and backporches etc)

Re: Multiple Frame buffer beta testers wanted

Posted: Thu Aug 02, 2018 12:42 pm
by aBUGSworstnightmare
jamesh wrote:You can have (currently) a maximum of two displays.
Affitmitive
jamesh wrote: That explains DSI+HDMI (DPI enabled) not working - it never gets to HDMI as it already thinks DPI and DSI are running (Note, DPI displays cannot be detected, so if they are enabled in config, then it is assumed they are there)
This is also understood. Even tested with different values for 'display_default_lcd=x' but this changes nothing and that's why it's commented out.
jamesh wrote: Doesn't explain why DSI+DPI doesnt work. DSI and DPI do use different pixel valves, so that should be OK. I really need to try this out myself but cannot do that right now.
Understood. Just let me know when you have DPI hardware on hands; I will resume testing then.
jamesh wrote: I wonder if increasing the number of displays would help, but I suspect then we would start to hit pixel bandwidth limitations, and probably run out of pixel valves anyway. (pixel valves are HW blocks that do a load of pixel processing, I think you need one per output device, they do timing of the pixels, things like fps and backporches etc)
Don't know how much work it is to add a third one (so DSI+DPI+HDMI would be possible). If you let me have the code I can promise to test it and report back.

Re: Multiple Frame buffer beta testers wanted

Posted: Fri Aug 03, 2018 6:40 am
by jamesh
aBUGSworstnightmare wrote:
Thu Aug 02, 2018 12:42 pm
jamesh wrote:You can have (currently) a maximum of two displays.
Affitmitive
jamesh wrote: That explains DSI+HDMI (DPI enabled) not working - it never gets to HDMI as it already thinks DPI and DSI are running (Note, DPI displays cannot be detected, so if they are enabled in config, then it is assumed they are there)
This is also understood. Even tested with different values for 'display_default_lcd=x' but this changes nothing and that's why it's commented out.
jamesh wrote: Doesn't explain why DSI+DPI doesnt work. DSI and DPI do use different pixel valves, so that should be OK. I really need to try this out myself but cannot do that right now.
Understood. Just let me know when you have DPI hardware on hands; I will resume testing then.
jamesh wrote: I wonder if increasing the number of displays would help, but I suspect then we would start to hit pixel bandwidth limitations, and probably run out of pixel valves anyway. (pixel valves are HW blocks that do a load of pixel processing, I think you need one per output device, they do timing of the pixels, things like fps and backporches etc)
Don't know how much work it is to add a third one (so DSI+DPI+HDMI would be possible). If you let me have the code I can promise to test it and report back.
Three screens, depending on size, will probably overload the hvs bandwidth. But we can try it.

Re: Multiple Frame buffer beta testers wanted

Posted: Fri Aug 03, 2018 8:18 am
by aBUGSworstnightmare
To me two would be sufficient.
Maybe this trail helps to nail down the problem in DPI+DSI

EDIT:
Three screens, depending on size, will probably overload the hvs bandwidth. But we can try it.
This brings us to the next questions:
- what would be the maximum achievable resolution for multi-head? Available resolution on DPI might be limited (as high clock speeds might be required).
- is there any possibility (or will there be) for defining the size of the framebuffers?

Note to myself: ... also Need to check what happens in case one/both displays are rotated to portrait mode ...

Re: Multiple Frame buffer beta testers wanted

Posted: Fri Aug 03, 2018 9:35 pm
by jamesh
Rotation will really hammer the HVS, that will cause lower acheivable frame rates.

I've been trying to get DSI+DPI working, no luck so far. I did have a slight distration in to providing a separate dpi_timings setting for config.txt that shoudl be in a firmware release in the nr future, so you can have separate customer HDMI and DPI timings.


The HVS and all the associated HW has a maximum pixel data rate, which you need to divide over the all displays, exceed that and things will start to go odd. Not sure how many gigapixels/s it is though - will find out Monday.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 08, 2018 10:10 am
by aBUGSworstnightmare
@ jamesh: any News?

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 08, 2018 11:27 am
by jamesh
Been hitting things with a big hacky stick, but not got the DPI and DSI to coexist. Going to call it a day since its a low use case. There may even be a HW limitation in there I am unaware of. Sorry.
You will get the new config.txt entry dpi_settings out of it, so you can have different custom settings for HDMI and DPI.

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 08, 2018 11:51 am
by aBUGSworstnightmare
jamesh wrote: You will get the new config.txt entry dpi_settings out of it, so you can have different custom settings for HDMI and DPI.
That's prefectly fine for me too! Even if DSI and DPI cannot coexist, having the possibility of two custom settings (HDMI + DPI) is great! Let me know when it's available and I will test it (DPI + Manga Screen 2 on HDMI is perfect candidate).

Re: Multiple Frame buffer beta testers wanted

Posted: Wed Aug 08, 2018 12:32 pm
by jamesh
aBUGSworstnightmare wrote:
Wed Aug 08, 2018 11:51 am
jamesh wrote: You will get the new config.txt entry dpi_settings out of it, so you can have different custom settings for HDMI and DPI.
That's prefectly fine for me too! Even if DSI and DPI cannot coexist, having the possibility of two custom settings (HDMI + DPI) is great! Let me know when it's available and I will test it (DPI + Manga Screen 2 on HDMI is perfect candidate).
It was merged to our repo a couple of days ago, not sure when it gets released as a binary. Within a week I expect. My testing showed it worked OK. I did find a bug in the DPI driver which has also been fixed, but it wasn't in your face, so probably will go past unnoticed.