Hi All,
I have just found that X11 form L4T 24.1 even x32 bit version cannot detect correctly MIPI DSI display 720x1280.
It worked well in L4T 23.2
Identifier “DSI-0” in section “Monitor” cannot be recognized.
This way I even have no chance to disable it in xorg.conf…
Hello, :
I tried 24.1 and DSI display works well in my side.
Do you add your own panel? You can check difference between 23.2 and 24.1 kernel source, and refer to your hardware change to find some clues.
br
ChenJian
Hello!
Thank you for your comment.
X11 starts on my panel, but interrupt session with message “low resolution”.
The kernel code is absolutely the same.
Moreover, framebuffer and fb console is working perfectly and same as on 23.2
I’m sure that X11 in 24.1 is buggy.
Did you try:
Section "Monitor"
Identifier "DSI-0"
Option "Ignore"
EndSection
in xorg.conf?
It is not working!!!
Please comment.
You may need to install packages “read-edid” and “edid-decode” for this test, but what do you see from:
sudo get-edid | parse-edid
sudo get-edid | edid-decode
Thanks, linuxdev!
I will try and write here.
But unfortunately later. I have to stay on more stable for me L2T 23.2 until all the functional parts will work together due to extremely tight development schedule.
Interesting that I have no such problem on L2T 23.2…
Hi Linuxdev,
finally I have tried get-edid
Unfortunately, it works only with i2c and must be very useful for HDMI, but not for DSI.
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 3
No EDID on bus 4
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Unfortunately I do not know enough about DSI, but you are correct that EDID uses i2c query of the monitor. This is more or less a standard method in X11 for automatic discovery of what a monitor’s capabilities are (the EDID software directly fills in the correct xorg.conf info whenever the monitor is detected…X does not care that the information is in RAM from a query or if it is from a file).
X can be configured by other methods, e.g., manually adding the required details to the Xorg.conf file, or simply having a monitor which has a valid configuration at the Xorg server’s default settings (a case of coincidentally working). Unless X ends up with a configuration matching a valid monitor configuration, you will get a failure.
For your DSI monitor, somewhere is probably a publication of its specifications such that you could manually enter the “/etc/xorg.conf” values for “DSI-0”. The program “gtf” may help with this, plus there are online web-based modeline calculators such as:
[url]http://arachnoid.com/modelines/[/url]
You could compare the output of the existing xorg.conf file, the output of a working monitor which has correct EDID, and translate specifications from the DSI device into that format…editing directly into the xorg.conf.
Thank you. I will try.
For me the problem becomes because of changing X11. In release 23.2 it worked perfectly…
But not now. And it is very hard to understand a reason…
DSI have a negotiations inside the protocol. The Protocol is closed. We are not a member of MIPI, it is too expensive for a medium company…
If it worked before, but not now, it tends to be from a change in defaults. The prior default matched something your display could handle, the current default does not. No EDID means no automated query.
Yes, a big hinderance to building display products with any proprietary interface (which includes eDP) is the extreme cost of information (thousands of dollars) from standards publishers. One has to rely on examples of implementations without any standards being available, e.g., good data sheets on display products which use that interface for their reference implementation. I really like the USB.org system where they publish information and fees are generally for labeling instead. In many cases chips for USB implementation offer use of the chip supplier’s information if desired…no such intermediate “glue” products seem to exist for newer display protocols, though I suspect those products will slowly appear on the market.
Hi LinuxDev,
Maybe you can help me…
I’ve returned back to the original motherboard just to check the difference in behavior between the original and our own carrier boards.
I found that get-edid wouldn’t like to work even on original carrier board…
It seems I do something wrong…
root@tegra-ubuntu:~# 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
[ 5758.627235] tegra-i2c 7000c700.i2c: --- register dump for debugging ----
[ 5758.634121] tegra-i2c 7000c700.i2c: I2C_CNFG - 0x22c00
[ 5758.640078] tegra-i2c 7000c700.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5758.649713] tegra-i2c 7000c700.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5758.655301] tegra-i2c 7000c700.i2c: I2C_FIFO_STATUS - 0x800040
[ 5758.661176] tegra-i2c 7000c700.i2c: I2C_INT_MASK - 0xed
[ 5758.666403] tegra-i2c 7000c700.i2c: I2C_INT_STATUS - 0x0
[ 5758.671843] tegra-i2c 7000c700.i2c: msg->len - 1
[ 5758.676558] tegra-i2c 7000c700.i2c: is_msg_write - 1
[ 5758.681569] tegra-i2c 7000c700.i2c: next_msg->len - 1
[ 5758.686675] tegra-i2c 7000c700.i2c: is_next_msg_write - 0
[ 5758.692074] tegra-i2c 7000c700.i2c: buf_remaining - 1
[ 5758.697157] tegra-i2c 7000c700.i2c: i2c transfer timed out, addr 0x0050, data 0x00
No EDID on bus 3
No EDID on bus 4
[ 5759.697341] tegra-i2c 7000d100.i2c: --- register dump for debugging ----
[ 5759.704206] tegra-i2c 7000d100.i2c: I2C_CNFG - 0x22c00
[ 5759.709757] tegra-i2c 7000d100.i2c: I2C_PACKET_TRANSFER_STATUS - 0x10001
[ 5759.716542] tegra-i2c 7000d100.i2c: I2C_FIFO_CONTROL - 0xe0
[ 5759.722403] tegra-i2c 7000d100.i2c: I2C_FIFO_STATUS - 0x800040
[ 5759.728423] tegra-i2c 7000d100.i2c: I2C_INT_MASK - 0xed
[ 5759.733694] tegra-i2c 7000d100.i2c: I2C_INT_STATUS - 0x0
[ 5759.739078] tegra-i2c 7000d100.i2c: msg->len - 1
[ 5759.743725] tegra-i2c 7000d100.i2c: is_msg_write - 1
[ 5759.748794] tegra-i2c 7000d100.i2c: next_msg->len - 1
[ 5759.753860] tegra-i2c 7000d100.i2c: is_next_msg_write - 0
[ 5759.759421] tegra-i2c 7000d100.i2c: buf_remaining - 1
[ 5759.764494] tegra-i2c 7000d100.i2c: i2c transfer timed out, addr 0x0050, data 0x00
No EDID on bus 5
No EDID on bus 6
1 potential busses found: 2
Bus 2 doesn't really have an EDID...
Couldn't find an accessible EDID on this computer.
I'm sorry nothing was successful. Maybe try some other arguments
if you played with them, or send an email to Matthew Kern <pyrophobicman@gmail.com>.
Partial Read... Try again
This tends to validate the idea that default video mode changed between the earlier and later L4T, and that you “got lucky” on earlier mode working with your monitor. There seem to be a lot of monitors with some quirk in their EDID output which needs a workaround. There is an email address to send data to to see about quirk workarounds, but you’ll likely be asked to first upgrade your read-edid package version to 3.0.2+.
See this post on libglx.so prior to any general use of apt-get to update everything:
https://devtalk.nvidia.com/default/topic/965192/jetson-tx1/jetpack-2-3-for-jetson-tx1-released-with-l4t-r24-2-ubuntu-16-04-64-bit-cuda-8-and-tensorrt/post/4976361/#4976361
The command in that above URL if libglx.so breaks is what’s important, so remember this one command:
sudo ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so /usr/lib/xorg/modules/extensions/libglx.so
For normal updates:
sudo apt update
sudo apt-get upgrade
# check L4T binaries still valid:
sha1sum -c /etc/nv_tegra_release
# If libglx.so breaks:
sudo ln -sf /usr/lib/aarch64-linux-gnu/tegra/libglx.so /usr/lib/xorg/modules/extensions/libglx.so
# check read-edid:
sudo dpkg --list | grep 'read-edid'
Once you have the latest read-edid, and if the error still shows, this email address becomes part of the read-edid failure message, and you can get information on fixing this particular monitor quirk (at least for the EDID acquisition, but there may still be issues to deal with on the Jetson end):
pyrophobicman@gmail.com
If you post the content of this file you can see what other EDID readers think (e.g., paste into http://www.edidreader.com):
cat /sys/kernel/debug/tegradc.1/edid
Unfortunately I cannot upgrade 23.2 because this way I will lose my working environment…
I’ve tried to look at the modern builds and found that I have to rewrite my DT, drivers and related code…
Now I have:
ubuntu@tegra-ubuntu:~$ sha1sum -c /etc/nv_tegra_release
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_image.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmedia.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libglx.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libscf.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvexif.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm_gpu.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_parser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_contentpipe.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvos.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtnr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvavp.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_video.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvodm_imager.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvjpeg.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtvmr.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvdc.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libtegrav4l2.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvapputil.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvcameratools.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvcam_imageencoder.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite_audio.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmm_utils.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvomxilclient.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvwinsys.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnveglstreamproducer.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvrm_graphics.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_2d_v2.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvtestresults.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvparser.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvddk_vic.so: OK
/usr/lib/arm-linux-gnueabihf/tegra/libnvmmlite.so: OK
/usr/lib/xorg/modules/drivers/nvidia_drv.so: OK
/usr/lib/xorg/modules/extensions/libglx.so: OK
ubuntu@tegra-ubuntu:~$ ls -l /usr/lib/xorg/modules/extensions/libglx.so
lrwxrwxrwx 1 root root 44 Oct 17 17:27 /usr/lib/xorg/modules/extensions/libglx.so -> /usr/lib/arm-linux-gnueabihf/tegra/libglx.so
ubuntu@tegra-ubuntu:~$ sudo dpkg --list | grep 'read-edid'
ii read-edid 3.0.1-2 armhf hardware information-gathering tool for VESA PnP monitors
ubuntu@tegra-ubuntu:~$ sudo cat /sys/kernel/debug/tegradc.1/edid
00 ff ff ff ff ff ff 00 10 ac a4 a0 4c 4e 31 37
20 19 01 03 80 35 1e 78 ee 7e 75 a7 55 52 9c 27
0f 50 54 a5 4b 00 71 4f 81 80 a9 c0 a9 40 d1 c0
01 01 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
45 00 0f 28 21 00 00 1e 00 00 00 ff 00 39 54 47
34 36 35 38 33 37 31 4e 4c 0a 00 00 00 fc 00 44
45 4c 4c 20 55 32 34 31 34 48 0a 20 00 00 00 fd
00 38 4c 1e 53 11 00 0a 20 20 20 20 20 20 01 8e
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 0f 28 21 00 00
1e 01 1d 80 18 71 1c 16 20 58 2c 25 00 0f 28 21
00 00 9e 01 1d 00 72 51 d0 1e 20 6e 28 55 00 0f
28 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10 10 3e 96
00 0f 28 21 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 37
If you go here you can download read-edid 3.0.2 source code (you should be able to compile this on the Jetson):
[url]http://www.polypux.org/projects/read-edid/[/url]
See if the same issue shows up with read-edid when using 3.0.2.
If you paste the raw EDID hex code from above here, you’ll see what a different parser says:
[url]http://www.edidreader.com/[/url]
The check sum is valid, and obviously i2c is able to read the data. So the issue is in how the data is parsed. Likely the default mode does not match a mode under the “Timing Bitmap” listing. Other modes may be possible if parsed differently, but you’ll need to test first with read-edid 3.0.2 before you can send email to get a quirk workaround at the email address listed in the read-edid error text.
Hello,
I just tried in R24.2
With
Section "Monitor"
Identifier "DSI-0"
Option "Ignore"
EndSection
in xorg.conf, it just ignore the LCD display. HDMI still works well.
any issue?
br
Chenjian
Hi Jachen!
I don’t know what should I do, to cry or to laugh… :)
You are right indeed, your system is debugged with HDMI display and certainly, if ignore it or better disconnect it works well.
But my target device has MIPI DSI display! :)
Could you advise?
Thank you,
Alex
Hello, Alex:
But if that section removed, LCD works well, and Ubuntu desktop appears in LCD.
br
ChenJian
Hello Jachen,
Certainly, without my display just only with hdmi your system works.
But again, my LCD has only MIPI DSI interface! Not HDMI. :(((
I cannot understand what are you trying to say?
Best regards,
Alex
Hello,
Calm down first.
Let me summarize your question and my tries.
Your question: You have a TX1 board with only DSI (LCD) and no HDMI, right?
I assumed that you’ve already brought up your LCD in kernel side. So you made some changes in xorg.conf.
In my hand, I have a Jetson TX1 board with a 1920x1200 LCD panel. And it can boot up Ubuntu desktop directly in LCD (WITHOUT HDMI)
As to the changes you’ve made:
Section "Monitor"
Identifier "DSI-0"
Option "Ignore"
EndSection
If this section is added in xorg.conf, it will ONLY show desktop in HDMI and nothing shown in DSI (LCD).
If this section is removed (in R24.2, default xorg.conf does not contain this section), Ubuntu desktop can display in LCD.
br
ChenJian
Hi Jachen,
I’m calm, please believe me. :) I just trying to find a solution… But sometimes it looks like a gambling because there is no any docs describes relation between hardware and software worlds of tx1… :(
Regarding my question. I’ve written " I even have no chance to disable it in xorg.conf…"
It means I actually need working LCD, but I cannot control it at all…
In R23.2 it was OK, in R24.2 not completely.
Any suggestions?
Best regards,
Alex
Hello, Alex:
Jetson document can be downloaded @ Jetson Download Center | NVIDIA Developer
If there’s any topic missed, please give out details. We will keep improving document.
As to LCD, it works in R24.2.
If you download Tegra210_Linux_R24.2.0_aarch64.tbz2/Tegra_Linux_Sample-Root-Filesystem_R24.2.0_aarch64.tbz2 and follow the steps in http://developer.download.nvidia.com/embedded/L4T/r24_Release_v2.0/BSP/l4t_quick_start_guide.txt?autho=1477389277_5faacf99cf0cac937ca016b448166a0b&file=l4t_quick_start_guide.txt, you can see jetson-tx1.conf is linked to p2371-2180-devkit.conf, which has only HDMI display. ‘p2371-2180.conf’ is the config which has both HDMI and LCD support, but that’s only for internal reference board with LCD module.
You can refer to that config and check why it fails in your side.
br
ChenJian