Raspberry Pi 4 Thread - general discussion

[timg236]

Yes, the firmware wasn't parsing the "YCbCr420_only" extended block of the EDID, so was seeing 3840x2160@60 in the detailed timings but then not filtering it out due to being YCbCr420 (which currently isn't supported).

I understand - HDMI 2.0 can be a minefield...

So currently what 4K60 (aka 2160p60) and 4K50 modes are supported, if 4:2:0 is currently not supported?

RGB 8-bit?
4:4:4 YCrCb 8-bit?
4:2:2 YCrCb 12-bit? (With 8-bit content?)

The lack of current 4:2:0 support is worth flagging for those who have earlier SDR-only UHD displays (My first Sony UHD TV was 4:2:0 8-bit only for 2160p50 and 2160p59.94/60 inputs)

8 bit is fine and IIRC at p30 RGB deep color is fine. However at 4Kp60 12 bit (can’t remember about 10) would exceed the max data rate so the standard requires YUV. 4:2:0 or 4:2:2. The compositor is always 12 bits per channel RGB but the HDMI colour space converter only supports 422 not 420. Presumably 420 requires extra line buffers for the vertical downsample.

[noggin]

Yes, the firmware wasn't parsing the "YCbCr420_only" extended block of the EDID, so was seeing 3840x2160@60 in the detailed timings but then not filtering it out due to being YCbCr420 (which currently isn't supported).

I understand - HDMI 2.0 can be a minefield...

So currently what 4K60 (aka 2160p60) and 4K50 modes are supported, if 4:2:0 is currently not supported?

RGB 8-bit?
4:4:4 YCrCb 8-bit?
4:2:2 YCrCb 12-bit? (With 8-bit content?)

The lack of current 4:2:0 support is worth flagging for those who have earlier SDR-only UHD displays (My first Sony UHD TV was 4:2:0 8-bit only for 2160p50 and 2160p59.94/60 inputs)

8 bit is fine and IIRC at p30 RGB deep color is fine. However at 4Kp60 12 bit (can’t remember about 10) would exceed the max data rate so the standard requires YUV. 4:2:0 or 4:2:2. The compositor is always 12 bits per channel RGB but the HDMI colour space converter only supports 422 not 420. Presumably 420 requires extra line buffers for the vertical downsample.

Yep - HDMI 2.0 spec supports the following :

2160p24-30 8-bit, 10-bit, 12-bit, 16-bit RGB and 4:4:4 YCrCb, and 12-bit only 4:2:2 YCrCb.
2160p50-60 8-bit RGB, 4:4:4 YCrCb and 4:2:0 YCrCb, 10-bit 4:2:0 YCrCb, 12-bit 4:2:2 and 4:2:0 YCrCb, 16-bit 4:2:0 YCrCb

So 4:2:2 YCrCb is only supported at 12-bit in any 2160p mode, and 4:4:4/RGB is only supported in 8-bit at 2160p50-60.

For HDR in 2160p50-60 you have a choice of 4:2:0 YCrCb at 10-16 bit or 4:2:2 YCrCb at 12-bit only (*)
For HDR in 2160p24-30 you can use RGB, YCrCb 4:4:4 at 10-16 bit or 4:2:2 YCrCb at 12-bit only (*)

(*) You can carry 10-bit in a 12-bit signal by padding the LSBs of course (which is what most consumer gear does when playing 10-bit HDR10 content output at 4:2:2)

The HDMI organisation used to have a great web page detailing the HDMI 2.0 specs for this. It's now gone but still available via the Wayback machine https://web.archive.org/web/20170606054 ... 0_faq.aspx



Some of the 10-16 bit modes, particularly at 2160p50-60 will require your TV to support HDMI Enhanced / HDR Deep Color etc. modes - and in some cases manually enable support in your TV and/or AVR (If your Pi is connected to your TV via an AVR) - and not all TVs support all modes on every HDMI input...

I guess if the Pi is converting from RGB->YCrCb in the compositor then the compositor will also need to know the new RGB->YCrCb matrix co-efficients for Rec 2020 gamut, as they are different to Rec 709 HD. Effectively we now have three separate RGB<->YCrCb matrix co-efficients to cope with - Rec 601 for SD, Rec 709 for HD and Rec 2020 for UHD (though Rec 2020 in HD is also now appearing on things like iPlayer UHD MPEG DASH streams when they drop to 1080p50)

[alphanumeric]

