PI4 only sends out DMT modes and ignores hdmi_group

[alanbork]

pi4/kms only seems to send out a DMT video signal.

I am testing a Samsung TV that behaves very differently (which display settings you can change, etc) when it's sent a DMT mode vs a CEA mode. On a pi0 it's easy to see this is the case by setting any one of the CEA modes using tvservice vs any one of the DMT modes; I've tried a bunch and this is definitely the variable that it detects and sets which menu options are active.

I have these lines in my pi4 config.txt

max_framebuffers=1
hdmi_force_hotplug=1
hdmi_group=1
hdmi_mode=16
hdmi_enable_4kp60=1
edid_content_type=EDID_ContentType_NODATA
hdmi_pixel_encoding=1 #RGB limited (16-235)

which from the docs seem like the best bet for getting a CEA mode. But both kms and fkms are ignoring hdmi_group, and the TV continues to think it's getting a DMT mode. I've also tried it with and without the last two items, which seem redundant or irrelevant given the hdmi_group setting but seemed like useful debugging.

I'm booting directly to the console, no x11. Running 1340be471e2764cca8b9f8266e23347d1288919e, haven't tried any older releases.

I apologize if I'm using the terminology wrong; it's not really clear to me if DMT modes are actually distinct from HDMI modes or if it's just a convention of resolutions, refresh rates, and pixel encodings.

[alanbork]

closed for a bit because I though maybe this should go in /kernel, but discovered that fkms had the same problem so I guess it could go either place.

[popcornmix]

These settings are firmware settings and will have zero effect in kms world.
They have little effect in fkms world (they affect the initial mode booted into, but linux chooses the modes subsequently).
If you remove both kms and fkms overlays they will have an effect.

[alanbork]

I see. Is there a workaround post-boot?

…

On Fri, May 14, 2021, 7:51 AM popcornmix ***@***.***> wrote: These settings are firmware settings and will have zero effect in kms world. They have little effect in fkms world (they affect the initial mode booted into, but linux chooses the modes subsequently). If you remove both kms and fkms overlays they will have an effect. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#1579 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANPGZ5MN2ZIDYYHWKGOQPEDTNU2GJANCNFSM443R2JIA> .

[6by9]

DMT and CEA are only ways of describing which table to look up standard resolutions from - VESA DMT (Display Monitor Timings) or CTA CEA-861.

For CEA modes the spec requires the use of reduced range video signals, and pass the mode number in the VIC (Video Information Code) field of the AVI (Auxilliary Video Information) Infoframe.
DMT modes use full range RGB, and set the VIC field to 0.

Trying to get the framebuffer emulation of DRM to adopt any particular resolution is all controlled by the video= parameter on the kernel command line. Syntax in https://github.com/raspberrypi/linux/blob/rpi-5.10.y/Documentation/fb/modedb.rst.
It doesn't allow you to specify the mode by number, only by resolution and refresh rate.
If the specified combination is found from the EDID then that mode will be adopted, otherwise a new mode with those parameters will be created using the GTF or CVT formulae.

Post-boot I do not believe there is a way to get the frame buffer emulation to change the base mode. If you have a need for a particular mode then your application needs to use the DRM/KMS API to request it, and then create a plane to render on that display.

[alanbork]

Thanks for pointing me in the right direction!

Am I understanding that the relevant DRM structure is

https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html#c.hdr_metadata_infoframe

EDIT: that can't be right, its for HDR and the units are luminance not RGB framebuffer. Is it possible the relevant Infoframe structure isn't exposed to userland?>

I don't see anything about VIC / Video Information Code anywhere on that same page either.

One last question: EDID_ContentType_NODATA, is that something that's being sent to the TV or just changing how the PI chooses modes? (seems like it's sent to TV based on https://www.raspberrypi.org/forums/viewtopic.php?t=14941). Is there a way to make kms send one of these content types other than from a custom DRM/KMS app?

[6by9]

No, hdr_metadata_infoframe would be for the HDR metadata infoframe, not the AVI infoframe.

The AVI infoframe is generated by the driver based on the timing parameters
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/vc4/vc4_hdmi.c#L375 using the standard DRM function drm_hdmi_avi_infoframe_from_display_mode to populate it.
This is exactly the same function that is called from the Intel i915, Nvidea nouveau, AMD radeon, or almost any of the other Linux display drivers.

Where have you found EDID_ContentType_NODATA from? It's not an enum that appears to be used anywhere within the Linux codebase or user API documentation.

[alanbork]

EDID_ContentType_NODATA  is from https://www.raspberrypi.org/documentation/configuration/config-txt/video.md

it sounds like those function is driver-level and not exposed to userland, based on this list:
https://www.kernel.org/doc/html/latest/gpu/drm-uapi.html

I have found an alternate option that's even accessible from the command line though: proptest.c from the same repo as modetest.c

You should be able to do something like this

./proptest 89 connector 94 1 # full
./proptest 89 connector 94 2 # limited

it doesn't take effect immediately or on the next mode change, however. Twiddling other properties (the margin) does take effect immediately, (very useful find, actually, resolves my long-standing issue with hardcoded overscan from config.txt).

Some other folks have been able to use this to change the encoding range (swaywm/sway#3173) for different hardware, could this be a vc4 driver bug?

if you think it's worth testing I can copy over what proptest does into my c code and see if setting it just before opening the mode makes a difference.

[6by9]

As has been stated numerous times, config.txt settings have near zero value in the KMS world. Same applies to the text descriptions of config.txt settings.

"Broadcast RGB" is an Intel specific property to allow overriding the RGB range. There is no generic property, although it has been discussed several times.
FKMS copies the Intel property. Full KMS doesn't, but will do once it is standardised (we try to avoid having downstream only patches for full KMS).

[alanbork]

so is there a userland api for making the KMS use a limited range then? it seems like all the things you've pointed to are kernel level.

[6by9]

so is there a userland api for making the KMS use a limited range then? it seems like all the things you've pointed to are kernel level.

Full KMS doesn't, but will do once it is standardised.

[alanbork]

Bummer. Is this likely to happen soon or is it time for me to learn to hack and compile kms code directly? Not looking forward to that, but at least you've given me some good links into where the code needed lives.

[timg236]

Closing due to inactivity.
NB FKMS and legacy display drivers are deprecated