run the HDMI and TFT screen simultaneously

[galelio]

I have been looking everywhere to solve my problem but couldn't find a solution so i thought i might ask here.

I would like to run both screens Touch screen (DSI) and the hdmi at the same time, however i can only find one framebuffer /dev/fb0

is there anyway to add a second framebuffer? adding an additional driver? modify the kernel? i don't know

if someone could help me i would really appreciate it.

Thanks

[jamesh]

AFAIK, its one or the other. But I cannot remember why. I'll take a look on Monday since I have been dabbling in this area for other reasons.

[galelio]

Yea i can switch between the 2 screens just fine, it a matter of where the /dev/fb0 is pointing, but i was hoping to have a second framebuffer to write to both of them simultaneously.

i know that some apps like omxplayer can write to the HDMI directly while the TFT is active and responding, so it feels like its a software problem not a hardware.

[k-pi]

From https://community.nxp.com/thread/462751

Victor Linnik Employee Oct 24, 2017 11:59 PM

You can use fbset utility to manage framebuffers.

Have a great day,
Victor

This may also help.
http://www.tldp.org/HOWTO/pdf/Framebuffer-HOWTO.pdf

[jamesh]

From https://community.nxp.com/thread/462751

Victor Linnik Employee Oct 24, 2017 11:59 PM

You can use fbset utility to manage framebuffers.

Have a great day,
Victor

This may also help.
http://www.tldp.org/HOWTO/pdf/Framebuffer-HOWTO.pdf

The issue is that the underlying boot code enables a framebuffer to HDMI or a framebuffer for DSI, but not both. So standard Linux stuff won't help.

[galelio]

From https://community.nxp.com/thread/462751

Victor Linnik Employee Oct 24, 2017 11:59 PM

You can use fbset utility to manage framebuffers.

Have a great day,
Victor

This may also help.
http://www.tldp.org/HOWTO/pdf/Framebuffer-HOWTO.pdf

from what i understand is that you can use fbset to manage the current framebuffers but not to add one.

[Morphology]

You can mirror one to the other using raspi2fb:

Code: Select all

git clone https://github.com/AndrewFromMelbourne/raspi2fb.git
cd raspi2fb
mkdir build
cd build
cmake ..
make
sudo make install
sudo cp ../raspi2fb@.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable raspi2fb@1.service
sudo systemctl start raspi2fb@1

[topguy]

i know that some apps like omxplayer can write to the HDMI directly while the TFT is active and responding, so it feels like its a software problem not a hardware.

Or more likely somewhere in between, firmware. My guess is that at least you will need some support in the kernel for two framebuffers. And there might be performance issues with having two.

What exactly do you want to do ON those screens ?

[galelio]

i know that some apps like omxplayer can write to the HDMI directly while the TFT is active and responding, so it feels like its a software problem not a hardware.

Or more likely somewhere in between, firmware. My guess is that at least you will need some support in the kernel for two framebuffers. And there might be performance issues with having two.

What exactly do you want to do ON those screens ?

i guess you are right, its probably a firmware problem, am writing a software where you can manage it from the TFT screen and gets the output on the hdmi (not mirroring), but so far am not able to do that. hopefully there will be an update to the firmware where it supports 2 framebuffers.

[jamesh]

OK, so with the current driver, we are unlikely to support this. However I believe the new ARM side graphics driver (enable with raspi-config) DOES support twin screens like this. So that might be an option.

[topguy]

i guess you are right, its probably a firmware problem, am writing a software where you can manage it from the TFT screen and gets the output on the hdmi (not mirroring), but so far am not able to do that. hopefully there will be an update to the firmware where it supports 2 framebuffers.

We have verified that both "Kivo" (Python) and "Qt5" (C++) are able to use the second screen, so if your "output" can be presented using any of those frameworks you could achieve this today.

[jamesh]

After more discussion, it appears we may well spend the time and effort to make the current graphics system multiple screen, in addition to the new driver. No idea of the feature set yet, and it won't appear overnight!

[galelio]

OK, so with the current driver, we are unlikely to support this. However I believe the new ARM side graphics driver (enable with raspi-config) DOES support twin screens like this. So that might be an option.

Thanks for your help, however i am not sure how to enable the new ARM graphics driver, do you have any instructions, i cant find it in the raspi-config.

[jamesh]

OK, so just found this out and not tried it.

sudo raspi-config

select advanced options and find the graphics driver option. Select KMS option. (not fake KMS)

Now it should start up with the display running on HDMI and DSI.

You can apparently control it with xrandr and KMS ioctls. That's the bit I don't know about yet.

[galelio]

OK, so just found this out and not tried it.

sudo raspi-config

select advanced options and find the graphics driver option. Select KMS option. (not fake KMS)

Now it should start up with the display running on HDMI and DSI.

You can apparently control it with xrandr and KMS ioctls. That's the bit I don't know about yet.

Thank you, i will check that

[juj]

