HDMI (A06) supported modes; requirements for new mode with xrandr --newmode

bicyclesonthemoon · December 27, 2021, 8:29pm

Hello,
I would like to ask:
on the devterm a06, hdmi output what modes are supported?
If I create a new video mode with
xrandr --newmode
what are the requirements that this mode must fulfill to be supported on the devterm?

context: I successfully was able to connect TV, but now I want to connect a display with a non-standard resolution of 1024x600.

For the same display on PC and on raspberry pi 400 I could use
xrandr --newmode r600 49 1024 1064 1068 1312 600 603 610 624 +Hsync +VSync
but on devterm this particular setting is not supported.

I would like to find a mode which will be compatible with both the devterm and my display.
Where do I find out what is supported, what are the requirements?

Is this documented somewhere? where can I read this?

EDITED TO ADD:

after some experimenting I noticed that:

modes that don’t work on HDMI-1 do work on DSI-1 (but of course the internal display will not like them)
it looks like the difference between a supported and not supported mode is the pixel clock frequency, for example the same mode as described above but changed from 49.000MHz frequency to 40.000MHz (other parameters unchanged) suddenly works (but my display does not like it)

So now the question is: which pixel clock frequencies are supported on the HDMI-1 output of the a06 devterm?

Godzil · December 28, 2021, 1:31pm

I never had to add any new mode using xrandr. All (most?) HDMI display do explicitly tell the device you plugs them what are their capabilities, and there should be no need to do anything by hand.

Are you sure the microHDMI is properly seated in your DevTerm? A lot of cable do not fit properly if the side panel is on, try to plug your cable without it.

bicyclesonthemoon · December 28, 2021, 3:49pm

I am sure that the cable is not the problem.
With exactly the same cable I connect to a TV successfully.
And with this cable I can read the capabilities correctly.
Here is related fragment from xrandr --verbose:

HDMI-1 connected (normal left inverted right x axis y axis)
	Identifier: 0x41
	Timestamp:  112373
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID: 
		00ffffffffffff000481040001000000
		01110103800f0a000a00000000000000
		00000000000001010101010101010101
		01010101010124130020415818202804
		3700ffff0000001e0000001000000000
		00000000000000000000000000100000
		00000000000000000000000000000010
		000000000000000000000000000000dc
	max bpc: 0 
		range: (8, 16)
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 49 
		supported: 49
	non-desktop: 0 
		range: (0, 1)

If you decode the EDID with a tool you will see that it encodes the mode of 1024x600@59.85Hz and no other mode.

For comparison what I got with the same screen on raspberry pi 400:

HDMI-1 connected primary 1024x600+0+0 (0x42) normal (normal left inverted right x axis y axis) 150mm x 100mm
	Identifier: 0x40
	Timestamp:  9116
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	EDID: 
		00ffffffffffff000481040001000000
		01110103800f0a000a00000000000000
		00000000000001010101010101010101
		01010101010124130020415818202804
		3700ffff0000001e0000001000000000
		00000000000000000000000000100000
		00000000000000000000000000000010
		000000000000000000000000000000dc
	Broadcast RGB: Automatic 
		supported: Automatic, Full, Limited 16:235
	bottom margin: 0 
		range: (0, 100)
	top margin: 0 
		range: (0, 100)
	right margin: 0 
		range: (0, 100)
	left margin: 0 
		range: (0, 100)
	link-status: Good 
		supported: Good, Bad
	CONNECTOR_ID: 89 
		supported: 89
	non-desktop: 0 
		range: (0, 1)
  1024x600 (0x42) 49.000MHz +HSync +VSync *current +preferred
        h: width  1024 start 1064 end 1068 total 1312 skew    0 clock  37.35KHz
        v: height  600 start  603 end  610 total  624           clock  59.85Hz
  640x480 (0x43) 23.975MHz -HSync +VSync
        h: width   640 start  664 end  720 total  800 skew    0 clock  29.97KHz
        v: height  480 start  483 end  487 total  500           clock  59.94Hz

