Actions
Forum Thread Details
  • State Suggested Answer
  • Replies 25 replies
  • Answers 6 answers
  • Subscribers 309 subscribers
  • Views 12871 views
  • Users 0 members are here
Related
See a helpful answer?

Be sure to click 'more' and select 'suggest as answer'!

If you're the thread creator, be sure to click 'more' then 'Verify as Answer'!

How to run HDMI and Official Raspberry Pi Display (DSI) simultaneously?

Former Member

Hallo  to all RPi lovers,

I've been trying for a while to clone the video from Official Raspberry Pi Display (connects through DSI) to the HDMI display. Both work fine when alone but not together.

I am pretty much sure, that it is possible from hardware side, as the omxplayer can play video, on HDMI display, while DSI Display is on and functioning.

Looking deeper in the problem I am able to state following:

1. Raspberry Pi doesn't create a framebuffer for second device, there is only /dev/fb0, no matter how many monitors are plugged

2. As the consequence of first, fbcp and other tools, that can play with framebuffer around, won't work.

3. As far as I understood the module bcm2708_fb is in charge of HDMI framebuffer however here is the lsmod:

Module             Size  Used by
cfg80211         419759  0
rfkill            16659  2 cfg80211
bcm2835_gpiomem    3023  0
evdev             10226  6
joydev             9047  0
snd_bcm2835       19739  3
snd_pcm           74833  1 snd_bcm2835
r8712u           167991  0
snd_timer         18164  1 snd_pcm
snd               52116  9 snd_bcm2835,snd_timer,snd_pcm
uio_pdrv_genirq    2966  0
rpi_ft5406         2826  0
uio                8228  1 uio_pdrv_genirq
rpi_backlight      1988  0
i2c_dev            6040  0
fuse              81721  3
ipv6             341380  30

 

and modprobe  bcm2708_fb gives in dmsg following error:

 

[ 3597.206111] bcm2708_fb soc:fb: Unknown ioctl 0x40187a22

[ 3721.217242] bcm2708_fb soc:fb: Unknown ioctl 0x40187a22

[ 3757.719256] bcm2708_fb soc:fb: Unknown ioctl 0x40187a22

[ 3881.152850] bcm2708_fb soc:fb: Unknown ioctl 0x40187a22

Just to imagine here is a part of config that defines the device:

 

Section "Device"

        Identifier      "Allwinner A10/A13 FBDEV"

        Driver          "fbturbo"

        Option          "fbdev" "/dev/fb0"

 

        Option          "SwapbuffersWait" "true"

EndSection

 

But Xorg configuration is the least of the Problem.

 

Would be happy to get any advices or questions and thanking for them in advance.

 

 

PS. To use built-in RCA, GPIO-VGA adapter, USB external graphic cards is not an option. Aim is stable and clear - to clone HDMI and DSI

The Device is Raspberry Pi 2, (Jessy and Wheezy)

 

PPS. Is there is the way to input code here as code with no highlighting?

