How to configure display timing for 7" non-Toradex monitor

Hello,

I’m trying to connect a non-Toradex display to a Verdin Development Board through the DSI to HDMI connector provided by Toradex.

The display turns on and attempts to display an image, but it jitters like crazy.
The resolution is correct, so it’s probably the timings.

When connected to a laptop, the display is configured correctly, and the DevBoard outputs correctly when plugged in to a 1080p computer monitor.
So both work independently but not together.

I’m currently running TorizonCore 4.0.0-devel-202007+build.17
The display is 7" 1024x600, but I don’t know the timings it requires.

Any ideas? Thanks!

Greetings @KlitosP,

Just some questions so I can gather more info.

  • Was the display image fine when using Toradex Easy Installer?
  • Can the 7’’ display use resolutions other than 1024x600? If yes does the image look better on these other resolutions?
  • Do you have another display other than the 7’’ display that can use 1024x600? What happens in this case?

So in general timings for HDMI are gathered through the connection via EDID info so needing to hard set timings configurations is usually not necessary. However since this is through a HDMI to DSI adapter there may be some weirdness with certain resolutions, I’ll double-check on this however.

Best Regards,
Jeremias

Hello Jeremias,
Thank you for the reply.

  • No, the Toradex easy installer was also jittering.
  • No. The display only supports 1024x600 from the standard resolutions.
  • Sorry, I do not.

I used edid-decode on the EDID file for the display whilst connected to the laptop where it is properly configured. From the output it seems that the display does not advertise itself properly, but somehow the laptop still understands.
This is the result:

header:          00 ff ff ff ff ff ff 00
serial number:   04 81 00 21 50 2d 31 01 1c 13
version:         01 03
basic params:    80 2f 1a 00 2a
chroma info:     35 85 a6 56 48 9a 24 12 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    a1 13 00 40 41 58 19 20 2c 58 36 00 dc 0c 11 00 00 18
descriptor 2:    00 00 00 ff 00 30 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a 0a
descriptor 3:    00 00 00 fd 00 38 4b 1e 53 15 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 48 44 4d 49 0a 0a 0a 0a 0a 0a 0a 0a 0a
extensions:      00
checksum:        89

Manufacturer: ADA Model 2100 Serial Number 20000080
Made week 28 of 2009
EDID version: 1.3
Digital display
Maximum image size: 47 cm x 26 cm
Gamma: 1.00
DPMS levels: Off
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed mode: Clock 50.250 MHz, 476 mm x 268 mm
               1024 1068 1156 1344 hborder 0
                600  603  609  625 vborder 0
               -hsync -vsync 
Serial number: 0
Monitor ranges (GTF): 56-75Hz V, 30-83kHz H, max dotclock 210MHz
Monitor name: HDMI
Checksum: 0x89 (valid)
EDID block does NOT conform to EDID 1.3!

That is an interesting finding on your end. By the way I forgot to ask earlier but what version of our software are you running? The output of cat /etc/issue should suffice. The reason I ask is cause on 4.0 software we ran a 4.14 kernel while on 5.0 I believe we now run a 5.4 kernel. So perhaps changing the kernel version may change how the display EDID gets read.

As a side note if you run our 5.0 software you need to make a small change to re-enable the DSI to HDMI adapter support as this is disabled in 5.0 by default currently. This article has more info: https://developer.toradex.com/knowledge-base/display-output-resolution-and-timings-linux#Verdin_DSI_to_HDMI_Adapter_Support_on_Verdin_iMX8M_Mini_and_Linux_BSP_50

If that doesn’t work then I suppose there’s also the option of trying to force/load an alternative EDID file than what is provided by the display. Though this can be a bit more involved.

Best Regards,
Jeremias

Thank you for the reply, Jeremias.

I was previously running TorizonCore 4.0.0-devel-202007+build.17, but this was changed to TorizonCore 5.0 as advised. I tried installing all versions of 5.0 with containers several times and all of them get stuck on boot. So to solve one problem at a time I installed the basic version, which booted.

