There is the big question I can’t answer…where in the chain of EDID data to video driver configuration does EDID get parsed for actual video mode? I’m hoping someone with access within the video driver can find out if in this particular case (the EDID data is listed for reference above at [url]https://devtalk.nvidia.com/default/topic/985264/jetson-tx1/black-virtual-consoles-on-l4t-64-bits-r24-rev-2-1/post/5054328/#5054328[/url] to make this repeatable) the video is not configuring correctly based on a mistake in EDID parsing. Actual behavior tends to suggest there is an EDID parse error even if http://www.edidreader.com says the data is valid.
Here is some followup information I’ve found. I’m restating the EDID information for pasting into http://www.edidreader.com (this can be considered as a way to reproduce the bug since the data is valid but does not result in a working display during automatic configuration):
00 ff ff ff ff ff ff 00 1e 6d 84 57 0f 95 04 00
05 15 01 03 ea 30 1b 78 ea 33 33 a5 55 4d 9d 25
11 50 52 a5 4b 00 b3 00 81 80 81 8f 71 4f 01 01
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 dd 0c 11 00 00 1a 21 39 90 30 62 1a 27 40
68 b0 36 00 dd 0c 11 00 00 1c 00 00 00 fd 00 38
4b 1e 53 0f 00 0a 20 20 20 20 20 20 00 00 00 fc
00 57 32 32 34 36 0a 20 20 20 20 20 20 20 00 a8
When at edidreader.com, the “Timing Bitmap” lists what are considered “standard timings” on the right, and then a check box on the left for modes this monitor specifically works with. The standard timings are a set of timnings always available in X servers. Those timings can be found in the TX1’s xserver-xorg source code at “xorg-server-1.18.4/hw/xfree86/ddc/print_edid.c”, function “print_established_timings”. So every mode in that file should be available if the monitor can work with those timings; in this case these timings are standard with “x” to mark those available for this case:
x 720×400 @ 70 Hz
720×400 @ 88 Hz
<b>x 640×480 @ 60 Hz</b>
640×480 @ 67 Hz
640×480 @ 72 Hz
<b>x 640×480 @ 75 Hz</b>
800×600 @ 56 Hz
<b>x 800×600 @ 60 Hz</b>
800×600 @ 72 Hz
<b>x 800×600 @ 75 Hz</b>
832×624 @ 75 Hz
1024×768i @ 87 Hz
<b>x 1024×768 @ 60 Hz</b>
1024×768 @ 72 Hz
[b]x 1024×768 @ 75 Hz
x 1280×1024 @ 75 Hz[/b]
1152x870 @ 75 Hz
It should be guaranteed that if EDID is readable that at least one of those modes within EDID would be picked. If not, then the docs show that “the server uses default timing information which supports 640x480, 800x600 and 1024x768 all with a 60Hz refresh rate”…meaning any fallback mode for a case of no EDID used and no timings found in a manually configured file should result in that subset of 60Hz modes…and the monitor in question supports those modes. So I’m trying to figure out why no valid mode was reached even if no EDID was found. Documentation within the Xorg source code specific to this Xorg release gives this information.
There are only two possibilities…
The first of two possibilities is that the EDID is found and the mode found and used is corrupt…meaning the drivers think their idea of valid modes via EDID is correct when in reality EDID was either not correctly parsed or was otherwise passed to another function in a way which corrupts previously valid parsing.
The second of two possibilities is that drivers know EDID failed and know that no manually created entries in xorg.conf exist, and so it falls back to a default mode…however, the default mode would not be one of those required: 640x480@60Hz, 800x600@60Hz, or 1024x768@60Hz (this is known because this monitor works at those resolutions…so does mine).
If something is corrupt in EDID, then we know i2c query was not the cause, the “/sys” edid file is correct in every case, even cases where “get-edid | parse-edid” or “get-edid | edid-decode” fail to read (for example, the above output of this example:
EDID block does not conform at all!
Bad year of manufacture
Manufacturer name field contains garbage
So if the first possibility is the problem (corrupted data), then there must be an error parsing or an error at passing the EDID modes to various functions. Raw EDID data is validated via checksum.
I don’t think the second possibility (incorrect fallback mode) is it…the fallback modes and the code to use those have been around a long time. My own monitor, during boot (prior to graphical stage), “says scan rate too fast”…I think EDID is being interpreted incorrectly since my monitor also supports all standard modes of fallback when no automatic configuration data is available.
Would it be possible for someone who works on the video driver code to paste in this sample EDID and see if the modes the driver receives are corrupt? Or if perhaps Xorg passes something through which is not even in the EDID listing?
Hi linuxdev and Honey_Patouceul,
Many thank for the experiments you’ve done and the summary of possibilities.
We will have team to investigate this issue.
Thanks
If serial console is available on any of your carrier boards you could post a log.
Hi Honey_Patouceul and linuxdev,
I am new to this topic. Could you make a brief summary here?
Even unplugging/replugging the monitor would cause the X to VGA resolution?
Hi Wayne,
Here is a brief summary. On my TX1 with L4T R24.2.1 with some monitors (such as mentioned LG Flatron W2246 or ASUS VW220TE), at boot time I don’t see kernel boot traces, but when X starts it works.
However, switching to console mode (Alt-Ctl-F1), I get unsupported mode so black screen.
I have found that if I unplug the HDMI cable while in X mode, then switch to console mode, then replug the HDMI then it usually works in console mode.
Switching back to X leads sometimes to VGA mode.
Even weirder, switching then to console and back to X mode again, I get a black screen with only the arrow pointer of the mouse alive. Seems stuck.
Let me know if you cannot reproduce or want me to do some extra tests.
Hi Honey_Patouceul,
I found there is an error in fbcon_blank. This would be fixed.
I will upload a patch for this if you would like to build kernel.
Hi Wayne,
Thanks for investigating this. Did you find another error than the one fixed by [url]Switching to tty1-6 - Jetson TX1 - NVIDIA Developer Forums on R24.1?
I’ve had no time to try it yet, I’ll wait for your patch.
My patch fixes the same error as your link. It is an unexpected coincidence.
diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c
index b47ba45..f44ec69 100644
--- a/drivers/video/console/fbcon.c
+++ b/drivers/video/console/fbcon.c
@@ -2367,7 +2367,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
}
}
- if (!fbcon_is_inactive(vc, info)) {
+ if (!fbcon_is_inactive(vc, info) || mode_switch) {
if (ops->blank_state != blank) {
ops->blank_state = blank;
fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
--
2.1.4
Hello,
Rather than creating a new topic, I’m posting here as I believe the issue I encounter is related to this one. Please don’t hesitate to recommend to create another one, if you think it is better.
To summarise:
- Resolution 1280x720,
- Graphic is working,
- Honey_Patouceul woraround is working (unplug / replug HDDMI cable).
So, I am using 1280x720 resolution for my tests, and the graphic display is good. I use xrandr to setup this resolution:
xrandr --display :0.0 --output HDMI-0 --mode 1280x720
When switching to VT1 (CTRL+ALT+F1), I can see only a new line in /var/log/kern.log:
kernel: [58089.235972] tegradc tegradc.1: nominal-pclk:74250000 parent:594000000 div:8.0 pclk:74250000 73507500~80932500
If I use Honey_Patouceul’s workarounds, when replugging the HDMI cable I am able to see the console.
I have tried both referenced kernel patches (Honey_Patouceul and WayneWWW) without any success for my use case.
Please let me know if I can provide more information.
Thanks,
NicoD
You may want to post the output of:
sudo -s
cat `find /sys -name 'edid'`
exit
Hi Linuxdev,
I’m not able to find any ‘edid’ entry in /sys, (/sys/kernel/debug/tegradc.1/edid does not exist on my system - r21.5 modified), but I can find the following:
# cat /sys/kernel/debug/edid0
No EDID
# cat /sys/kernel/debug/edid1
edid[000] = 00 ff ff ff ff ff ff 00 10 ac 65 a0 53 59 32 31
edid[010] = 03 16 01 03 80 30 1b 78 ea 81 f5 a3 57 53 9f 27
edid[020] = 0a 50 54 a5 4b 00 71 4f 81 80 d1 c0 01 01 01 01
edid[030] = 01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
edid[040] = 45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 59 50 59
edid[050] = 34 4e 32 31 48 31 32 59 53 0a 00 00 00 fc 00 44
edid[060] = 45 4c 4c 20 53 54 32 32 32 30 4c 0a 00 00 00 fd
edid[070] = 00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 01 89
edid[080] = 02 03 1f f1 4c 90 05 04 03 02 07 16 01 14 1f 12
edid[090] = 13 23 09 07 07 65 03 0c 00 10 00 83 01 00 00 02
edid[0a0] = 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00
edid[0b0] = 1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 dd 0c 11
edid[0c0] = 00 00 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 dd
edid[0d0] = 0c 11 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96
edid[0e0] = 00 dd 0c 11 00 00 18 00 00 00 00 00 00 00 00 00
edid[0f0] = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 af
I’ve added the output of the command:
# get-edid | edid-decode
This is read-edid version 3.0.1. Prepare for some fun.
Attempting to use i2c interface
No EDID on bus 0
No EDID on bus 1
No EDID on bus 2
No EDID on bus 4
No EDID on bus 5
1 potential busses found: 3
256-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Extracted contents:
header: 00 ff ff ff ff ff ff 00
serial number: 10 ac 65 a0 53 59 32 31 03 16
version: 01 03
basic params: 80 30 1b 78 ea
chroma info: 81 f5 a3 57 53 9f 27 0a 50 54
established: a5 4b 00
standard: 71 4f 81 80 d1 c0 01 01 01 01 01 01 01 01 01 01
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00 1e
descriptor 2: 00 00 00 ff 00 59 50 59 34 4e 32 31 48 31 32 59 53 0a
descriptor 3: 00 00 00 fc 00 44 45 4c 4c 20 53 54 32 32 32 30 4c 0a
descriptor 4: 00 00 00 fd 00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20
extensions: 01
checksum: 89
Manufacturer: DEL Model a065 Serial Number 825383251
Made week 3 of 2012
EDID version: 1.3
Digital display
Maximum image size: 48 cm x 27 cm
Gamma: 2.20
DPMS levels: Standby Suspend Off
Supported color formats: RGB 4:4:4, YCrCb 4:2:2
First detailed timing is preferred timing
Established timings supported:
720x400@70Hz
640x480@60Hz
640x480@75Hz
800x600@60Hz
800x600@75Hz
1024x768@60Hz
1024x768@75Hz
1280x1024@75Hz
Standard timings supported:
1152x864@75Hz
1280x1024@60Hz
1920x1152@60Hz
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Serial number: YPY4N21H12YS
Monitor name: DELL ST2220L
Monitor ranges: 56-76HZ vertical, 30-83kHz horizontal, max dotclock 170MHz
Has 1 extension blocks
Checksum: 0x89
CEA extension block
Extension version: 3
27 bytes of CEA data
Video data block
VIC 16 (native)
VIC 05
VIC 04
VIC 03
VIC 02
VIC 07
VIC 22
VIC 01
VIC 20
VIC 31
VIC 18
Audio data block
Vendor-specific data block, OUI 000c03 (HDMI)
Source physical address 1.0.0.0
Speaker allocation data block
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 148.500 MHz, 477 mm x 268 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Detailed mode: Clock 74.250 MHz, 477 mm x 268 mm
1920 2008 2052 2200 hborder 0
540 542 547 562 vborder 0
+hsync +vsync interlaced
Detailed mode: Clock 74.250 MHz, 477 mm x 268 mm
1280 1390 1430 1650 hborder 0
720 725 730 750 vborder 0
+hsync +vsync
Detailed mode: Clock 27.000 MHz, 477 mm x 268 mm
720 736 798 858 hborder 0
480 489 495 525 vborder 0
-hsync -vsync
Checksum: 0xaf
Thanks,
NicoD
Hi NicoD,
Welcome to this thread :)
Is it mandatory for you to stick to R21.5 ? Many bugs have been fixed since then.
On my side I have no time to investigate this further from now, I appreciate @WayneWWW suggestion but cannot test it for a while (it came late, most of my tasks were acheived from ssh and some with my workaroud).
I also can tell that this issue is not happening with TX2 on R27. If TX1 gets a linux 4.x kernel this might improve…
Hi Honey_Patouceul,
I could give it a try with another version of L4T, but I have to stick to TK1: as far as I know, 21.5 is the latest release for this device. Is it not?
According to https://developer.nvidia.com/embedded/develop/software, it is.
Thanks,
NicoD
Sorry, I was missing you are facing this on TK1… I suppose you should not expect a 4.x kernel for TK1.
On the other hand, TK1 should have messages about EDID parsing in dmesg. Could you check it ?
I did notice something interesting from the edid-decode, although it looks in general like a very normal monitor. If you paste the EDID data into http://www.edidreader.com, then you’ll see descriptor 1 includes 1920x1080. EDID pasted here again for convenience:
00 ff ff ff ff ff ff 00 10 ac 65 a0 53 59 32 31
03 16 01 03 80 30 1b 78 ea 81 f5 a3 57 53 9f 27
0a 50 54 a5 4b 00 71 4f 81 80 d1 c0 01 01 01 01
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 dd 0c 11 00 00 1e 00 00 00 ff 00 59 50 59
34 4e 32 31 48 31 32 59 53 0a 00 00 00 fc 00 44
45 4c 4c 20 53 54 32 32 32 30 4c 0a 00 00 00 fd
00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 01 89
02 03 1f f1 4c 90 05 04 03 02 07 16 01 14 1f 12
13 23 09 07 07 65 03 0c 00 10 00 83 01 00 00 02
3a 80 18 71 38 2d 40 58 2c 45 00 dd 0c 11 00 00
1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 dd 0c 11
00 00 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 dd
0c 11 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96
00 dd 0c 11 00 00 18 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 af
Even so, I don’t see 1920x1080 in the edid-decode output. I also see edid-decode allowing 1920x1152, but don’t understand from edidreader.com where this came from. Descriptor 2 shows 1920x540, which is a bit unusual, but this too is missing from edid-decode. I am wondering where the wrong modes came from and where the missing correct modes (especially 1920x1080) went to.
I am not so familiar with Edids I have to admit. Right now, I’ve found a faster workaround:
- Configure 1080p screen in 720p: xrandr --display :0.0 --output HDMI-0 --mode 1280x720,
- xrandr --display :0.0 --output HDMI-0 --mode 1920x1080 (to get back to 1080p),
- CTRL+ALT+F1 to switch to VT1: I can see login prompt,
- CTRL+ALT+F7 to switch back to graphic VT,
- xrandr --display :0.0 --output HDMI-0 --mode 1280x720 (to get back to 720p).
I’m not sure it really helps btw…
NicoD
It is useful to know those modes work even if auto config does not. Someone at NVIDIA may be interested in that above EDID data and why edid-decode failed to match the modes shown at edidreader.com. Somewhere in there I believe is a legitimate bug hitting only some modes.