Multiple Frame buffer beta testers wanted

[jamesh]

OK, finally got a DPI display going.

I see no overscan on DPI, tried with disable_overscan=0 and disable_overscan=1

I don't think you should expect a rainbow screen on the DPI, due to way it starts up - by the time it's initialised, the splash screen has been and gone.

I am getting display on the HDMI for dispmanx 2 and 5, the rest go to the DPI - I think that would be the same for the DSI display. It's the way I re-map display numbers* - I thought it was backwards compatible, but if not, what should be expected here?

* Hangover from when the DSI display was first implemented...not very nicely.

[6by9]

I don't think you should expect a rainbow screen on the DPI, due to way it starts up - by the time it's initialised, the splash screen has been and gone.

If you provide a dt-blob.bin to do the pin remuxing, then you'll see the rainbow screen.
If you use dtoverlay=dpi18 or dtoverlay=dpi24 to do the pin muxing, then that doesn't get applied until the kernel starts, so you've missed the rainbow screen.

[tvjon]

Thank you again for pursuing this James.

Essentially, my posts so far are an attempt to answer:

"What I am looking for...

Any bugs or regressions, anything that works differently than before that
will upset backwards compatibility"

I'm quite sure your fbi example works fine, but really we're already at this stage by sending screen output from certain applications to the desired attached display using

--display n

or hardcoding the display number in applications.

I no longer have a Foundation tft display, so can't test it, but as you have a DPI screen, & HDMI & DSI, can you tell us if all 3 displays can be used simultaneously via the addition of a fb2? If so this advantage would perhaps lessen the impact of going through all existing applicable applications to change the appropriate lines of code.

" I am not sure I will be able to make it 100% backward compatible."

I see.

I also wonder if it's an opportunity to address:

https://github.com/raspberrypi/firmware ... +is%3Aopen

Can a fix for this be incorporated in your code?

@6by9, thank you for that rainbow screen note.

[DougieLawson]

I gave this a try on my RPi3B with the Official LCD. I got the rainbow screen (on both the LCD and the TV) but the boot didn't continue from that point.

That 3B is set-up to boot from a USB stick.

It was already running 4.14.50-v7+ #1122 before I started the experiment.

I may try again with a USB serial console on GPIO14/15 enabled. I should also try a regular SDCard rather than the USB stick.

[jamesh]

I gave this a try on my RPi3B with the Official LCD. I got the rainbow screen (on both the LCD and the TV) but the boot didn't continue from that point.

That 3B is set-up to boot from a USB stick.

It was already running 4.14.50-v7+ #1122 before I started the experiment.

I may try again with a USB serial console on GPIO14/15 enabled. I should also try a regular SDCard rather than the USB stick.

Hmm. Odd. So you just have the LCD and HDMI connected? If you disconnect either does it start up?

Might be related the USB stick startup, difficult to tell, but I would not expect it.

[jamesh]

Just a ping to bring this back to the top - still need people testing this as it's a big change that needs eyes on it.

[LTolledo]

I'd love to join in but I dont have a DPI panel, only HDMI monitors.

Can I do this with a Raspberry Pi model B (HDMI + composite, 512 RAM)?

[macload1]

I have a Pi Zero connected over DPI to a display and could also connect a HDMI display.

Is it possible to charge the system over usbboot (rpiboot) for testing? I don't have any spare SD card.

Best regards,
macload1

[macload1]

Oh, I just saw that this is not for the Zero or Zero W, but only for the multi-core PIs.

Good luck then!

[DirkS]

Oh, I just saw that this is not for the Zero or Zero W, but only for the multi-core PIs.

Where did you see that? AFAIK multiple frame buffers should also work on a Zero...

[procount]

2nd attempt on a more common setup: Pi 3B with 7" RPF touchscreen & external VGA monitor running off VGA-HDMI converter.
Installed latest Raspbian (June 2018) which is already @ 4.14.50+, so no need for rpi-update.
Installed new kernel, start_x.elf and set start_x=1 in config.txt.
Success - 2 rainbow screens with a pinkier one on the touchscreen!

I can use the fbcon:map0/1 cmdline option to switch console screens on startup.
I can use con2fbmap to switch a console to a different screen. I even got 2 consoles up at once - one on each screen.

I copied /usr/share/X11/xorg.conf.d/99-fbturbo.con to /etc/X11/xorg.conf, changing /dev/fb0 to /dev/fb1, but I this doesn't seem sufficient as it does nothing. I guess I need additional screen and monitor sections? Anyone got an example xorg.conf file that works?

A couple of possible issues - If I boot to the cmdline and put the console (TTY1) on the touchscreen (/fb1) then run startx, the touchscreen and HDMI go blank before X starts up on the HDMI (/fb0). When I exit back to the cmdline:
1) the wallpaper does not disappear and it stays on the HDMI monitor.
2) The touchscreen remains black and I am typing in the dark. I know the console is still active because I can run startx again, or I can blindly switch the console back to the HDMI and it is visible again. How can I get the touchscreen display back again?
3) I tried tvservice -p and after doing something else (forgot) managed to get a very high-res screen on the touchscreen which I got sorted with `fbset -g 800 480 800 480 32` But after this, fb0 was now referencing the touchscreen and the HDMI was not accessible.
4) Which fb does tvservice -s relate to?

[Maggard163]

I tried to do this this morning. I have Raspbian installed with NOOBS and updated to the specified version. I am a complete idiot at this stuff but im learning. Im using a LCD monitor with a VGA to HDMI cable and a Kuman 3.5 touchscreen LCD display. Ive had both working but I was using the LCD when I attempted this.