So the issue seems to be that the display announces only a single possible mode, and that mode is not supported by the devterm.
If I try to force it, this is what happens:

6.b:~> xrandr --newmode a600 49 1024 1064 1068 1312 600 603 610 624 +HSync +VSync
6.b:~> xrandr --addmode HDMI-1 a600
6.b:~> xrandr --verbose --output HDMI-1 --mode a600
crtc 1:         a600  59.85 +0+0 "HDMI-1"
xrandr: Configure crtc 1 failed
crtc 0: disable
crtc 1: disable
screen 0: revert
crtc 0: revert
crtc 1: revert
6.b:~>

(yes I already edited the command prompt environment variable)
If I do the same on DSI-1 instead of HDMI-1 it will be successful but the internal display will show wrong picture, obviously.

I also tried modes generated by cvt 1024 600 60 and gtf 1024 600 60 commands also without success.

However when I changed the frequency to 40MHz not changing anything I was able to create a mode which was successfully output by the devterm:

6.b:~> xrandr --newmode b600 40 1024 1064 1068 1312 600 603 610 624 +HSync +VSync
6.b:~> xrandr --addmode HDMI-1 b600
6.b:~> xrandr --verbose --output HDMI-1 --mode b600
crtc 1:         b600  48.86 +0+0 "HDMI-1"
6.b:~>

only that my display did not like the new timing and showed a horizontally distorted image.

What I would now like to know now is what is required for a video mode to be supported by the HDMI output of the a06 devterm.
Then I will be able to find a correct mode and overwrite the EDID of the problematic display so that the new supported mode is included and next time will be recognised automatically.
In fact, this EDID is already modified by me in the past, as the original was not compatible with the raspberry pi 400 which demands that all horizontal timings be even numbers.
And yes, I also tried the original mode on devterm, without success.

I do not know where and how to look for the information.
The page says that a06 contains Mali-T864 gpu. Can I find this information in some documentation of the gpu? but which document?
Or in the source of the OS? but where?

If I had a CM3 I would also swap the core and check how it works then but I don’t have.

Godzil · December 29, 2021, 12:53pm

The GPU is completely unrelated with the display pipeline itself.

Lots of TV that do have weird non standard pixel resolution do accept standard 720/1080 signals, it is not the best, but have you tried to feed it with such video output?

There is no HDMI Phy as it is the RK3399 which directly output the HDMI signal, so either it is not able to, or something is wrong in the driver (probably not well tested for weird screen/resolution)

I’m not sure what handle the RK3399 framebuffer, but it is most likely rockchip specific, and yes it is in the kernel, can’t say if there is any proper documentation though.

It is probably in that file (and some related):

bicyclesonthemoon · December 29, 2021, 4:03pm

I can force different resolutions but it looks wrong and is unacceptable:

(in this example connected to desktop computer with Debian 10 LXDE)

Thank you for the link but I am not able to find what.
Actually, I don’t understand much of it.

I kind of hoped to ‘follow the path’ from entering the mode in xrandr to the point where the values are accepted or rejected.
From xrandr I managed only to reach the XRRSetCrtcConfig function in xrrCrtc.c of libxrandr. Then comes X11 stuff which I don’t understand either.
also noticed that

[   566.501] (II) modeset(0): Allocate new frame buffer 1280x600 stride
[   566.572] (EE) modeset(0): failed to set mode: Invalid argument
[   566.595] (II) modeset(0): Allocate new frame buffer 1280x480 stride

appears in /var/log/Xorg.0.log

If not this forum, what would be the good place to ask about this?

bicyclesonthemoon · December 30, 2021, 3:11pm

Next post, to announce my success.

As I noticed that the only issue is with the pixel clock when all other parameters are in reasonable ranges,
I created a script which checked every setting between 12MHz and about 110Mz.
After a few hours the discovered working frequencies are:

