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.
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.
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.
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.
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?
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.
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.
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?
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.
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.
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.
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?
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.
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.
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.
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:
