Why does 1366x768 work on some monitors but not others.

[plugwash]

There have been been reports on the forums of compatibility problems with 1366x768 monitors and the documentation now says that mode 81, is not supported on the Pi 4.

However I was sure I had seen a Pi4 working in 1366x768 with a Pi-top ceed. Wanting to confirm my suspicions I just pulled out my original pi-top (which I assume used the same screen as the ceed) and hooked up a Pi4 to it. I confirmed that it is indeed running in 1366x768.

I first though that the display might be using mode 86 (the reduced blanking variant) but that does not appear to be the case. Querying using tvservice for supported modes shows only modes 81 and 4

tvservice -s says

state 0x6 [DVI CUSTOM RGB full 16:9], 1366x768 @ 60.00Hz, progressive

I have not configured any custom modes.

Any idea why this is working, and whether this knowledge can be used to help users of other 1366x768 screens?

[trejan]

Timing must be slightly different. Dump the EDID?

Code: Select all

tvservice -d edid.bin
base64 edid.bin

[6by9]

https://www.raspberrypi.org/documentati ... i4-hdmi.md

[cleverca22]

https://www.raspberrypi.org/documentati ... i4-hdmi.md

ahhhh, odd numbers in the timing params, that explains why its such a drastic change

It's a pity the problem with screen resolution 1366x768 that existed in the Pi4 is still present in the Pi400.

That would require a major change to the silicon, which is not a "stepping" change. i.e. not fixable in HW on this SoC at this stage. It's not a simple "bug fix" like the other changes in C0, it's a major change in the way the HDMI block works.

and why its not so easily fixed, the PV would have to be modified again


and i guess you cant just cheat and round the timings up/down, because hdmi encodes the DE signal into things, so its not just a matter of the image bleeding into the blanking interval

have any experiments been done to see how a typical monitor reacts to rounding the timings up/down, so they are even once more?

[6by9]

and i guess you cant just cheat and round the timings up/down, because hdmi encodes the DE signal into things, so its not just a matter of the image bleeding into the blanking interval

have any experiments been done to see how a typical monitor reacts to rounding the timings up/down, so they are even once more?

When we initially believed that the HDMI block could retime (so PV got modified timings and HDMI got the real thing) we had timings that worked on the PiTop, but the same settings didn't work on the Acer 1366x768 monitor that a reseller was using.
Incrementing the sync pulses one way resulted in the PiTop misinterpreting the stride and giving a diagonal shift, whilst the other way worked on that particular display. That's largely the reason that the firmware and kernel drivers now just disable the mode rather than trying to second guess what may work.

[cleverca22]

and i guess you cant just cheat and round the timings up/down, because hdmi encodes the DE signal into things, so its not just a matter of the image bleeding into the blanking interval

have any experiments been done to see how a typical monitor reacts to rounding the timings up/down, so they are even once more?

When we initially believed that the HDMI block could retime (so PV got modified timings and HDMI got the real thing) we had timings that worked on the PiTop, but the same settings didn't work on the Acer 1366x768 monitor that a reseller was using.
Incrementing the sync pulses one way resulted in the PiTop misinterpreting the stride and giving a diagonal shift, whilst the other way worked on that particular display. That's largely the reason that the firmware and kernel drivers now just disable the mode rather than trying to second guess what may work.

and i'm guessing you can still use hdmi_timings= to force even timings with 1366x768, but youll need to experiment to find the right ones for your specific monitor, and if your monitor even allows the timing to be off by 1 count

[jamesh]

and i guess you cant just cheat and round the timings up/down, because hdmi encodes the DE signal into things, so its not just a matter of the image bleeding into the blanking interval

have any experiments been done to see how a typical monitor reacts to rounding the timings up/down, so they are even once more?

When we initially believed that the HDMI block could retime (so PV got modified timings and HDMI got the real thing) we had timings that worked on the PiTop, but the same settings didn't work on the Acer 1366x768 monitor that a reseller was using.
Incrementing the sync pulses one way resulted in the PiTop misinterpreting the stride and giving a diagonal shift, whilst the other way worked on that particular display. That's largely the reason that the firmware and kernel drivers now just disable the mode rather than trying to second guess what may work.

and i'm guessing you can still use hdmi_timings= to force even timings with 1366x768, but youll need to experiment to find the right ones for your specific monitor, and if your monitor even allows the timing to be off by 1 count

Correct.

[LTolledo]

However I was sure I had seen a Pi4 working in 1366x768 with a Pi-top ceed. Wanting to confirm my suspicions I just pulled out my original pi-top (which I assume used the same screen as the ceed) and hooked up a Pi4 to it. I confirmed that it is indeed running in 1366x768.

is this on the latest firmware? 5.4? 5.10?

because when I tested my RPi4B-4GB on the pi-top that I have, at 4.19 firmware, there was no display at 1366 x 768 resolution....
eventually getting a usable visual output at 1360 x 768 to which is "forcefully set" as of now....