27
36
40
54
65
65.001
65.002
66
74.25
83.5
106.5
108

(all in MHz)
I noticed additionally, when I connected a HDTV that indeed all available modes use these clocks only:

  1920x1080 (0x1ba0e) 148.500MHz +HSync -VSync +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0x1ba0f) 148.500MHz +HSync +VSync
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
  1920x1080 (0x1ba10) 148.500MHz +HSync +VSync
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  56.25KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  50.00Hz
  1920x1080i (0x1ba11) 74.250MHz +HSync +VSync Interlace
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  33.75KHz
        v: height 1080 start 1084 end 1094 total 1125           clock  60.00Hz
  1920x1080i (0x1ba12) 74.250MHz +HSync +VSync Interlace
        h: width  1920 start 2448 end 2492 total 2640 skew    0 clock  28.12KHz
        v: height 1080 start 1084 end 1094 total 1125           clock  50.00Hz
  1920x1080 (0x1ba13) 74.250MHz +HSync +VSync
        h: width  1920 start 2558 end 2602 total 2750 skew    0 clock  27.00KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  24.00Hz
  1280x1024 (0x1ba14) 108.000MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock  63.98KHz
        v: height 1024 start 1025 end 1028 total 1066           clock  60.02Hz
  1280x960 (0x1ba15) 108.000MHz +HSync +VSync
        h: width  1280 start 1376 end 1488 total 1800 skew    0 clock  60.00KHz
        v: height  960 start  961 end  964 total 1000           clock  60.00Hz
  1280x720 (0x1ba16) 74.250MHz +HSync +VSync
        h: width  1280 start 1390 end 1430 total 1650 skew    0 clock  45.00KHz
        v: height  720 start  725 end  730 total  750           clock  60.00Hz
  1280x720 (0x1ba17) 74.250MHz +HSync +VSync
        h: width  1280 start 1720 end 1760 total 1980 skew    0 clock  37.50KHz
        v: height  720 start  725 end  730 total  750           clock  50.00Hz
  1024x768 (0x302) 65.000MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock  48.36KHz
        v: height  768 start  771 end  777 total  806           clock  60.00Hz
  800x600 (0x303) 40.000MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock  37.88KHz
        v: height  600 start  601 end  605 total  628           clock  60.32Hz
  800x600 (0x304) 36.000MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock  35.16KHz
        v: height  600 start  601 end  603 total  625           clock  56.25Hz
  720x576 (0x1ba18) 27.000MHz -HSync -VSync
        h: width   720 start  732 end  796 total  864 skew    0 clock  31.25KHz
        v: height  576 start  581 end  586 total  625           clock  50.00Hz
  720x480 (0x1ba19) 27.000MHz -HSync -VSync
        h: width   720 start  736 end  798 total  858 skew    0 clock  31.47KHz
        v: height  480 start  489 end  495 total  525           clock  59.94Hz

with this knowledge I was able 2 generate 2 video modes compatible with my display modes using the 54MHz clock.
(closest to original 49MHz, also my display doesn’t like 40MHz apparently)

  1024x600 (0x2d7) 54.000MHz +HSync -VSync
        h: width  1024 start 1072 end 1104 total 1184 skew    0 clock  45.61KHz
        v: height  600 start  603 end  613 total  621           clock  73.44Hz
  1024x600 (0x2d8) 54.000MHz -HSync +VSync *current
        h: width  1024 start 1064 end 1168 total 1312 skew    0 clock  41.16KHz
        v: height  600 start  603 end  613 total  626           clock  65.75Hz

I reprogrammed my display’s EDID to include the modes and now the devterm finally recognises it correctly:

success.

Bonus content:
If you are wondering how I reprogrammed the display:

I made a custom adapter connected to raspberry pi 400:

I prepared the file edid1.txt:

EDID BYTES:
0x   00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
    ------------------------------------------------
