search

libretro / Lakka-LibreELEC

Lakka is a lightweight Linux distribution that transforms a small computer into a full blown game console.
https://www.lakka.tv
1.76k stars 289 forks source link

Raspberry Pi Composite (3.5mm) output broken #1290

Closed jayare5 closed 3 years ago

jayare5 commented 3 years ago

There was a PR that was expected to fix it here but it didn't seem to work:

https://github.com/libretro/Lakka-LibreELEC/pull/1273

@dmrlawson, I tested both Pi3 and Pi4 (with enable_tvout=1) and they don't work. However, I know they're outputting something because the TV detects the signal, but it's black. Using sdtv_mode=16 actually works, and gives a 240p signal, so I know the Pi4 has enable_tvout working, but it's all black.

Thanks!!

dmrlawson commented 3 years ago

I think I've got a cable I can use to look into this, I just need to find some time.

I suspect it's one of:

Hiki1 commented 3 years ago

I've retested this issue on Pi3 and Pi4 with Lakka 3.0 stable and unfortunately it still does occur.

gouchi commented 3 years ago
dmrlawson commented 3 years ago

We're using a commit later than that in Lakka 3.0, do we still need to enable something?

gouchi commented 3 years ago

It seems it needs some testing according to this thread.

I don't know if something else is needed more than RPi linux kernel and firmware updated and enable_tvout=1.

Ntemis commented 3 years ago

@jayare5 please test 3.1 release

jayare5 commented 3 years ago

@Ntemis Tested! Unfortunately still broken.

gouchi commented 3 years ago

I see that there is also this PR , not sure if it is needed for this issue.

jayare5 commented 3 years ago

@gouchi Can it be used to test?

gouchi commented 3 years ago

You can make a test with this image for RPi4.

Thank you.

jayare5 commented 3 years ago

@gouchi Tested, it still displays only black.

Notes: Since this is Pi4, I used enable_tvout=1, with this I can tell that it's outputting black because the TV flickers for a bit when it detects the signal, so I know the option is working, just no image or video coming. (And the black screen is slightly less dark than when there's no signal)

Another interesting note: Normally when you power on the RPi, you can only use either Composite or HDMI, never both at the same time, and it requires you to power off if you want to switch. With this test image, even though I powered on the RPi connected to my CRT with the AV cable, I connected the HDMI cable to check and it was actually outputting through HDMI at 1080p! RetroArch is not even supposed to boot at 1080p when connected to a CRT with the 3.5mm AV cable. Not sure if that says anything, just something I noticed.

gouchi commented 3 years ago

@jayare5 Thank you for your tests. Can you try ?

And I can confirm that then, enable_tvout=1 and dtoverlay=vc4-kms-v3d-pi4,composite=1 in config.txt result in usable picture in X on Pi4.

It might help for our case.

Source

jayare5 commented 3 years ago

Adding that line makes the Lakka berry show up on the TV! But it doesn't seem to get past it, at least for the 3 minutes I left it on.

gouchi commented 3 years ago

Thank you for your tests.

Will it possible to get some RA logs if possible ?

jayare5 commented 3 years ago

@gouchi I followed the guide and have a log.txt file! Not sure if this is correct though since this is my first time creating a log, let me know. log.txt

gouchi commented 3 years ago

Thank you for the log.

