Multiple framebuffer support - testers wanted

[jamesh]

Hello all,

I'm at the point of releasing a very beta version of the multi framebuffer support I have been looking in to.

This provides for having 2 or more frame buffers (max 4), one for each display device attached. So for example, /dev/fb0 would be allocated to the HDMI, and /dev/fb1 would be allocated to the LCD display. I've not tried it with composite or DPI but both should work (basically anything that attaches to the GPU - USB or SPI attached screens usually supply their own fb device so should not be affected by this change)

This means you can have a console on one display and be writing to the other display using standard Linux tools (e.g. fbi -d /dev/fb<x>). You can swap consoles from one to the other as well (using con2fbmap 1 <displaynum>)

Would anyone be interesting in beta testing? You will need to build your own kernel and modules, and be able to install them on an SD card. There will also be a new firmware (start*.elf) required.

You can already see the kernel changes in this branch on my github https://github.com/JamesH65/linux/tree/multiFB_pr

I can supply firmware on demand.

What I am looking for is any unexpected changes in how things have worked in the past - it should, on the whole, be backwards compatible. Also be interesting in getting X working over multiple displays - I wasn't able to get it working in my quick attempts.

James

[jamesh]

No-one?

All my efforts in vain then.....

[Heater]

Not in vain at all James.

It all sounds great and I'd love to give it a spin. Finding the time is the problem.

What I'd really like is to be able to render multiple frame buffers at the same time, from different programs, and then be able to tab between them on the same display. Perhaps that is already possible, I have not looked into it.

What would be really great is being able to render Chrome into a frame buffer, full screen, without any X involved.

[karrika]

I believe that the natural setup would be to have a 7" touch screen for entering commands and use a HDMI screen for output.

Actually I have already tried this with omxplayer as you can re-direct the video to the 2nd screen.

There is a few applications where I see this as a very good thing.

The QLC+ already has the capability to play video on the HDMI interface while the virtual console is run on the 7" official display.

But it would be a very good thing to be able to swap the screens. When you are planning your show you could use a full screen HDMI display to fine tune the lights and sound. And the video playback would go to the 7" screen.

The only problem with QLC+ is that I am in the middle of our performing season so my PiZero + AudioInjector + DiscoCap + 5" touch screen is happily providing lights and sounds almost every evening while I am on stage. So not much time to play with the code before the performing season is over. I already have a new Pi3B+ and plans for a new DiscoHAT. This dual display thing would be a great addition to that setup.

I also love the Fruitbox software with the old Jukebox skins. It would be cool to have a second screen for album art and video. Perhaps a second 7" screen just below the official 7" screen.

The 3rd project I am involved with is the RPi-InfoScreen project. As it is based on Kivy it should already support more than one screen. I just have not had the time to test it yet.

But having up to 4 screens is definitely a very good thing. Several small conning displays for gyro, log, wind, thrust would be great with a low-power Pi.

Here is a small example of what I have in mind... OpenGL rendered analog displays...

[bensimmo]

Quick one, could you test with the SenseHAT.
Only because it uses /dev/fb1 iirc.

[rotwang]

No-one?

All my efforts in vain then.....

Your efforts will, eventually, be greatly appreciated, you may need to be a little patient.
If only I could have a cross-compiler setup that worked on my desktop machine (8 cores, 64bit, great gobs of memory and disc) I'd be delighted.
If anybody comes up with a built kernel, and associated boot stuff then I'll give it a go. I have in mind a very specific setup involving OpenOffice Impress and using the built in display manager to get presentation via hdmi to a projector, with control on the rpi DSI display.
Roger

[jamesh]

Quick one, could you test with the SenseHAT.
Only because it uses /dev/fb1 iirc.

If fb1 is already in use, I suspect that the SenseHAT would move to fb2, probably depends on initialisation order. I'll see if I can find one in the office to test though. Might be a bit awkward because of using the header for powering the LCD, but need to be tested.

EDIT: Yup, sense HAT appears on /dev/fb2

[Ultibo]

Would anyone be interesting in beta testing? You will need to build your own kernel and modules, and be able to install them on an SD card. There will also be a new firmware (start*.elf) required.

You can already see the kernel changes in this branch on my github https://github.com/JamesH65/linux/tree/multiFB_pr

I can supply firmware on demand.

Hi James,

I'm happy to test the new functionality under bare metal, have HDMI, official 7" LCD and composite displays available (nothing on DPI at this point).

Since our code also has OpenGL ES we can test with that overlaid on the different displays as well.

If you can supply a link to the updated firmware I can pick out the changes from your GitHub branch to make it work.

Cheers,

Garry.

[jamesh]

Would anyone be interesting in beta testing? You will need to build your own kernel and modules, and be able to install them on an SD card. There will also be a new firmware (start*.elf) required.

You can already see the kernel changes in this branch on my github https://github.com/JamesH65/linux/tree/multiFB_pr

I can supply firmware on demand.

Hi James,

I'm happy to test the new functionality under bare metal, have HDMI, official 7" LCD and composite displays available (nothing on DPI at this point).

Since our code also has OpenGL ES we can test with that overlaid on the different displays as well.

If you can supply a link to the updated firmware I can pick out the changes from your GitHub branch to make it work.

Cheers,

Garry.

Cool. I'm just fixing up some stuff that was brought up in a code review, hopefully by end of week - one thorny issue to do with display numbering and maintaining backwards compatibility. (and off next week, so if I don't get it done this week there will be a delay)

There's a few new mailbox calls for determining number of attached displays and getting their parameters, plus telling the existing mailbox functions which display to act on. Should be fairly easy to comprehend.

[sharkman]

Hi James,

Has playground development progress stopped with the multi framebuffer support on the Pi?

I ask, as I've just purchased a Waveshare 3.5" LCD+Touch display that works fine on the Pi.

Albeit working, the intention in using the Pi, is to be able to develop software using the Pi with a HDMI screen, and use the LCD/TFT (touch) as a 2nd display for applications that can use such a small display.

Regards,

Steve

[jamesh]

See this thread

viewtopic.php?f=63&t=216399&sid=4658a6b ... 28cae1209b