If this has been discussed already my apologies, getting to be a long thread and easy to miss a post or two.
Anyway, just wondering how dual monitor support works if one of them is the official touch screen connected via the DSI connector? How easy is that to setup, can it be done with a mouse click via a GUI or do you have to resort to config.txt edits etc?

[bensimmo]

This is more a query of development.

Did the team explore adding header pins for USB so it is easier for devices or HATs to make use of USB without the connector.
I know it's been suggested a few times, while I can see less of a need now with the extra UARTs, USB is however easy.

I assume it deemed not enough demand to price and board space.*
Just wondering if it was looked at.


The board still looks odd with the ports back to front

Going to have to go read about how to make use of the extra UARTs now.

[hjimbens]

My application that is similar to the hello_pi demos hangs in the eglCreateContext call on a Pi 4. I disabled the FKMS driver in config.txt and I am using a buster image that works fine on a Pi 3B+.
When I change to hello_triangle demo to not bail out on a Pi 4, it hangs in the same eglCreateContext. Is there any way to get OpenGL ES/Dispmanx applications working on the Pi 4?

[6by9]

If this has been discussed already my apologies, getting to be a long thread and easy to miss a post or two.
Anyway, just wondering how dual monitor support works if one of them is the official touch screen connected via the DSI connector? How easy is that to setup, can it be done with a mouse click via a GUI or do you have to resort to config.txt edits etc?

For DSI (and DPI) displays the firmware provides details of the mode to the kernel. You should then get a DSI-1 display in Screen Configuration that behaves in exactly the same way as an HDMI display, but without the option to change resolution/refresh rate.
HDMI0 can be used at the same time for dual screens (not HDMI1).

DPI configuration is still done via config.txt dpi_timings/dpi_mode/dpi_group/enable_dpi_lcd. It'll be called DSI-1 in Screen Configuration as there isn't a simple piece of information to hook into to differentiate them.

[alphanumeric]

If this has been discussed already my apologies, getting to be a long thread and easy to miss a post or two.
Anyway, just wondering how dual monitor support works if one of them is the official touch screen connected via the DSI connector? How easy is that to setup, can it be done with a mouse click via a GUI or do you have to resort to config.txt edits etc?

For DSI (and DPI) displays the firmware provides details of the mode to the kernel. You should then get a DSI-1 display in Screen Configuration that behaves in exactly the same way as an HDMI display, but without the option to change resolution/refresh rate.
HDMI0 can be used at the same time for dual screens (not HDMI1).

DPI configuration is still done via config.txt dpi_timings/dpi_mode/dpi_group/enable_dpi_lcd. It'll be called DSI-1 in Screen Configuration as there isn't a simple piece of information to hook into to differentiate them.

Nice, just what I wanted to hear. Thanks for the quick reply. I have a breadboarding setup with the official touch screen. Its all mounted on an open beam frame and semi portable. Being able to plug a second monitor into an HDMI jack with no fuss is a big bonus.

[6by9]

The TV is a Samsung KS8000, that I have also connected to my PC and works without a problem using etiher 4:2:0, 4:2:2 or 4:4:4 all HDMI ports have deepcolor (HDR) enabled, which I don't see how that should affect the resolution.

Also connected to my 4K Elgato capture card, that works without a problem again with xbox one x and ps4 pro.

I wanted to make a video about it for my youtube channel, but glad it didn't work or it would have been a frustrated video.

I am not angry at rpi group or anything I am just frustrating that it feels the OS is not ready at least from my point of view is a little bit disappointing and I believe it should have been a smoother release is all.

Please start a new thread, and include the raw EDID of your display ("tvservice -d edid.bin"). We're happy to investigate these sorts of quirks.

Parsing EDIDs is a royal pain in the rear, and combining it with much of the mainline code isn't trivial.
The EDID parsing that the kernel is using is common to all Linux platforms, so I'd be curious to know what an x86 Linux distribution does with it.

[k-pi]

With 4GB, running a distro from ram is going to be quite feasible, & that is the fastest way I know to use a computer, so anyone saying the RPi is slow should try it.

[ShiftPlusOne]

It is running javascript constantly. It shows the current time as well as a countdown until a next event as well as a slideshow. Basically, need to run that code.

Then I'm not sure the upcoming changes will make a difference for your use case.

If you're using webgl and don't need video, you can edit the chromium-browser launcher script to re-enable GPU support. Search for 'FKMS' and remove the whole 'if' block there.

