Multiple Frame buffer beta testers wanted

[jamesh]

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.

[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

[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

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

[DougieLawson]

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.

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

[jamesh]

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.

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

[DougieLawson]

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.

[jamesh]

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.

[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

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

[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

[jamesh]

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!

[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

[aBUGSworstnightmare]

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.

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

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)

[aBUGSworstnightmare]

You can have (currently) a maximum of two displays.

Affitmitive

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.

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.

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.

[jamesh]

You can have (currently) a maximum of two displays.

Affitmitive

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.

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.

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.

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

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

[aBUGSworstnightmare]

@ jamesh: any News?

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

[aBUGSworstnightmare]

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

[jamesh]

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.