It seems you got segfault :(

Can you try with nightly builds to boot with enable_tvout=1 and dtoverlay=vc4-kms-v3d-pi4,composite=1 in config.txt and provide some log ?

jayare5 commented 3 years ago

Done! Unfortunately, I got basically the same issue, seeing as the log looks practically the same except for newer nightly version. The Lakka berry did not show up (as expected) but I did use those 2 options in the config.txt.

To make sure everything is correct, I connected to HDMI and saw that the SSH window looked good with all the info showing and no segment fault, but I just get segment fault again when it's connected with the composite cable.

log (2).txt

gouchi commented 3 years ago

Thank you for your tests.

We will have to wait a little maybe some update from RPi linux kernel.

jayare5 commented 3 years ago

No problem! Here's hoping :)

gouchi commented 3 years ago

@jayare5 can you try also to a make test adding those options in config.txt?

hdmi_force_hotplug=0
hdmi_ignore_hotplug=1
enable_tvout=1

hdmi_force_hotplug Setting hdmi_force_hotplug to 1 pretends that the HDMI hotplug signal is asserted, so it appears that a HDMI display is attached. In other words, HDMI output mode will be used, even if no HDMI monitor is detected

hdmi_ignore_hotplug Setting hdmi_ignore_hotplug to 1 pretends that the HDMI hotplug signal is not asserted, so it appears that a HDMI display is not attached. In other words, composite output mode will be used, even if an HDMI monitor is detected.

Source

jayare5 commented 3 years ago

Hmmm so I'm not sure if I'm doing something wrong, but there are no differences using this! Nothing happens if I just add this to config.txt. I tried latest nightly as well as an old one that was installed before flashing a new nightly.

The Composite output will only give me black on my CRT, but plugging in the HDMI cable will display on the HDMI screen. (not supposed to happen but is the same that was already happening)

If I use dtoverlay=vc4-fkms-v3d-pi4, I just see the Lakka berry but stays there frozen. With this one I do not see HDMI working after it's already turned on.

gouchi commented 3 years ago

Thank you for your tests I wished it could have improved the situation.

It should have at least disable the hdmi output.

jayare5 commented 3 years ago

Hmmm it definitely didn't do that! What are the chances I did something wrong? I had actually also checked that the same config wasn't anywhere else on the config.txt, well except for one of the hotplug ones which is there commented by default, which should have done nothing.

I'll double check though. Let me know what else I should look out for.

eugene-s-nesdev commented 3 years ago

I confirm this problem on RPi3B+ with lastest "Lakka-RPi3.aarch64-nightly-20210724-58dafbe.img"

Lakka 2.2.x works, 2.3.x hangs at flower, 3.x show blackscreen on the CRT.

Ntemis commented 3 years ago

Report this to raspberry pi kernel repo so we can fix this in the future

eugene-s-nesdev commented 3 years ago

CRT-test update:

eugene-s-nesdev commented 3 years ago

RPi3B+ testing

That lakka-nightly which i've tested had 5.10.50 kernel https://github.com/libretro/Lakka-LibreELEC/commit/eb4a4fe0a29de5afae4e92ee2ea7bb6cd9c22b8e but still don't working. So I need to test RPiOS:

I've downloaded "2021-05-07-raspios-buster-armhf.img", tested it on LCD via HDMI, and then tried all SDTV-modes on CRT:

sdtv_mode=0          / Normal NTSC
sdtv_mode=2          / Normal PAL
sdtv_mode=16         / Progressive NTSC
sdtv_mode=18         / Progressive PAL

All modes works correct on CRT.

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.17-v7+ #1414 SMP Fri Apr 30 13:18:35 BST 2021 armv7l GNU/Linux

I'm still confused why lakka doesn't work, seems it has more fresh kernel. This bug should be already fixed.

Report this to raspberry pi kernel repo so we can fix this in the future

Already reported here: https://github.com/raspberrypi/linux/issues/4233#issuecomment-892682431 This bug seems to be on the Lakka side.

Last release that had composite-out working was 2.2.2. (It has been removed from all servers now. I have backup fortunately) It's broken since 2.3.x releases. Re-open bug please.

gouchi commented 3 years ago

So you did succeed to make CRT to work using KMS (no Xorg or Wayland) with RPiOS ?

Thank you.

eugene-s-nesdev commented 3 years ago

I've just downloaded this "2021-05-07-raspios-buster-armhf.img" image, and tried all sdtv modes (0, 2, 16, 18) via native RPi3 composite minijack output on CRT.

I don't touched/added any lines in cfg, except sdtv_mode='value' Also i don't touched any RPiOS settings, not upgraded linux kernel. All was at default.

So, i guess linux core works good. Need to find why lakka is broken since 2.3.x

Unfortunately, i don't have RPi4 for testing.

gouchi commented 3 years ago

Workaround for now is to use fake kms.

eugene-s-nesdev commented 3 years ago

Does this config work with RPi3 internal minijack composite out?

jayare5 commented 3 years ago

Does this config work with RPi3 internal minijack composite out?

It does!

eugene-s-nesdev commented 3 years ago

ELZ wrote he use this config:

#include distroconfig.txt
dtoverlay=vc4-fkms-v3d
dtoverlay=dpi24
enable_dpi_lcd=1
display_default_lcd=1
dpi_output_format=519
dpi_group=2
dpi_mode=87
hdmi_timings=2048 1 180 202 300 240 1 3 5 14 0 0 0 60 0 42954545 1
disable_splash=1
disable_overscan=1
dtparam=audio=on
hdmi_drive=2

I see it contains a bunch of HDMI-related parameters. What's clean config just for use with internal tvout?

Is it enough?:

dtoverlay=vc4-fkms-v3d
sdtv_mode='your_prefer_value'
gouchi commented 3 years ago

@jayare5 @eugene-s-nesdev Can you try to make a test with latest nightly as we did update the RPi kernel.

Thank you.

jayare5 commented 3 years ago

All right I've tested Pi3 and Pi4.

On Pi3, the situation is the same as before, needs to have the fkms edit in the config, and it will work properly with a CRT. Without the fkms it won't show up at all.

On Pi4, the situation has changed! Using enable_tvout=1, no other edits, won't show up on the CRT. Using enable_tvout=1, with the fkms edit, IT WILL SHOW UP ON THE CRT! This is the first time I get that to happen on a Pi4 probably in the last 2 years.

Though I guess the point of updating is so that one day it will be able to work without the fkms edit? Anyway, I'll be here to test future updates! :)

gouchi commented 3 years ago

@jayare5 @eugene-s-nesdev

Can you try for the RPi4 this configuration for config.txt

dtoverlay=vc4-kms-v3d-pi4,composite=1
hdmi_force_hotplug=0
hdmi_ignore_hotplug=1
enable_tvout=1
disable_fw_kms_setup=1

Then append to cmdline.txt the video parameter and adapt to the resolution you need video=Composite-1:<xres>x<yres>@<refresh>e for example

video=Composite-1:720x576@50ie

Thanks to @HiassofT for the information.

jayare5 commented 3 years ago

Tested!

I flashed the nightly 2021 08 28, unfortunately it just hangs at the Lakka berry splash screen. (Likely same segfault as the logs I had posted)

I also don't think this line is doing anything: video=Composite-1:720x576@50ie

I tried it in all 3 txt files just to see, and my TV always displayed things properly (480i @60, NTSC TV here but that line should have given me a PAL signal, which would have been wrong, but I tried it just like the example anyway and it doesn't do anything)

gouchi commented 3 years ago

@jayare5 Thank you for your test.

So you did try also with ?

video=Composite-1:720x480@60ie

May you try to give the output of when you are in the terminal

for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done

Thank you.

HiassofT commented 3 years ago

make sure everything in cmdline.txt is on a single line, you have to add video=... after "quiet", separated by a space.

If you added that as a separate line it will be ignored.

jayare5 commented 3 years ago

Hey, it actually works! I put this line after "quiet " (with space) video=Composite-1:720x480@60ie

It boots fine now and everything including cores seem to be quite smooth and perfect! The only thing I don't see working now is sdtv_mode=16 for progressive NTSC, it's interlaced right now.

gouchi commented 3 years ago

I am glad it is working now.

You may try to append the video parameter at the end of cmdline.txt with (without the i)

video=Composite-1:720x480@60e

HiassofT commented 3 years ago

240/288 line progressive output isn't implemented in the driver yet.

There's an open PR though which should add this - when it gets merged

https://github.com/raspberrypi/linux/pull/4406

gouchi commented 3 years ago

@HiassofT Thank you for the information I did not know about it .

@jayare5 So we will have to wait a little ;)

HiassofT commented 3 years ago

FYI: you can find some more info about composite configuration in the RPi kernel PR which added/fixed composite output: https://github.com/raspberrypi/linux/pull/4241

eg there's now also a vc4.tv_norm module parameter (which you can add to cmdline.txt) to select PAL60, SECAM, NTSC-J, ... output if you need that

jayare5 commented 3 years ago

Sounds like really good news!! I am glad to see this is just waiting to be merged and that a lot of attention is being put into this :D Let me know when more tests are needed.

jayare5 commented 3 years ago

I tested the latest version after that merge!

Progressive certainly works, but not in the way I expected. I think the only way for me to get progressive scan is to type 720x240@60e in the parameter instead of 720x480@60e? However, the image is not correct because what that does is it takes the top 240 pixel portion and stretch it vertically... it needs to be 480, just "line halved" to 240 if that makes sense.

It is described here in the first paragraph titled Progressive modes: https://github.com/raspberrypi/linux/pull/4406 and apparently that's what is intended to do, but currently, it cannot be used like this.

So I just ask, is there / will there be a 480 mode that works how sdtv_mode=16/sdtv_mode=18 did? Thanks!! image_2021-09-08_173449

kFYatek commented 3 years ago

@jayare5

It is described here in the first paragraph titled Progressive modes: raspberrypi/linux#4406 and apparently that's what is intended to do, but currently, it cannot be used like this.

As an author of that PR, I don't think that can be done directly.

With my PR, I was able to get the kind of output you expect in X by entering that 720x240 mode and running xrandr --output Composite-1 --scale 1x2. I'm not sure how could that be achieved in Kodi or whatever you're using.

The GPU will always internally operate at 720x240 in the progressive mode, that "fake" 720x480 mode you expect will always be some kind of scaling. Perhaps that could be configured within the DRM driver, but that's really outside my field or expertise or interest, and I'm not even sure if that kind of mode handling in the kernel would be appropriate.

jayare5 commented 3 years ago

Wow that sounds like bad news. That mode is specifically why many people like me even got into Raspberry Pi... it sounds like it will take very long for someone to come in with the right expertise and interest. Things used to work perfectly well though, with just the sdtv_mode=16 / sdtv_mode=18, is there no way to make that work without having to use fkms in dtoverlay=vc4-fkms-v3d? Because when I use fkms, certain things don't work well

kFYatek commented 3 years ago

I just did some very dirty PoC on my Pi that does hardware scaling from 720x480 to 720x240 with Full-KMS. I did not test with RetroArch, but it seems to work under X, although not quite exactly like it does with the firmware framebuffer:

If this kind of behaviour would satisfy you, I can try polishing it up so that it could be made into an actual PR. I have no idea whether it could ever be accepted into the default Raspberry Pi kernel, let alone upstream - I don't think I've ever seen video modes downscaled by design in the kernel, so I wouldn't be surprised if the maintainers would be willing to accept that. On the other hand, that's how the firmware behaved since forever, so... maybe.

jayare5 commented 3 years ago

I really appreciate you continuing to work on this!! I did not expect it :) Thank you. The way you describe the behavior does sound like it would work well for what we're doing here, because the thing is that the games we play with this are already basically line doubled (games are 240p, integer scaled to 480p, and then line halved again on the TV) so it shouldn't be a difference there! The lines being averaged sounds like it might even produce a nicer image whenever higher quality assets are shown (like in RetroArch menus).

If it's not too much to ask for, I'd love to try it!