I’m using default kernel configuration.
Yes, the desktop Ubuntu had this dmesg log:
i2c i2c-8: sendbytes: NAK bailout.
Anyway, I had a chance to test “get-edid” command on a Jetson TK1 board and had no error at all. I didn’t have time to try changing the refresh rate and whatsoever, but it seems quite promising…
Without actual hardware to work with I’m not sure how accurate this answer is, but the NAK bailout message is from an i2c driver sending data to a slave. The actual kernel code and comment in “drivers/i2c/algos/i2c-algo-bit.c”:
/* A slave NAKing the master means the slave didn't like
* something about the data it saw. For example, maybe
* the SMBus PEC was wrong.
*/
} else if (retval == 0) {
dev_err(&i2c_adap->dev,
"sendbytes: NAK bailout on byte %d\n", count);
return -EIO;
From what I can tell sometimes i2c devices have quirks and there are a lot of workarounds for specific quirks, e.g., writing three bytes may fail to get a slave response (NAK), but writing two bytes and then one byte (the same bytes) would succeed (ACK). It looks like this monitor may have one of those quirks (you’d have to look at the actual i2c conversation to know for sure). The question then becomes how the software communicating over i2c deals with exceptions…it seems that the JTX1 simply isn’t dealing with the quirks and also isn’t dealing with errors…whereas on the machines where the monitor works either the software deals with the quirks or the error is handled differently (by dealing with quirks I mean knowing there is a problem and compensating…versus how the software behaves if quirks are not accounted for and an error causes bailout will the program continue or will the program crash and burn).
If there is an error in the monitor’s EDID response to a query and Jetson does not handle the error, it isn’t really the Jetson’s fault. On the other hand, no matter where the fault is, if there is a more graceful way to deal with an error, “it would be a good thing” to do so. Curiosity makes me wonder what may have changed between JTK1 and JTX1 where the NAK bailout was not fatal for JTK1 and JTX1 does not handle it.
I had a chance to test Jetson TK1 again. The funny thing is I could execute get-edid, parse-edid and edid-decode, however ‘no acknowledge’ error appears in the dmesg log. Unfortunately, adding a new resolution/refresh rate mode in xrandr made the same error as the TX1.
Here are the outputs of Jetson TK1:
ubuntu@Jetson-TK1:~$ sudo get-edid | parse-edid
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
128-byte EDID successfully retrieved from i2c bus 3
Looks like i2c was successful. Have a good day.
Checksum Correct
Section "Monitor"
Identifier "23MB35"
ModelName "23MB35"
VendorName "GSM"
# Monitor Manufactured week 5 of 2015
# EDID version 1.3
# Digital Display
DisplaySize 510 290
Gamma 2.20
Option "DPMS" "true"
Horizsync 30-83
VertRefresh 56-75
# Maximum pixel clock is 150MHz
#Not giving standard mode: 1152x864, 75Hz
#Not giving standard mode: 1280x720, 60Hz
#Not giving standard mode: 1280x800, 60Hz
#Not giving standard mode: 1280x1024, 60Hz
#Not giving standard mode: 1440x900, 60Hz
#Not giving standard mode: 1400x1050, 60Hz
#Not giving standard mode: 1600x900, 60Hz
#Not giving standard mode: 1680x1050, 60Hz
Modeline "Mode 0" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
EndSection
ubuntu@Jetson-TK1:~$ sudo 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
128-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: 1e 6d 3e 5a de 13 02 00 05 19
version: 01 03
basic params: 80 33 1d 78 ea
chroma info: 62 75 a3 55 4f a0 27 12 50 54
established: a7 6b 80
standard: 71 4f 81 c0 81 00 81 80 95 00 90 40 a9 c0 b3 00
descriptor 1: 02 3a 80 18 71 38 2d 40 58 2c 45 00 fe 22 11 00 00 1e
descriptor 2: 00 00 00 fd 00 38 4b 1e 53 0f 00 0a 20 20 20 20 20 20
descriptor 3: 00 00 00 fc 00 32 33 4d 42 33 35 0a 20 20 20 20 20 20
descriptor 4: 00 00 00 ff 00 35 30 35 4e 54 53 55 34 30 31 35 38 0a
extensions: 00
checksum: 8e
Manufacturer: GSM Model 5a3e Serial Number 136158
Made week 5 of 2015
EDID version: 1.3
Digital display
Maximum image size: 51 cm x 29 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@56Hz
800x600@60Hz
800x600@75Hz
832x624@75Hz
1024x768@60Hz
1024x768@75Hz
1280x1024@75Hz
1152x870@75Hz
Standard timings supported:
1152x864@75Hz
1280x768@60Hz
1280x800@60Hz
1280x1024@60Hz
1440x900@60Hz
1400x1050@60Hz
1600x960@60Hz
1680x1050@60Hz
Detailed mode: Clock 148.500 MHz, 510 mm x 290 mm
1920 2008 2052 2200 hborder 0
1080 1084 1089 1125 vborder 0
+hsync +vsync
Monitor ranges: 56-75HZ vertical, 30-83kHz horizontal, max dotclock 150MHz
Monitor name: 23MB35
Serial number: 505NTSU40158
Checksum: 0x8e
[ 5478.959650] tegra-i2c tegra12-i2c.0: no acknowledge from address 0x50
[ 5478.960209] tegra-i2c tegra12-i2c.1: no acknowledge from address 0x50
[ 5478.961408] tegra-i2c tegra12-i2c.2: no acknowledge from address 0x50
[ 5478.962294] tegra-i2c tegra12-i2c.4: no acknowledge from address 0x50
[ 5479.963027] tegra-i2c tegra12-i2c.5: --- register dump for debugging ----
[ 5479.977974] tegra-i2c tegra12-i2c.5: I2C_CNFG - 0x2c00
[ 5479.993743] tegra-i2c tegra12-i2c.5: I2C_PACKET_TRANSFER_STATUS - 0xff0001
[ 5480.001426] tegra-i2c tegra12-i2c.5: I2C_FIFO_CONTROL - 0xe0
[ 5480.008179] tegra-i2c tegra12-i2c.5: I2C_FIFO_STATUS - 0x800040
[ 5480.014676] tegra-i2c tegra12-i2c.5: I2C_INT_MASK - 0xed
[ 5480.020805] tegra-i2c tegra12-i2c.5: I2C_INT_STATUS - 0x0
[ 5480.026530] tegra-i2c tegra12-i2c.5: msg->len - 1
[ 5480.032220] tegra-i2c tegra12-i2c.5: is_msg_write - 1
[ 5480.038300] tegra-i2c tegra12-i2c.5: next_msg->len - 1
[ 5480.043997] tegra-i2c tegra12-i2c.5: is_next_msg_write - 0
[ 5480.049792] tegra-i2c tegra12-i2c.5: buf_remaining - 1
[ 5480.055812] tegra-i2c tegra12-i2c.5: i2c transfer timed out, addr 0x0050, data 0x00
ubuntu@Jetson-TK1:~$ xrandr --addmode HDMI-0 1920x1080_60.00
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 140 (RANDR)
Minor opcode of failed request: 18 (RRAddOutputMode)
Serial number of failed request: 23
Current serial number in output stream: 24
This may be a case of doing some good to send the information to the email address which shows up when get-edid fails. It may be one of those monitors which could get EDID query adjusted for quirks. If you are very motivated, you could still find out what a valid EDID response would be for that monitor and manually configure X11…not an easy thing to do.
I don’t know how changing the resolution/refresh rate works in the background, but is “get-edid” or i2c communication really necessary for that? In other words, is it a “get-edid” problem or an “xrandr” problem?
The early monitors had a 15-pin D-sub connector. None of those pins allowed a graphics card to find out what is on the 15-pin connector. All monitors…100%…required configuration to be blindly added on all operating systems. This was done by starting in an agreed-upon low performance video mode, e.g., 640x480 at some low color depth and slow scan rate, and then copying the specification file to that operating system’s configuration table. The configuration table layout would be different for all environments, so for example the driver disk would need to have been ported or have some knowledge for each operating system. People spent time hand tweaking mode lines, and alternating to a rescue disk when video never came back up.
Enter the next era…ISA bus cards which required manually set jumpers for IRQ and address gave way to PCI, where the card itself was queried and a minimal driver was available in the PCI equivalent of a BIOS. No more hand setting of jumpers and making sure the operating system had been manually set to match the jumpers…it was now automatic. Video followed this, and 15-pin D-sub connectors gave way to DVI and other wiring which had a similar ability to be queried by the video card.
The response by a monitor to a query is somewhat analogous to a BIOS, and contains all of the information the old driver disk had, but in a uniform and standardized format. Software in the operating system could use the DVI’s query wire (or now HDMI and DisplayPort) to get a single standard layout set of details for that monitor, and automatically convert to its own configuration format for that operating system.
The protocol used for communications on that monitor query channel is i2c. Many things in the embedded world use i2c, not just monitors. xrandr and get-edid are front ends to i2c specific to monitors…they understand i2c, but deal only with parsing DDC/EDID data formats. The monitor is not providing the correct conversation in some cases, while working in other cases. Neither xrandr nor get-edid are at fault, as there is no definition of how they should behave when the monitor has a broken response which cuts off in the middle of a query. Gracefully handling errors is more of an art than a science. The software which queries the monitor exists in multiple places…some places handle errors differently from other places (e.g., a software text-mode frame buffer, versus hardware accelerated GUI…software developed independently of each other).
If the monitor fails to communicate in a defined way over i2c, it is the monitor at fault, but software may be able to compensate for it if it is a known problem…software just isn’t required to do so. If the i2c channel on the computer is causing the problem, then it is the hardware/driver fault…still not the fault of get-edid or xrandr. To know exactly what is wrong would require placing an i2c protocol analyzer on the line and comparing the conversation between monitor and computer to see which side failed to follow the DDC/EDID/i2c requirements.
The email address you may sometimes see from get-edid failing is more or less about the art of adding more graceful error handling for this monitor’s error scenario.
Thank you very much for taking the time to explain this to me!
I have written an email to the almighty Matthew Kern. I hope he will provide some good news.