By following the steps in the link you provided the DTO was enabled, but the screen jitters just like in 4.0.

Also worth noting is that you were right about the Torizon Easy Installer screen. When in the Easy Installer, the screen works fine. So maybe the settings from there can somehow be used?

Kind regards,
Klitos

That is even more interesting that Easy Installer seems to work fine. I believe Easy Installer forces a typical VGA resolution/timings on all of our modules, Verdin included. Can you share what version of Easy Installer you were using with a correct display, just so I can confirm.

By the way can you try and see how your display functions on one of our non-Torizon BSP images. I mean Torizon is built and based on top of our non-Torizon BSP but I just want to see if this is a common issue or just a Torizon one. Unfortunately I don’t have a display here with the same issues you’re experiencing so I can’t confirm for myself.

Best Regards,
Jeremias

I’m not entirely sure which version of the Easy Installer I’m using, but it was one of the nightlies on the artifacts servers. I should add that the image does not exactly match the display as some of the image is under the display area, but the timings are right.

Tested on both BSP 5.0 and BSP 4.0, with the same results as Torizon.

Kind regards,
Klitos

Hi @KlitosP,

Are you using the Toradex Easy Installer with the “Fullscreen” option?

You can see some details about it here.

Please, just confirm which version of the Toradex Easy Installer are you using for our reference.

Abou the DSI-HDMI adapter on Verdin, it has a known issue that normally does not work with displays that do not reply to EDID, as you observed above.

Best regards,
André Curvello

Hello André,

I wasn’t given a choice for “Fullscreen” so I guess I’m using the default, although the interface does take up the whole screen. I load the TEI on the module using the USB OTG method and use it as it comes.

The TEI version is 2.0b6-nightly-20201028.

Would it be possible to use the HDMI on the module and solve the problem that way?

Kind regards,
Klitos

As André has said on further investigation there seems to be an issue with improper EDID via DSI-HDMI. Unfortunately despite the HDMI on the carrier board, the module itself only supports it via adapter through DSI.

We’re currently having discussions internally on possible workarounds for displays with improper EDID. For the time being can you possibly try other HDMI displays. It would help to know if you could possibly recreate this error on other HDMI displays so that we might know if there’s a common issue with problematic displays.

Best Regards,
Jeremias

Hi Jeremias,

Unfortunately I don’t have other small displays available. The module displays images fine on proper pc monitors (tested on two different models), but this is obviously not a solution.

I also tested what André suggested with the custom boot.scr. The image is the same as with the original boot.scr, so working but not exactly right on the y axis.

Could the variables passed to u-boot for the TEI be passed and not be overwritten by Linux? Although the TEI configuration is not perfect it is good enough to get things going.

Kind regards,
Klitos

We do have an idea that you maybe able to try on your side. We are also trying on our side but we don’t have too many problematic displays to test. So the idea is that it may be possible to overwrite the improper EDID coming from this display.

As documented here: https://developer.toradex.com/knowledge-base/display-output-resolution-and-timings-linux#Injecting_a_Binary_EDID_Blob

The Linux kernel has a feature to load your own EDID information. I checked and our software should have this feature enabled by default. The trick now is getting your own EDID binary file. There are EDID generators out there such as this: https://github.com/akatrevorjay/edid-generator

But in theory any method that produces an EDID binary should work with this method. Again we haven’t properly tested this out yet but if you could provide any feedback this would help greatly.

By the way for our reference and future testing what is the exact model of display you are experiencing issues with?

Best Regards,
Jeremias

Thanks for the info.

I’ve tried forcing one of the preset edid blobs to see the process but the /lib/firmware directory is read only in user space, how can this be overcome?

The display used is a hobbyist one and can be found here.

