Switching image from LCD to HDMI when connected

[Coincoin]

@coincoin said in Switching image from LCD to HDMI when connected:

@jidem Bah ça boot avec la sortie HDMI si c'est branché, sinon, ça boot sur le LCD.
Je me prennais la tête franchement en me disant "mais si j'essaye, ça va sortir re-inversé verticalement" mais non !

Donc il suffit de coller la ligne qui va bien pour inverser l'écran, et celle -là pour que ça marche parfaitement. Maintenant, le truc casse-pied, c'est le petit écran qui est allumé en noir pendant la sortie HDMI, je crois que je vais être obligé de bricoler un interrupteur comme toi, mais j'ai pas envie...

-edit- ah si : au début, y a NOOB qui sort àl'envers sur le 7''. Tu choisi recalbox et après ça sort en HDMI dans le bon sens.

==> translation because it seems I can't edit after one hour :
Well, it's booting with the HDMI output if it's plugged in, otherwise, it's booting on the LCD.
I was frankly thinking "but if I try, it's going to come out inverted vertically" but no!

So all you have to do is paste the line that goes well to invert the screen, and this one will work perfectly. Now, the puzzling thing is the small screen that is lit in black during the HDMI output, I think I'm going to have to tinker with a switch like you, but I don't want to...

edit- oh yeah : at first, NOOB comes out upside down on the 7''. You choose recalbox and then it comes out in HDMI in the right direction.

[jidem]

@coincoin OK, I found it:
SCL to the third pin down on the left hand side, and
SDA to the second pin down on the left hand side.
Please can you try to boot without SDL et SDA wires connected to see what happens? If it doesn't work, I purchase 2 wires!
Thanks by advance!

[Coincoin]

If the 7'' screen is in normal position on your table (HDMI output on top) :

• on the GPIO all thread are in a square shape :

• first line, from right to left, nothing / pin / pin / nothing / nothing / ... / nothing
• second line, from right to left, nothing / pin / pin / nothing / nothing / ... / nothing

Ok.
Now if you look this square shape : top left, I have yellow, top right blue, bottom left is black, then I have red.

On the screen, there is 4 (if I remember ?) pins which are from left to right : black yellow green red. So yellow & green use the two spot between your typical 5v/GND (which if I done things right, are red / black in what I did).

I really can't find the documentation, but the color of these threads are typical of I/O lines (so that's why I'm telling this is it).

[Coincoin]

@jidem you're right, this is an easier test => well

"SDL and SDA wires" unplugged :

+HDMI plugged in :

• NOOBS boot on 7'' upside - down.
• Rasbian boot on HDMI with the good inversion
• Recalbox boot on HDMI with the good inversion

+HDMI not plugged :

• NOOBS boot on 7'' upside - down.
• Rasbian blackscreens
• Recalbox blackscreens

"SDL and SDA wires" plugged :
+HDMI plugged in :

• NOOBS boot on 7'' upside - down.
• Rasbian boot on HDMI with the good inversion
• Recalbox boot on HDMI with the good inversion

+HDMI not plugged :

• NOOBS boot on 7'' upside - down.
• Rasbian blackscreens (in fact, it outputs on HDMI, because when I plugged it after boot, I see some sort of 4/3 desktop on my 1080p TV)
• Recalbox blackscreens (in fact, it outputs on HDMI... same. Same 4/3.)

Blackscreens with unwired should be the same I guess.

D**n. It's been two days I play on TV thinking this was a solved problem :3

[jidem]

@coincoin thanks for your tests!
And sorry for the results...
that's confirm my previous tests...

[Coincoin]

Which are "display_default_lcd=0" disables LCD instead of making HDMI default ?

I must try removing those from the recalbox config file, and the rasbian config file, and only rely on the NOOBS config file.

I saw while browsing recalbox that some line are added by NOOBS... There should be a conflict somewhere (including @Nijate orignal problem).

This is really really bothering. We have all the commands that does things right, and none can be used there.

[Coincoin]

@jidem NOT YET, SNAKE, IT'S NOT OVER YET!!

I can make it boot with Rasbian on HDMI or 7'' whether the HDMI is plugged or not

I'm making more tests to be sure.

[Coincoin]

@jidem @Nijate and....... bingo.
I've got it, I'm so happy.

First, you need to know what is the name of your HDMI screen. For that, plug HDMI, boot, then open console (for exemple in Rasbian) then type :
tvservice -n
(tvservice works too with a recalbox console : I say that because I'm a total noob in Linux and I think I'm not alone)

=> this will give your TV name like that :
device_name=THIS_IS_YOUR_TV_NAME

Note that name on paper (or take a photo : mine was SNY_SONY-TV, and never could remember if - was before _)

Then, open config.txt in Rasbian and on the very very top of the file, you put those 3 lines :

[EDID=THIS_IS_YOUR_TV_NAME]
display_default_lcd=0
[all]

What will happen there is when the Raspi detect on boot the TV, then it will use the next lines in the config.
Then it found the [all] filter that is used by default when there is no filter.

Therefor, display_default_lcd=0 will only be used when my TV is plugged on boot. Since that line happens to make the output on the HDMI, this is perfect : when HDMI is plugged, then the raspi will boot on HDMI else, it will boot on LCD.

Ok. This is not finished. This will only work with Rasbian.
You have to go in recalbox's /boot, and copy the same 3 lines on the very top of your config.txt file there so recalbox boot with the same behaviour.

It s NOT finish... I know there is a config command to power off the lcd. If you find it, you can put this between the [EDID=...] and the [all] filter so it power off the LCD if you use the HDMI output.

I think this is the solution !
(also, @Substring if this is the real solution and that does not work only for me, this could be automated in recalbox ? before the boot, use tvservice to know if something is plugged and [EDID=that stuff] then [all] the rest of the config file)

The solution was REALLY simple in fact. So simple that it's hard to notice just under our noses

[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