@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

Hello,

Plutôt que d’appeler ce sujet PiPi, j'ai préféré l'appeler Pi², vous allez comprendre.

Je me demandais s'il était possible de mettre en réseau deux Raspberry Pi pour faire tourner une recalbox, et ainsi bénéficier de plus de patate pour l'émulation, ou si c'est une impossibilité technique totale ?

Merci pour vos réponses !

La télé est le seul écran branché sur le pi ?

@substring said in Feature Suggestion: Game played (Marker):

@tormentor667 2 icons would mean rewriting ALL themes

1 icon. 3 images.

@toxicooow this is plugged through i2c on GPIO, not another bus ?

Juste pour dire que j'ai des couilles d'apairage moi aussi, depuis que j'ai fait la dernière mise à jour quand j'ai commencé à mettre le rpi sur le réseau wifi (mais la maj est peut être une coïncidence). Je n'ai pas le système depuis longtemps, j'ai eu mon rpi 3 pour Noël

Je ne peux simplement plus jouer en Bluetooth avec une manette de PS3. Et je galère pour que la manette soit reconnue même en filaire (je remap les boutons à chaque redémarage, et ça marche une fois sur deux environ).

Avant, je faisait un truc du style en passant par le dongle bluetooth du clavier =>

• remap de bouton, puis au premier screen la manette était trouvée en filaire, je faisait croix puis rond pour revenir.
• appairer une manette, ça foire, puis rond et débranchement et ça marchait (si ma mémoire est juste).

Là, le remap marche donc une fois sur deux et j'ai bien du essayer 20 fois d'appairer, sans succès. Même en oubilant le bidule, redémarrant, appairer, que dalle.
C'est pas si grave (je suis à l'ancienne, j'ai pas pris l'habitude de jouer en BT) mais bon.

Yeah, you should try to use RCA cable like here I guess. I think there's a problem of bandwidth : a 800*600 CRT screen have 480k pixel. A pixel use 24 bits of information.
If you want 30 images per second that is 480000 (all pixels) * 24 (bit per pixel) * 30 (images per secodns) = 345 600 000 bits per second aka 345.6 Mbps.
This is meaning you need at least a category 6a copper pair cable.

I'm making assomptions, but if it's just a cheap chineese copper pair, then you will have LOTS of white noise, because of physical stuff I don't want to bother you with.
You would have white noise in the image and in the sound (white noise in image is your classic CRT "snow", and white noise in sound is the sound from that snow screen).
In the image, it's a pixel or another that won't be displayed for 1/30 of a second, you just would notice a bad image stability/quality. But for sound you would hear that very clearly, because it's a 1D signal. This would be "either signal is ?wtf? either it's ok", instead of "just THAT pixel for a 1/30 of a second", in burst.

(sound on top is just about +1Mbps (+192Mops, but I'm really not sure here), this means 6a is still ok. 6a was made for video anyway.)

Check with a RCA (that one), or 2x 6a pair !

Oh, and honestly, I'd also try to stay with PAL instead of NTSC. It's better for signal/noise, and it seems this is your main problem there.

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

@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 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 I agree but why do you say people need noob skills with recalbox then ? It's one or the other ?