00 | 00 FF FF FF FF FF FF 00 04 81 04 00 01 00 00 00
10 | 01 11 01 03 80 0F 0A 00 0A 00 00 00 00 00 00 00
20 | 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01
30 | 01 01 01 01 01 01 24 13 00 20 41 58 18 20 28 68
40 | 37 00 FF FF 00 00 00 1E 18 15 00 20 41 58 1A 20
50 | 28 68 3A 00 FF FF 00 00 00 1C 18 15 00 A0 40 58
60 | 15 20 30 20 3A 00 FF FF 00 00 00 1A 00 00 00 10
70 | 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58

and a script upload_edid.pl:

#!/usr/bin/perl

use strict;

if (@ARGV<2)
{
	print STDERR "arg missing.\n";
	exit 1;
}

my $i2c = $ARGV[0];
my $path = $ARGV[1];
my $file;
my $line;
my @edid;
my $i=0;

unless (open($file, "<", $path)) {
	print STDERR "file open fail.\n";
	exit 1;
}

while (defined($line = <$file>)) {
	if ($line =~ /\|(.*)$/) {
		$line = $1;
		while ($line =~ /^\s([0-9a-fA-F]{2})(.*)$/) {
			$edid[$i] = $1;
			$line = $2;
			++$i;
		}
	}
}
close ($file);

for ($i=0; $i<128; ++$i) {
	system(
		'i2cset', '-y', $i2c, '0x50',
		sprintf ('0x%02x', $i),
		'0x'.$edid[$i]
	);
}

and then I :

7.b:~/lcd> i2cdetect -l
i2c-1	i2c       	bcm2835 (i2c@7e804000)          	I2C adapter
7.b:~/lcd> ./upload_edid.pl 1 ./edid1.txt

And that’s all.
‘i2c’ was listed with index 1 (starting from 0), that’s why the parameter is 1.

I successfully finished dealing with this issue but I still have other.
Expect more questions soon.

EDITED TO ADD:
but in text mode (tty1, ctrl + alt + F1) it is rotated.
How to fix this?

Godzil · December 30, 2021, 7:28pm

That’s an interesting output you have there.

From my experience, you have two things that try to output different resolutions/pixel clocks.

It is highly possible that xrandr is unable to setup the thing properly and only set one part of the while thing.

But good you manage to find a solution

bicyclesonthemoon · December 30, 2021, 11:16pm

This looks like a combination of 2 things:

devterm being very specific about what signal (with what frequency) it will produce
display being very specific about what signal it will accept

Luckily i was able to brute force through the clock frequencies (with 1kHz steps) for half a day, making the poor display blink for hours.
I had some idea what to do because of dealing with video signal timings multiple times in the past and trying to make the same display cooperate with the raspberry a few months ago.
(actually I ordered the pi and the devterm almost at the same time)

About the rotation in text mode:
I am aware that the display is actually 480x1280, not 1280x480.
xrandr, etc can deal with it fine.

the text mode however is something else.
In /boot/armbianEnv.txt there is fbcon=rotate:1
this rotates the ‘framebuffer console’ (The Framebuffer Console — The Linux Kernel documentation) back to expected position.

But in this mode all displays show the same framebuffer console, the rotation affects them all.

What I would need would be to not rotate the framebuffer console but do it 1 level lower, do the rotation on the framebuffer driver / video driver in a way which affects only the internal display.

At this point I don’t know yet how to achieve this.
(it is not as important as it was to make the screen work in gui mode at all)

Topic		Replies	Views
Output HDMI (external display) DevTerm	6	894	January 7, 2022
Looking for experiences with hdmi output DevTerm devterm-a06	6	635	January 18, 2022
No HDMI on A04? DevTerm hardware , a04	7	853	January 25, 2022
Devterm A04 changed to CM4, now able to do hdmi out! DevTerm	0	236	December 7, 2023
R01 and HDMI output DevTerm hardware , video	10	915	November 16, 2022

HDMI (A06) supported modes; requirements for new mode with xrandr --newmode

Related Topics