new kms driver doesn't detect 480i or work when forced.

[alanbork]

the kms driver does not detect 480i. Tested with 2ac4de4eaac5c1d1b25acec4a5e0a9fdb16f0c91. Haven't checked if it woks with older versions.

kms: modetest | grep 480i
[nothing]
fkms: modetest | grep 480i
#31 720x480i 30.00 720 739 801 858 480 488 494 525 13514 flags: nhsync, nvsync, interlace, dblclk; type: driver
#32 720x480i 29.97 720 739 801 858 480 488 494 525 13500 flags: nhsync, nvsync, interlace, dblclk; type: driver

there's a bug in modetest that shows the refresh rate as half if the mode is interlaced, those really are 60hz/ntsc.

perhaps relatedly, kms fails if I force 480i by using the same modeline detected by fkms:

720x480i-60.00hz(60): 13.514000 720 739 801 858 480 488 494 525 -hsync -vsync interlace dblclk

it initializes kms/drm without errors but swapbuffer in a tight loop always returns after .28ms and nothing is shown on screen.

it works if I instead I generate a modeline using cvt:

13.50 720 744 808 896 480 483 493 512 interlace -hsync +vsync

so maybe the issue is dblclk?

[alanbork]

seems this exact problem was fixed for fkms a while ago: #3725.

[6by9]

DRM works in frames not fields. 480i is 30 frames (60 fields) per second, and 33ms would therefore be correct for vsync timings (I'm assuming .28ms was a typo for 28ms).
You can not update the display between fields.

Your listed timing is totally different from the porch timings of the one parsed from the EDID, so I'm not sure of the relevance.

As per the docs, due to the 2-pixels/clock architecture, odd values in horizontal timings can not be supported.
720x480i 30.00 720 739 801 858 480 488 494 525 13514 and 720x480i 29.97 720 739 801 858 480 488 494 525 13500 will have been pruned due to this. See https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_hdmi.c#L1444

Fkms has a specific conditional to allow such modes with DBLCLK.
Looking at vc4_crtc.c, all the horizontal pixel valve timings get doubled in DBLCLK mode, so there is no way they can be odd, so those modes can be supported. The filtering out is erroneous then.

[alanbork]

DRM works in frames not fields. 480i is 30 frames (60 fields) per second, and 33ms would therefore be correct for vsync timings (I'm assuming .28ms was a typo for 28ms).
You can not update the display between fields.

not a typo, it's returning after less than a millisecond. Note these are only inferred timings as they are based on when the swapbuffer call returns. Are you saying that 480i60 can only be updated at 30hz?

Your listed timing is totally different from the porch timings of the one parsed from the EDID, so I'm not sure of the relevance.

you must be talking about the timing generated with the cvt command line, which does work even with the kms driver release I tested under. my point of including that was that kms interlaced at this resolution works fine if you bypass the edid. To be clear, I'll restate:

mode as revealed under fkms via modetest:

#31 720x480i 30.00 720 739 801 858 480 488 494 525 13514 flags: nhsync, nvsync, interlace, dblclk; type: driver

is the same as this xorg compatible modeline:

720x480i-60.00hz(60): 13.514000 720 739 801 858 480 488 494 525 -hsync -vsync interlace dblclk

which works with fkms but not kms.

as soon as a new firmware is pushed out I'll test it but since you can bypass the filtering by jamming custom values into the mode struct before initializing kms/drm I'm worried that it still won't work. At least I assume that bypasses the filtering. In any case no reason to pursue this further until the new firmware is out and ready to test, I just wanted to close the loop for posterity.

[6by9]

Are you saying that 480i60 can only be updated at 30hz?

Yes. Always has been the case if you're actually updating the display lists rather than scrawling over a live buffer.

as soon as a new firmware is pushed out I'll test it

Kernel, not firmware.

I'm worried that it still won't work

I've tested this with an HDMI analyser. It reports the timings exactly as expected.

[alanbork]

Are you saying that 480i60 can only be updated at 30hz?

Yes. Always has been the case if you're actually updating the display lists rather than scrawling over a live buffer.

I guess I'm "scrawling over a live buffer" then. Times printed below are between calls to eglSwapBuffers(*display, *surface), and alternating full black and white frames are displayed correctly. identical performance under kms and fkms (note that I'm using 1080i since 480i is not available to test yet)

 kmsmodeline 15
/dev/dri/card0 does not have DRM resources, using card1
1920x1080i-60.00hz(60): 74.250000 1920 2008 2052 2200 1080 1084 1094 1125 +hsync +vsync interlace
Initialized EGL version: 1.4
GL Viewport size: 1920x1080
16.65 ms        60.05 hz
16.70 ms        59.89 hz
16.89 ms        59.21 hz
16.40 ms        60.96 hz
19.01 ms        52.61 hz
14.18 ms        70.53 hz
16.64 ms        60.08 hz
16.63 ms        60.14 hz

(code:

    eglSwapBuffers(*display, *surface);
    struct gbm_bo *bo = gbm_surface_lock_front_buffer(gbmSurface);
    uint32_t handle = gbm_bo_get_handle(bo).u32;
    uint32_t pitch = gbm_bo_get_stride(bo);
    uint32_t fb;
    drmModeAddFB(device, mode->hdisplay, mode->vdisplay, 24, 32, pitch, handle, &fb);
    drmModeSetCrtc(device, crtc->crtc_id, fb, 0, 0, &connectorId, 1, mode);

in fact none of the code I've used seems to update at 32ms intervals, though I suspect strongly all are based on this example above. From a technical viewpoint I would have thought "scrawling over a live buffer" meant writing directly to the front buffer (or as we called it 10+ years ago, the framebuffer).

as soon as a new firmware is pushed out I'll test it

Kernel, not firmware.

as of aad6d2e912201703446691bb5efeca8e97dbaa9b it doesn't work (not detected). I'm guessing the new kernel hasn't been pushed out.

[alanbork]

oh goodness, I'm very sorry. that post above was first written with the new rpi-update but with fkms enabled not kms. 480i is still not detected under kms. I've updated the post above so that it's correct, but if you registered for emails the one sent out is wrong.

[6by9]

You could check the commit history yourself
https://github.com/Hexxeh/rpi-firmware/commits/master

Hexxeh/rpi-firmware@aad6d2e

userland: Rebuild with man pages
See: raspberrypi/userland#663

Hexxeh/rpi-firmware@1340be4

kernel: Bump to 5.10.33

kernel: spi: bcm2835: Increase the CS limit to 24
See: raspberrypi/linux#4281

kernel: ARM: dts: bcm2711-rpi-400: Limit MDIO clock speed

kernel: Single overlay file to configure the Si4682 I2S
See: raspberrypi/linux#4310

kernel: drm/vc4: Allow DBLCLK modes even if horz timing is odd.
See: raspberrypi/linux#4312

firmware: Pi400: Reduce MII clock freq when probing ethernet PHY