Something interesting I found is that the resolution is not actually bad when connected to the module. In fact it is better than in the TEI. This was not visible before because of the jittering, but when zoomed in the jittering goes away. I recorded a video showing this. It can be found here.

Another thing is that when executing get-edid | edid-decode on the module the output is slightly different from the laptop, and shows that the EDID read is compliant.
The output of the commands is:

EDID version: 1.3
Manufacturer: ADA Model 2100 Serial Number 20000080
Made in week 28 of 2009
Digital display
Maximum image size: 47 cm x 26 cm
Gamma: 1.00
DPMS levels: Off
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
  Red:   0.6484, 0.3388
  Green: 0.2822, 0.6025
  Blue:  0.1425, 0.0703
  White: 0.3134, 0.3291
Established timings supported:
Standard timings supported:
Detailed mode: Clock 50.250 MHz, 476 mm x 268 mm
               1024 1068 1156 1344 hborder 0
                600  603  609  625 vborder 0
               -hsync -vsync
               VertFreq: 59 Hz, HorFreq: 37388 Hz
Serial number: 0
Monitor ranges (GTF): 56-75Hz V, 30-83kHz H, max dotclock 210MHz
Monitor name: HDMI
Checksum: 0x89 (valid)

So the problem is the timings and not the resolution. As the resolution is non standard and is processed correctly, it is implied that the EDID is correct, which is backed up by the decoder. The jitter could be a re-drawing problem, but this does not make sense as when left untouched on a still image showing the whole screen it never settles like it does when zoomed in.

Kind regards,
Klitos

Well as with all display related technology it gets stranger the more we dig in. So the module gets different EDID information than what your laptop/PC receives?

As for the read-only filesystem, this is something unique to Torizon due to the OTA update framework it uses. For the time being you can force remount the filesystem as read/write with the following command: sudo mount -o remount,rw /dev/mmcblk2p2 /usr

This was for my system and it should be the same for you but make sure the mountpoints are correct for you as well just in case.

Best Regards,
Jeremias

Yes, it seems like. I’ve doubled checked and can confirm the two decoded EDID’s from above are correct.

The remounting worked, but the EDID does not get forced. I’ve tried a couple of different ones on both 5.0 and 4.0 and there is no change.

Are you aware of any display with capacitive touch which works with the Verdin Development Board out of the box? This one will only be used for development, so there is no point in fixing it since it takes so much effort.

Kind regards,
Klitos

Hi @KlitosP,

I’m to conduct some tests in “forcing” or trying to change the timing with a given EDID information. But I’m still to do these tests.

In the meantime, you asked about compatible displays.
We have this table of Supported Capacitive Displays based on feedback from our customers.

Unfortunately there arent’ too much information about Verdin Development Board support as Verdin is a quite new/recent platform.

But the chances of these displays to work with Verdin are quite high as they were proved to work with other modules.

Please let me know if that worked.

Best regards,
André Curvello

Hi André,

Okay, thank you for testing the EDID forcing and providing the display link.
I will have a look at the display options.

Kind regards,
Klitos

Hi @KlitosP,

Long time no see :slight_smile:

We had some improvements in the BSP 5.1.0 since our last contact.

So, if possible, I’d like to ask you to try your Verdin Development Board V1.0B with the MIPI DSI-HDMI adapter, but now flashing the module with the latest nightly of the Toradex Embedded Linux Reference Multimedia Image, Build 181 (2021-01-05) - with the monitor your know that “does not work”.

If that, for some reason still does not work, you can still try do to the following:

  • Download the “raw” 1920x1080.bin edid from edid-generator project, saving it at the /lib/firmware/edid folder at your target Verdin iMX8M Mini.
  • Then, reboot the board and stop the boot at U-Boot bootloader.
  • Create a environment variable called vidargs with the following content: drm.edid_firmware=edid/1920x1080.bin

Please tell me if it worked for you.

Thanks for the patience and for the attention.

Best regards,
André Curvello