1366x768 only works without fkms

[stevenjowens]

Describe the bug

dtoverlay=vc4-fkms-v3d in /boot/config.txt prevents video on a 1366x768 monitor ( AOpen 20CH1Q ) from working.

Tested on both a Raspberry Pi 4 and a Raspberry Pi compute module 4 (with Waveshare IO Board with POE).

Eventually we determined that commenting out the dtoverlay line in /boot/config.txt resolved the problem (albeit with much slower video without fkms rendering acceleration).

Note: The same problem occurs with kms as with fkms.

In more detail:

When using an AOpen 20CH1Q monitor (native resolution 1366 x 768), no video on boot up.

Managed to get video (640x480) by setting hdmi_safe=1 (aka hdmi_group=1 and hdmi_mode=1) in /boot/config.txt.

No other settings of hdmi_group/hdmi_mode made video work.

If booted with the HDMI plugged into another monitor (Dell U24), video on the Dell works, and if the HDMI cable is then unplugged from the Dell and plugged into the AOpen, video on the AOpen works.

When booted plugged into the Dell monitor, the tvservice query shows:

pi@pi192:~ $ tvservice --mode=DMT
Group DMT has 9 modes:
           mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
           mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
           mode 32: 1280x960 @ 60Hz 4:3, clock:108MHz progressive
           mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
           mode 51: 1600x1200 @ 60Hz 4:3, clock:162MHz progressive
           mode 58: 1680x1050 @ 60Hz 16:10, clock:146MHz progressive
  (prefer) mode 68: 1920x1200 @ 60Hz 16:10, clock:154MHz progressive
           mode 82: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
pi@pi192:~ $ tvservice --mode=CEA
Group CEA has 0 modes:
pi@pi192:~ $

When the following settings were used in /boot/config.txt, and the pi cm4&IO Board, booted with the HDMI plugged into the AOpen monitor, video worked:

a) the dtoverlay line commented out
b) hdmi_group=2
c) hdmi_mode=68

Movie playing was jerky of course, due to the lack of fkms/kms rendering acceleration.

To reproduce

1. Install Raspberry Pi OS into a pi 4 or pi compute module 4 w/IO board
2. Plug the HDMI out from the pi 4 into an AOpen 20CH1Q monitor
3. Boot up the pi.

Expected behaviour

For the video to work.

Actual behaviour

Screen backlight comes on, blinking underline cursor in upper left corner.
Rasperry Pi splash screen displays for a second or two.
Screen goes dark.
Screen lights up again.
Screen goes dark again.
Screen lights up again.
Screen goes dark again.
Screen displays "No Signal" briefly, then goes dark.

System

See attached raspinfo.txt

raspinfo.txt

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW

Both pi 4 and pi compute module 4 with a waveshare IO Board with POE.

• Which OS and version (cat /etc/rpi-issue)?

pi@pi192:~ $ cat /etc/rpi-issue 
Raspberry Pi reference 2021-05-07
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage5
pi@pi192:~ $ 

• Which firmware version (vcgencmd version)?

pi@pi192:~ $ vcgencmd version
May 27 2021 14:02:15 
Copyright (c) 2012 Broadcom
version 7d9a298cda813f747b51fe17e1e417e7bf5ca94d (clean) (release) (start)
pi@pi192:~ $ 

• Which kernel version (uname -a)?

pi@pi192:~ $ uname -a
Linux pi192.168.66.69 5.10.17-v7l+ #1421 SMP Thu May 27 14:00:13 BST 2021 armv7l GNU/Linux
pi@pi192:~ $ 

Logs

No logs applicable.

Additional context

For completeness, here's the monitor details:

https://www.bestbuy.com/site/acer-aopen-20ch1q-bi-19-5-hd-widescreen-tn-led-lcd-flat-panel-monitor-hdmi/6435025.p?skuId=6435025
Acer - AOPEN 20CH1Q BI 19.5" HD Widescreen TN LED LCD Flat Panel Monitor (HDMI)
Model:20CH1Q BI
SKU:6435025

[JamesH65]

1366x768 is a horrible resolution and not supported directly by the Pi hardware. Its the ONLY defined resolution that uses odd numbers timings, that the Pi4 is unable to generate. When using the legacy graphics (no FKMS or KMS) the firmware hacks the resolution and changes it to something close by that can be generated. Looks like the FKMS/KMS does not do the same hack. @6by9 may be able to comment further.

[6by9]

https://www.raspberrypi.org/documentation/configuration/config-txt/pi4-hdmi.md

FKMS and KMS both reject any modes that have odd horizontal timing values.
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1093
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_hdmi.c#L1095
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/drivers/gpu/drm/vc4/vc4_hdmi.c#L1143
It should choose an alternate mode from the EDID.

Memory says that the firmware does the same too. At one point it attempted to tweak the mode, but that didn't work on all monitors.

If the firmware and kernel disagree on supported modes then the kernel can end up choosing the CVT mode of the firmware's resolution. This is often not supported by the monitor as CVT is much slower on timing than CEA or DMT. You can add disable_fw_kms_setup=1 to stop the firmware even attempting to pass video mode to the kernel (via the kernel command line).

Please provide the EDID of your AOpen display (tvservice -d edid.bin).

[stevenjowens]

edid.bin.gz

Github wouldn't let me upload edid.bin raw, it said unsupported file format.
So I gzipped it, and that seems to make github happy.