On startup I get the rainbow screen at the monitor, followed by the NOOBS recovery screen, then the screen goes black. The 3.5 LCD has a white screen that never changes at any time. If I hold shift at NOOBS recovery I have access on the monitor but the LCD is still white.

My interest is using the 3.5 screen and having the option to connect a HDMI when stationary without the hassle of switching them manually. Thanks for all the effort.

[ghans]

This is only for the official touchscreen or displays using DPI on the GPIO. All other screens should always have worked in multi-head scenarios already, as long the proper display driver was loaded via devicetree overlays.

ghans

[jamesh]

Oh, I just saw that this is not for the Zero or Zero W, but only for the multi-core PIs.

Where did you see that? AFAIK multiple frame buffers should also work on a Zero...

Correct. It's mostly Videocore changes and that bit of HW is the same across the Pi range.

[procount]

@JamesH - I think there is a problem with the new start_x.elf that prevents it running in a version of Raspbian that is installed via NOOBS/PINN, in my case it is on /dev/mmcblk0p6.
I repeated my 2nd test attempt on the same version of Raspbian, but installed by PINN. Copied over Kernel7.img and start_x.elf. It all works fine on a reboot, until I set start_x=1 and then it doesn't boot. Both screens are blank and the network is not working - no ssh or vnc although they are enabled and tested working before setting start_x=1.

[macload1]

Oh, I just saw that this is not for the Zero or Zero W, but only for the multi-core PIs.

Where did you see that? AFAIK multiple frame buffers should also work on a Zero...

Correct. It's mostly Videocore changes and that bit of HW is the same across the Pi range.

Oh, I was mislead by the first post of this forum entry that stated: "These instructions assume a Pi2B/3B board."

Are the instructions the same for the Pi Zero in the end? Is it possible to upload such a big filesystem over usbboot?

[DirkS]

Oh, I was mislead by the first post of this forum entry that stated: "These instructions assume a Pi2B/3B board."

Ah, yes. Problem is that James only provided a kernel7.img (for Pi2/3).
For Pi1 / Zero you will need kernel.img
So at the moment you cannot test it on these devvices.

[jamesh]

@JamesH - I think there is a problem with the new start_x.elf that prevents it running in a version of Raspbian that is installed via NOOBS/PINN, in my case it is on /dev/mmcblk0p6.
I repeated my 2nd test attempt on the same version of Raspbian, but installed by PINN. Copied over Kernel7.img and start_x.elf. It all works fine on a reboot, until I set start_x=1 and then it doesn't boot. Both screens are blank and the network is not working - no ssh or vnc although they are enabled and tested working before setting start_x=1.

I didn't test it under those circumstance, so possible. Sounds like it simply not booting at all. Probably the start_x.elf is not starting up, or even being loaded. No idea why not.

[procount]

Another difference with this start_x.elf is that it defaults to overscan enabled, whereas start.elf defaults to overscan disabled. I had to force `disable_overscan=1` to make the behaviour the same. (I didn't check if this applies to the original start_x.elf as well). Surely these should be the same, or is there another reason I'm not aware of?

[jamesh]

Another difference with this start_x.elf is that it defaults to overscan enabled, whereas start.elf defaults to overscan disabled. I had to force `disable_overscan=1` to make the behaviour the same. (I didn't check if this applies to the original start_x.elf as well). Surely these should be the same, or is there another reason I'm not aware of?

Hmm. Thought the overscan should be the same as before. I'll need to check.

[procount]

I just used the recent June Raspbian version with no modifications to config.txt, so all overscan settings were commented out.
Using start.elf, resulted in no overscan on the RPF touchscreen.
Just adding start_x=1 with your new start_x.elf resulted in overscan being applied to the touchscreen, so I had to uncomment disable_overscan=1 to get the same behaviour.

[procount]

I copied /usr/share/X11/xorg.conf.d/99-fbturbo.con to /etc/X11/xorg.conf, changing /dev/fb0 to /dev/fb1, but I this doesn't seem sufficient as it does nothing. I guess I need additional screen and monitor sections? Anyone got an example xorg.conf file that works?

I got a bit further using this for /etc/X11/xorg.conf, but the desktop is only visible on one screen, and all it has on it is the wallpaper and a waste basket - no menu or anything else. I can swap it between the screens, but not get both up at the same time.

Code: Select all

Section "Device"
        Identifier      "FBDEV 0"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb0"
EndSection

Section "Device"
        Identifier      "FBDEV 1"
        Driver          "fbturbo"
        Option          "fbdev" "/dev/fb1"
EndSection

Section "Screen"
        Identifier      "VGA"
        Device          "FBDEV 0"
        Monitor         "Monitor name 0"
EndSection

Section "Screen"
        Identifier      "HDMI"
        Device          "FBDEV 1"
        Monitor         "Monitor name 1"
EndSection

Section "ServerLayout"
        Identifier      "Default Layout"
        Screen          0 "VGA"
        Screen          1 "HDMI" RightOf "VGA"
EndSection

[jamesh]

I was unable to get the desktop to stretch over multiple FB's, I suspect they need to be the same resolution.

[Lonerider]

Hello,
tried to test the multiple frame buffers, but failed. What I did:

• - Attached the 7" touch screen and an HDMI monitor to the Raspi.
  - Installed the current Raspbian via PINN (Linux raspberrypi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux
  ).
  - Within the boot directory both files needed (kernel7.img and start_x.elf) are available.
  - Added 'start_x=1' to /boot/config.txt
  - Did a reboot.
  - Only the touch screen shows the desktop, and there is only one frame buffer:

  Code: Select all

   ls /dev/fb* -> /dev/fb0

  .

So am I missing something?

[DirkS]

- Within the boot directory both files needed (kernel7.img and start_x.elf) are available.

That's not very clear. Did you actually replace these with the ones that James provided?