Pi4: Output 2160x3840 image?

Help
1

Hi,

i’m trying to set up device 36059 (Pi4 8GB) to output a 2160x3840px image (4k portrait mode). However, everythin i’ve tried so far did not yield any useful results.

On a Pi3 i’ve used the following snippet in the past (successfully), but even using exactly this will still make the pi output regular landscape video.

hdmi_timings=1080 0 18 16 48 1920 0 8 16 10 0 0 0 60 0 136000000 1
hdmi_group=2
hdmi_mode=87
hdmi_ignore_edid=0xa5000080
hdmi_cvt 1080 1920 60
max_framebuffer_width=1080
max_framebuffer_height=1920

Can you maybe give me a hint on what i’m doing wrong and how i can get the pi to output a portrait image?

2

All hdmi_* settings in config.txt have been deprecated by newer Pis as KMS/DRM is now responsible for setting up video modes. The new way is to have something like video=HDMI-A-1:1920x1080M@60D which the kernel parse in the KMS/DRM subsystem and applies. But: For backwards compatibility and in case you transfer SD card from older Pis to a newer Pi4/5 and to unify setting resolutions, info-beamer OS has a limited backwards compatibility feature that still parses these options and emulates them.

What’s supported:

hdmi_group=[DMT|CEA]
hdmi_mode={some number}
hdmi_pixel_encoding=[0|1|2|3|4]

and in case of DMT 87:

hdmi_cvt={width} {height} {framerate}

The reason your settings don’t work is because the hdmi_cvt with only spaces won’t work. You need the hdmi_cvt= prefix. You can get rid of hdmi_timings, max_framebuffer_* and hdmi_ignore_edid as they will be ignored. This probably also means that you might not see the boot messages as the mode is only applied once the info-beamer process takes over.

3

Thanks for the quick reply.

I’ve tried fiddling with the proposed hdmi_* options, but none of them seem to have any effect.

I also can’t see any option in the hosted web interface to manually specify the video= option, the web interface only has a field for config.txt, not for cmdline.txt. Am i correct in assuming that fiddling with cmdline.txt on the system itself is not supported and will get removed on system updates?

4

Ah. That feature was added only in the Dezember release of ‘stable’ while you are on the July version. I updated, but it seems the mode still isn’t accepted and it falls back to using FullHD instead:

info-beamer: [surface_kms.c]  assigned mode for display 0 (blob_id=720): 2160x3840: 59.98 70Hz name: 2160x3840, clock: 722499 (flag:0x6 -hsync +vsync) - user defined
info-beamer: [surface_kms.c]  testing mode on display 0
info-beamer: [surface_kms.c]   VRR_ENABLED display 0 = 0
info-beamer: [surface_kms.c]   Broadcast_RGB display 0 = Full
info-beamer: [surface_kms.c]   Pixel encoding display 0 = Automatic
info-beamer: [surface_kms.c]   SDR on display 0
info-beamer: [surface_kms.c]   chosen mode not valid. Using FullHD fallback
info-beamer: [surface_kms.c]  assigned mode for display 0 (blob_id=720): 1920x1080: 60.00 00Hz name: 1920x1080 @ 60Hz (1080p), clock: 148500 (flag:0x5 +hsync +vsync)

The corresponding DRM error is:

(Can be seen using echo 0x19F > /sys/module/drm/parameters/debug which then instantly floods the syslog)

vc4-drm gpu: [drm:drm_atomic_add_affected_connectors [drm]] Addingall current connectors for [CRTC:101:pixelvalve-2] to 000000008886960e
vc4-drm gpu: [drm:drm_atomic_add_affected_planes [drm]] Adding allcurrent planes for [CRTC:101:pixelvalve-2] to 000000008886960e
vc4-drm gpu: [drm:drm_atomic_add_encoder_bridges [drm]] Adding allbridges for [encoder:31:TMDS-31] to 000000008886960e
vc4-drm gpu: [drm:drm_atomic_add_encoder_bridges [drm]] Adding allbridges for [encoder:31:TMDS-31] to 000000008886960e
vc4-drm gpu: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [ENCODER:31:TMDS-31] mode_valid() failed
vc4-drm gpu: [drm:drm_atomic_check_only [drm]] atomic driver checkfor 000000008886960e failed: -22
vc4-drm gpu: [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state 000000008886960e

mode_valid() failed I think happens if the configured mode isn’t allowed according to the EDID information provided by the display. Are you sure your display supports that? It seems to be a normal looking NEC display. Does that accept a portrait mode signal and then internally rotates it? Wouldn’t rotating the content via the assigned setup work instead?

5

I’m not 100% sure this display supports that resolution, but i assume so because it does support rotating the screen to a portrait orientation, stretching a landscape signal to fit.

Rotating via the assigned setup would indeed work, however not all the setups we currently run do support rotation, so i thought this could be a sneaky way to get around implementing rotation in 5+ packages.

(For reference: This is a standard NEC P435 display in portrait mode, with “Picture” → “Advanced” → “Rotation” → “Rotate All” enabled.)

6

Interesting approach. I’m not entirely sure on the mode validation logic. I think I traced it back to linux/drivers/gpu/drm/vc4/vc4_hdmi.c at 2a536bfca932b9df066dff0b03444dfe4a35b592 · raspberrypi/linux · GitHub and the clock test is here: linux/drivers/gpu/drm/vc4/vc4_hdmi.c at 2a536bfca932b9df066dff0b03444dfe4a35b592 · raspberrypi/linux · GitHub.

This sounds relevant:

	/* 4096x2160@60 is not reliable without overclocking core */
	if (!vc4->hvs->vc5_hdmi_enable_4096by2160 &&
	    mode->hdisplay > 3840 && mode->vdisplay >= 2160 &&
	    drm_mode_vrefresh(mode) >= 50)
		return MODE_CLOCK_HIGH;

The rotation would cause vdisplay to be 3840, so it should trigger this condition. Maybe? Can you check if it works if you temporarily reduce framerate to 30Hz?

vc5_hdmi_enable_4096by2160 is set conditionally here:

		max_rate = rpi_firmware_clk_get_max_rate(firmware,
							 RPI_FIRMWARE_CORE_CLK_ID);
        [...]
		if (max_rate >= 600000000)
			hvs->vc5_hdmi_enable_4096by2160 = true;

Not sure how that clock is set. Maybe core_freq=600 in config.txt?