Switching image from LCD to HDMI when connected

[Substring]

I've been using the EDID trick with a geekworm DPI screen for months already ... The problem is that it's the only way to circumvent a flaw in the "bios" design : the Pi can't tell if a composite screen is plugged, or if a GPIO screen is plugged. So making LCD default firces the pi to display on it, no matter if a HDMI screen is available.

The EDID trick is not really satisfying too, because it statically links a screen to your pi. That's ok if ypu always plug your pi on the same screen. But this can not always be the case.

For a trick from within Recalbox : no. That would cause really too many bugs because we'd have to format the config.txt with EDID and all sections, which would then be tricky to debug for non lcd users. You know the trick, manually apply it by yourself

[Coincoin]

@Substring for the "plug'n play on any screen", I think I have a solution, but it would need to find a way to execute a bash script before the config.
So we could dynamically create an EDID= with the name of the HDMI screen obtained through tvservice -n (and also power off the lcd if tvservice give a result with other bsh commands)

I don't even know if this is possible. I'm very noob there.

But I know it's possible to add sub config files with something like "include subconfig.txt", the idea there would be to tvservice -n then create a file with either
[EDID=tv_name_you_got_with_tvservice]
display_default_lcd=0
[all]

Or either
[all]

Name that toto.txt, then put include toto.txt on the top of your config.txt and that should output to any HDMI screen if an HDMI is plugged (and if possible, power off the LCD), or to your LCD if not.

About the stability / usability / speciality to put that in recalbox, I'd agree. The only thing is finding that info was VERY difficult (but once understood, it was so easy). It would be at least a good thing to put in the faq I think.

[Substring]

@coincoin it's all documented at raspberry's official website

[Coincoin]

@substring I agree but why do you say people need noob skills with recalbox then ? It's one or the other ?

[Substring]

@coincoin usng recalbox in a plain and standard way is easy for anyone. Switching between DPI and HDMI the way you'd expect it is beyond what Recalbox does and is, as i said earlier, a flaw in the firmware

[Coincoin]

@substring I don't really understand.
I have maybe 2 full days of googling-fu this problem and nobody clearly wrote "hey guys, here is all the solutions for the dudes that bough the official 7'' screen, are total noobs at raspi, and also use recalbox".

There is no flaw in the firmware. It's by design. The screen have been made by specialists ingeneers that perfectly understand how EDID & low-level drivers works. So to their eyes, it's working flawlessly. You can ouput to whatever thing you like, if you can program before config, the behaviour is like "boot'n play".

If I can find how to do event programing, find the plug HDMI event, threading that with a simple if each second, I could even make that plug'n play, at least in Rasbian. This is what plug'n play drivers does, the only difference is they use interupt drivers level but you can make that easely post-kernel too if you're a raspi noob like me.

(background info : studied electronics, then been in informatics for like 15 years)

[Substring]

@coincoin hey pal get a grip, no need to get on fire that quick.

1. I've never read that thread until i posted a reply, although i had already given the trick on another topic
2. https://www.raspberrypi.org/documentation/configuration/config-txt/video.md is what explains almost everything
3. Not being able to fallback on LCD when HDMI is not available is a flaw in my vision of things. So of course i'm not saying raspberry engineers suck, their work is just amazing. And if you can't have lcd as default when there is no hdmi available must probably have some hardware reasons, i still believe this is a misconception, therefore a flaw.

Now regarding the small code block you're thinking about, i could give you some tips on how to write it, i'm just saying that this is a very particular case which i do not wish to be automatically managed. In other words : i won't work on it, but would gladly accept external contributions and even give a hand.

And my CV is not that different from yours you k ow

[Coincoin]

@substring hey

• I'm not "on fire", it's just I don't have as much vocabulary as I'd want in English + I use lots of shortcuts that do not sound very kind in English (but are ok in French). If I'd be "on fire", usually people knows
• I am NOT insisting on putting this in recalbox. I am insisting on writing a faq item (I'll write it if you want).
• I still don't see any flaw. Are you talking about hot fallback to LCD ? Or on boot fallback ? (which what happens). There is no driver, there : this behaviour is a software behaviour, not an hardware behaviour, so I still don't see any flaw in hardware design (which is where we agree), neither in firmware (that must stay compatible with other outputs).
  I don't understand when you say it's a firmware pb : at much to me, it's a gpu driver problem that don't differentiate this screen from the others ? (which is an advantage, if you watch this with "no diff between screens" eyes).

[Substring]

@coincoin by firmware i mean either the bootcode.bin, or start.elf. one of these files (most probably the first one) is "the firmware", like a bios file, and does the initialization. The pi itself boots on GPU before CPU (yeah yeah, no mistake in what i wrote), the gpu loads the firmware from the sd card ...

Anyway as far as i remember, once you have booted, you can't switch to another display type, tvservice doesn't help, which is a pity.

[Coincoin]

If it boot on gpu, then everything is explained ?
"don't take any risk (see what I did there ?) with the booting chip" on top of "things must not be peripherical dependant" which combos in "booting chip must not be peripherical depending"

This booting on gpu is surprising, but not totally from outer space when you considering pi's ARM nature
@Substring

I think it's possible to achieve what your usual computer does. There's no impossibility, but a lot to learn before doing that : to do this right, you must take this before kernel. I would have to document myself on that before coming with questions. IRQ is already little known territory to me, but ARM board IRQ may be very much alien space in my Windows guy's eyes : I learnt how from a pile of sand making something this is driven by hardware or asm drivers 20 years ago, there should be remains