The fbtft project ( https://github.com/notro/fbtft ) does create a framebuffer for the second SPI display. This framebuffer appears as /dev/fb1 whereas the main HDMI display appears as /dev/fb0. These can be driven separately with separate contents, or one can use a mirroring technique to continuously copy contents of /dev/fb0 over to /dev/fb1.

A generic mirroring driver for /dev/fb0 -> /dev/fb1 copying that builds on notro/fbtft is available at https://github.com/tasanakorn/rpi-fbcp . I have been developing a custom mirroring driver specifically for ILI9341 displays: https://github.com/juj/fbcp-ili9341

It should be noted that due to software problems, performance and/or power efficiency is not great. The fbtft driver is inefficient because it operates on page faults, which has the convenience of being generic, but is not a good abstraction for performance. The mirroring driver has this issue as a major power drain: https://github.com/raspberrypi/userland/issues/440 . If that was resolved in the DispmanX driver, it should be possible to write quite power optimal mirroring drivers. If you are planning not to mirror the contents, then the above issue is avoided. In that case, you can mmap /dev/fb1 to write pixels to the SPI display.

EDIT: re-reading the thread, I realize this question was about a MIPI-DSI connected TFT display rather than an SPI based TFT display.

[jamesh]

The fbtft project ( https://github.com/notro/fbtft ) does create a framebuffer for the second SPI display. This framebuffer appears as /dev/fb1 whereas the main HDMI display appears as /dev/fb0. These can be driven separately with separate contents, or one can use a mirroring technique to continuously copy contents of /dev/fb0 over to /dev/fb1.

A generic mirroring driver for /dev/fb0 -> /dev/fb1 copying that builds on notro/fbtft is available at https://github.com/tasanakorn/rpi-fbcp . I have been developing a custom mirroring driver specifically for ILI9341 displays: https://github.com/juj/fbcp-ili9341

It should be noted that due to software problems, performance and/or power efficiency is not great. The fbtft driver is inefficient because it operates on page faults, which has the convenience of being generic, but is not a good abstraction for performance. The mirroring driver has this issue as a major power drain: https://github.com/raspberrypi/userland/issues/440 . If that was resolved in the DispmanX driver, it should be possible to write quite power optimal mirroring drivers. If you are planning not to mirror the contents, then the above issue is avoided. In that case, you can mmap /dev/fb1 to write pixels to the SPI display.

EDIT: re-reading the thread, I realize this question was about a MIPI-DSI connected TFT display rather than an SPI based TFT display.

I've been pondering the issue on github, and I am not sure its possible. Will have a lok though when trolling bout all this other display stuff that needs sorting out.

[JasonY00]

SInce a company I was going to use for a multi room A/V system went bust I have been looking around for a low cost solution (that I could build and maintain) to fill the void.

I would love to have a setup in each room with the PI mounted in a wall behind the Official Raspbery Pi DSI touch screen. It would be used as a touch screen remote (running something like KODI) and pass the video output to a HDMI TV/Projector in the same room. Idelly I would also like to hook the audio output (maybe via an expansion audio/amp into some in ceiling speakers. The final touch would be to take a local audio source and also "pipe" it though the in ceiling speakers. Such a setup would do all of the things I was going to pay $1000's for in a fraction of the budget.

The first step is to be able to have the PI output two seperate screens (say Kodi on the DSI) and a movie on the HDMI screens.

I hope you clever people at Raspberry Pi or one of the forum contributors who are much smarter than me could acheive this!
I will happily wait for as long as it takes as "beggers can't be choosers".

It would open up a great new way to leverage the Pi into awesome cheap and highly customisable multiroom AV devices!

Many thanks

Jason

[jamesh]

This is being looked in to.

Note you can already specify the display for video output when using omxplayer, (ie desktop on LCD, movie on HDMI) not sure when using Kodi though.

[JasonY00]

Thanks for the reply Jamesh,

I couldn't seem to get OMXPlayer to work on the HDMI...but its most likely me and not the Pi...

I had conflicting instructions as to whether to use an equals sign. i.e.

omxplayer --display=5 video.mkv From Raspberrypi.org, or
omxplayer --display 5 video.mkv from omx player help. where "video.mkv" was various movie formats

Both times all I ended up with was the "Have a nice day " signoff from OMXPlayer command line and no video on the HDMI interface.

I will have another go though. I do love a challenge...

Kind regards

Jason

[JasonY00]

I have also tried to emulate the Youtube clip found here

https://www.youtube.com/watch?v=zzugiIN ... e=youtu.be

that describes how to run the Pi with a HDMI monitor and LCD TFT at the same time in different modes via the “/etc/X11/xorg.conf.d/99-fbdev.conf” file modification.

It seems promising, but I am not sure if the LCD is of the DSI type. I am also having a go at this option...

Cheers

Jason

[luis1761]

OK, so just found this out and not tried it.

sudo raspi-config

select advanced options and find the graphics driver option. Select KMS option. (not fake KMS)

Now it should start up with the display running on HDMI and DSI.

You can apparently control it with xrandr and KMS ioctls. That's the bit I don't know about yet.

This worked for me just now. Thanks

[djtommye]

This may require a new thread, but seems like a relevant question...

I do A/V installs and get tired of dragging out a laptop to test HDMI connections. I have the PiTFT Toucscreen, and would love to create some kind of "desktop" shortcuts that display on the screen and simply run some omxplayer scripts to output to the HDMI. This way, I can display color bars, a focus grid, etc on the output of the RasPi easily enough.

However, I'm pretty new to RasPi and I'm not sure where to start. I guess the first question is - CAN I drive content to the HDMI via omxplayer, while showing X on the TFT?

Thank you in advance!

[jamesh]

See here for new multi FB support

viewtopic.php?f=63&t=216399

[Vicky P]

I have tried the sudo raspi-config/Advanced Optionsd/GLDriver KMS option. When fullKMS is enabled, the monitor works and when fakeKMS is enabled, the touchscreen works. However, the touch part works even if the touchscreen display is off. Not both of them at the same time. I use this because I am legally blind and use a regular monitor to read fine print and the touchscreen for everything else.