Parents Reply Children
  • 0 in reply to shabaz

    Shabaz are you sure that it is not possible changing the X11 Linux settings? I think - not yet tried - that the HDMI screen can be saw as a second display...

    If possible it will be great, don't you think it its the worth to investigate in this direciton ?

  • 0 in reply to shabaz

    (sorry for this fragmented post...) The reason of my suspects just originate from this Wikipedia article: https://en.wikipedia.org/wiki/Display_Serial_Interface So, as the LCD is as a matter of fact a serial display interface, it should not impact with the HDMI output if there are not some specific hardware impeachment.

     

    Enrico

  • 0 in reply to shabaz

    Again ... This guy provided a tutorial on youtube (but there are the no-video links for more details here: https://www.youtube.com/watch?v=dTcU5YSq-Ww In this case he used two videos instead of the alternate standard displays of the RPI

     

    Also this usage of the GPIO to drive a VGA (from Hackster.io) sounds interesting... Raspberry Pi Gets VGA, Dual Screen Support | Hackaday

    ... and here (better explained): Adding a second display to your Raspberry Pi just got much easier - Geek.com

     

    Enrico

  • 0 in reply to balearicdynamics

    Hi Enrico!

     

    In theory it is possible, but according to the doc from Gert (who worked on the Pi at the RPF) "In contrast to the composite video, the DPI interface can be run independent of the HDMI" and he says the code would be available in a few weeks (this was in Sep 2014). I don't know if this code is now in Raspbian or not, but the composite video doesn't use the DPI interface. I'm unsure of all the combinations that will work (maybe we should start writing a table with the combinations and the notes for each one, as a reference - I'm surprised this doesn't exist, if you think this is worthwhile let's start one in a Jive document, maybe together we can determine most of the display technologies that exist out there, and then we can search for references to the various combinations),  the one that is specifically said to not provide dual desktop or desktop extension or general app running (unless the application is coded for it), is HDMI and DSI (e.g. Pi official 7" capacitive display) according to here: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=120541

    until a second framebuffer is implemented for the DSI (I've not heard that this has been implemented, but things could have changed).

    So, for the same reason (but I have not tried), Composite and DSI together would behave the same, because for a desktop or general application display the composite requires the framebuffer too, and a second one isn't implemented for the DSI.

    But, as you say, there are other ways to get dual displays, for example VGA and HDMI if that future code change mentioned in 2014 has been made, or the dual displayLink method in that other video. I didn't know these methods were possible, this is good to know. I think we do need a table : (

  • 0 in reply to balearicdynamics

    To complicate matters further, there is the text here:

    https://www.adafruit.com/products/2453

    According to that, Adafruit's DPI display doesn't simultaneously work with the HDMI output. So we also can't assume that if the DPI based VGA functions with HDMI, that other DPI displays will work with HDMI : ( Looks like the code implementation for enabling DPI based VGA might have been very specific or implemented a framebuffer that Adafruit for some reason decided to not use? I have no idea to be honest.

    So many combinations : (

  • 0 in reply to shabaz

    Hi Shabaz!

     

    You put more light on this interesting problem. The dual HDMI-VGA remain, in my opinion a good idea for a lot of applications. What I know instead - but it is interesting your citation (from 2014, so it's referred to the Jurassic-PI) about the availability of this code. My bare intuition is that as the 7 inch lcd is serial, despite what is the Kernel driver if uses a totally different image managing approach than the HDMI signals. But - if I am not wrong - one limitation, a serious one, can depends on the use of the same SPI ports and in this case there is not option to make both working together. I think that some more investigation on the drivers behaviours maybe extremely useful. Consider this fact: if you connect an HDMI display the 7inches display stop working, and if you disconnect it, it starts working again. No setting should be changed, no hardware impact when the two devices are connected at the same time. So it is probable that all it is a question of software...

     

    Enrico

  • 0 in reply to shabaz

    I think that there is a way to check if at least it is possible to have one case with two stuff working on two display. The trick is the display default read on startup by the system. After the 7 inches touch installation it is recognised as the default display; but we can decide what is the default one in the config file, setting the parameter

     

    display_default_lcd=0

     

    Well, so we can decide by software what is the display managed. In addition to this I see that there is a bridge (hardware) that send the main screen buffer to the desired display (I am not sure but the chip should reside on the Pi board as it is the board that support the three formats VGA, HDMI and DSI. But Xorg has a lot of settings adapting to a wide range of video and screen configurations.

    I think that the test should be something like extending as much as possible (128Kb or more, up to 256 Kb) the video memory as the Pi shares the video memory with the rest of the system.

    Then - another intuition, note verified - I suppose that if we can set the default output screen this means that for sure the system on boot and when running recognise not only the display we are seeing something but both ones. Can't be different, I say.

    Now, if my thoughts are correct, the problem is limited to setup some kind of software, driver etc. to manage also the non-default screen.

     

    The test of what supposed above is almost easy: there is omxplayer, a video player designed for the Raspberry PI supporting a lot of features including the display selection, despite on what is the selected default. If it is possible to play two different videos simultaneously on the two screens... Bingo!.

     

    Then there is the rest of the solution. If someone has the option to make this test and the results are positive, it is the worth to try the next step.

     

    Enrico

  • 0 in reply to shabaz

    Hello Shabaz, sorry for my bad mood with Adafruit but their approach is too "ada-product oriented" to be reliable in my opinion.

     

    Enrico

  • 0 in reply to balearicdynamics

    Hi Enrico,

     

    Exactly that, it is all driver limitations, not hardware related at all. In fact the Pi is pretty good at having all the display possibilities. The dual combinations are mostly resolvable as a result, but not all supported today.

  • 0 in reply to balearicdynamics

    I think (according to a link earlier) omxplayer is a special exception, it is specifically coded to allow use of a second display. Otherwise, the standard way would be to have code implemented (i.e. a driver) to write to the display based on what is dumped to a framebuffer. This means that any application could output to the display, since the framebuffer is a standardised way (anyone can just write to the framebuffer, without knowing the display low-level details). Any text or graphic API command (from any graphic library for example) would eventually write to the framebuffer. Problem is, today only one framebuffer gets created if there is a DSI display attached, and it can be chosen to be the DSI or the HDMI. So, this means other apps that want to talk to other display can't use the standard method, so have to be specially coded : (

    This is my laymans understanding based on the RPF link earlier, I could be totally wrong.. In some brief earlier experiments with framebuffers, I was able to just write any random values to it, which is pretty handy when you want to do overlays : ) For that, I had no need to understand the low-level display comms, or whether it was DSI, SPI, DPI, HDMI and so on. This is still fairly low-level of course, ordinarily some graphics library would be used.

    If the user is willing to directly write to a display (i.e. even lower-level) then that is possible (e.g. one can do that with an SPI display by writing SPI data) but then involves specifically coding for it, and knowing detail about the display protocol or chipset etc.