[dom]

When I change to hello_triangle demo to not bail out on a Pi 4, it hangs in the same eglCreateContext. Is there any way to get OpenGL ES/Dispmanx applications working on the Pi 4?

No it will need minor changes to the code. The good news is after the changes the code will run unchanged on earlier Pi's with fkms/kms enabled as well at other linux platforms that support kms/drm/mesa.

[hjimbens]

When I change to hello_triangle demo to not bail out on a Pi 4, it hangs in the same eglCreateContext. Is there any way to get OpenGL ES/Dispmanx applications working on the Pi 4?

No it will need minor changes to the code. The good news is after the changes the code will run unchanged on earlier Pi's with fkms/kms enabled as well at other linux platforms that support kms/drm/mesa.

Thank you for your answer. Do I understand correctly that it is no longer possible to use OpenGL ES/dispmanx with the legacy driver on a Pi 4?

In the past I have tried to change from OpenGL ES legacy driver/dispmanx to fkms/gbm, but then I could not get the videodecoder to render to a texture via OpenMAX. Would that be possible now?

[uilfut]

I am not angry at rpi group or anything I am just frustrating that it feels the OS is not ready at least from my point of view is a little bit disappointing and I believe it should have been a smoother release is all.

Respectfully I think most folk here are happy to get their hands on one sooner, and see the wrinkles ironed out if they arise.

[jamesh]

I am not angry at rpi group or anything I am just frustrating that it feels the OS is not ready at least from my point of view is a little bit disappointing and I believe it should have been a smoother release is all.

Respectfully I think most folk here are happy to get their hands on one sooner, and see the wrinkles ironed out if they arise.

That's my opinion. Release dates are scheduled months in advance, and development continues right up to release date. And bugs tend to turn up as more testing is done closer to release. It would take a real doozy of a bug to stop a release.

[dickon]

And then you hand them to pesky users, who poke and prod them in irritating ways you didn't quite anticipate, and break things.

Such is the way with computers.

[Aardappeltaart]

Just received my new Pi4 2GB:

Code: Select all

pi@raspberrypi:~ $ vcgencmd get_mem arm
arm=948M
vcgencmd get_mem gpu
gpu=76M

Where is the 2GB??
Or does it mean that 1GB max can be allocated to the GPU?

Pff:

Code: Select all

pi@raspberrypi:~ $ free -h
             	 total        used        free      shared  buff/cache   available
Mem:          1.9Gi        57Mi       1.6Gi       8.0Mi       225Mi       1.8Gi
Swap:          99Mi          0B        99Mi

It's a bit of a toaster : 60° idling.

Code: Select all

vcgencmd measure_temp 
temp=61.0'C

[M5]

I'm sure that I am missing somthng. But my old fathfull samsung 21" LCD TV with HDMI output that worked will with my RPi B up till my B3+ had no problem showing 1080p seems to have failed me. as the 1080p out put of HDMI0 on my new RPi 4 B is bugger than the screen. so the top, bottom & both sides are off the screen.

I tried to edit the settings in the config.txt file in the boot directory. But this only seems to work in text mode.

Please can any one help?

Thank you every one in advance

Brian (M5)

[bensimmo]

I've just been through looking at the documentation for setting up the new UART and gpio configurations.
I can't find any. (It's still all a RPi3 stage)
Any help, info, pointers. even preliminary info on github ?

[jamesh]

I've just been through looking at the documentation for setting up the new UART and gpio configurations.
I can't find any. (It's still all a RPi3 stage)
Any help, info, pointers. even preliminary info on github ?

The full peripheral spec document isn't quite ready yet. 300 pages of proof reading needed....

[jamesh]

I'm sure that I am missing somthng. But my old fathfull samsung 21" LCD TV with HDMI output that worked will with my RPi B up till my B3+ had no problem showing 1080p seems to have failed me. as the 1080p out put of HDMI0 on my new RPi 4 B is bugger than the screen. so the top, bottom & both sides are off the screen.

I tried to edit the settings in the config.txt file in the boot directory. But this only seems to work in text mode.

Please can any one help?

Thank you every one in advance

Brian (M5)

Can you turn off overscan on the TV? We are still working on overscan for FKMS.

You could revert back to legacy graphics mode until that is sort out. Edit config.txt and comment out the fkms line in the Pi4 section to see if that helps. Not sure what other effects that might have, but should work.

[6by9]

Thank you for your answer. Do I understand correctly that it is no longer possible to use OpenGL ES/dispmanx with the legacy driver on a Pi 4?

In the past I have tried to change from OpenGL ES legacy driver/dispmanx to fkms/gbm, but then I could not get the videodecoder to render to a texture via OpenMAX. Would that be possible now?

There is no firmware driver for the 3D hardware on the Pi4, therefore there will be no "legacy" OpenGLES driver. For one, the VPU only knows about 1GB of memory, whilst the new 3D block has an IOMMU to allow it to access everything.

OpenMAX egl_render talks under the hood between decoder and 3D - that won't work.
Still bashing the last little bits into shape, but use MMAL or V4L2 to decode into a buffer, export that as a dmabuf, and then pass that into EGL or DRM for rendering. https://github.com/6by9/drm_mmal master branch should do that for DRM (ie do not start X), and the x11 or x11_export branches should do the right thing for EGL and X (x11_export will fail at present).

[bensimmo]

I've just been through looking at the documentation for setting up the new UART and gpio configurations.
I can't find any. (It's still all a RPi3 stage)
Any help, info, pointers. even preliminary info on github ?

The full peripheral spec document isn't quite ready yet. 300 pages of proof reading needed....

I'll wait.
Though a 'canny be arsed, give me the lines needed' condensed method would be appreciated

UART= port#, txpin#, rxpin#
or stop it using the S0 when it turn it on.

Busy times.


----
uSD card doesn't really seem to be (Sandisk A1 32GB) any faster, still 50MHz but iirc you/someone says DDR50 and whatever ADMA does.

Does the Overclock to 100 still work/probably work?

[6by9]

I've just been through looking at the documentation for setting up the new UART and gpio configurations.
I can't find any. (It's still all a RPi3 stage)
Any help, info, pointers. even preliminary info on github ?

The full peripheral spec document isn't quite ready yet. 300 pages of proof reading needed....

I'll wait.
Though a 'canny be arsed, give me the lines needed' condensed method would be appreciated

UART= port#, txpin#, rxpin#
or stop it using the S0 when it turn it on.

raspi-gpio has been updated with all the new alt functions
https://github.com/RPi-Distro/raspi-gpi ... pio.c#L101
And the kernel device tree includes all the resource configuration
https://github.com/raspberrypi/linux/bl ... 8.dtsi#L60
It's only really the "make it look pretty" docs that are still to do.

[bensimmo]

I think I miss-read my SD card speeds.
Using the Pi Dramble /gurlingguy benchmark

A year ago on the April Stretch image of the day.
Must have been a Pi3B

SANDISK Ultra *A1* 64GB
(sdsquar-064G-GZFMA)

50Hz
1st / 2nd test
22.51/22.61
10.0/10.1
7878/7907
3155/3047

---
dtparm=sd_overclock=100

100Hz
test1/test2/test3

33.79/33.60/33.56
10.4/15.2/13.7
8979/9004/9276
3026/3160/3150


Pi4B just now updated just now.
With the 32GB version of the card.

50Hz
43.56 ( hdparm Buffered Read MB/s)
10.5 ( dd Write MB/s)
7839 (random read iozone kB/s)
3036 (random write iozonekB/s)

(It seems dtparam=sd_overclock= doesn't work on the Pi4, it's ignored, so random IO is slower then my normal use)
At least for me.
I will try this SD card on the 3B/B+ though.
It's probably not noticeable.

[tomasf]

Hi,

I received my Raspberry Pi 4B today. Seems fantastic so far!

One problem I have encountered is getting my DPI display to work. It works great on my 3B+, but it's all black on my 4B. It's one of these: https://www.waveshare.com/wiki/7inch_LCD_for_Pi

I'm basically using the configuration lines from that page:

Code: Select all

dtoverlay=dpi24
enable_dpi_lcd=1
display_default_lcd=1

dpi_group=2
dpi_mode=87
dpi_output_format=0x6f005
hdmi_cvt=1024 600 60 6 0 0 0

It uses the documented backward compatible hdmi_cvt entry. Just an idea, but has this perhaps stopped working on RPi 4? Do I need to craft a dpi_timings entry instead? I tried to construct one from the panel data sheet, but it's pretty tough. ( https://www.waveshare.com/w/upload/1/1a ... LCD_DS.pdf )

Or if that isn't it, any other ideas? Thank you!