Hello everyone, I am working on an AR project and need to use the LS055R1SX04 LCD display 1440x2560. The kernel naturally disables a display of this setting in hdmi2.0.c. I have no idea how to modify the kernel to allow this setting and set up my jetson nano B01 SUB to use this display. Can someone teach me how to modify the kernel for this task, and can it be done on the jetson board or does it require a host machine and then a flash process?
If the mode is disabled in the kernel then it means not supported.
VR display for jetson nano - #8, are you sure, bc in this post it is achievable. I am just trying to comment out the resolution restrictions in the kernel to get the display to work. 1440x2560 HDMI display not working. You said here in this post it would work as well.
Some explanation might be useful here, YMMV…
HDMI, DisplayPort, and digital DVI provide information about the monitor to the GPU (it is the EDID data). This is what makes monitors “plug-n-play”. The drivers will use that information to ask the monitor what modes it has available, and from that the GPU driver will select something compatible. If nothing compatible is found, then there may be default modes or fallback modes.
The Jetson’s GPU is integrated directly to the memory controller (it is an iGPU), whereas most video cards go through the PCI bus and are discrete (a dGPU). The drivers for the dGPU are more flexible and can create many custom modes so long as it is within specs of the GPU’s capabilities. The iGPU does not have that ability, it can only use modes available from EDID listings, and no custom modes.
Sometimes in the forums you will see notes of people changing modes in the kernel. What they’re really doing is changing the default fallback mode. The reason this is useful is that some people have displays (such as LVDS) which do not report EDID, and yet they know it has a mode that the driver supports. They are not creating a new mode, they are instead picking an existing mode other than default for the fallback case of no EDID. In that case the display works because the default mode is what the end user wants.
In the case of a VR display, if it reports EDID over HDMI or DisplayPort, and if there is no valid mode, then changing the default mode won’t help.
If you want the driver itself to tell you what it thinks of each EDID mode, then you can edit the file “/etc/X11/xorg.conf”. Find the part with Section "Device". Add the line `Option “ModeDebug” like this:
Section "Device"
Option "ModeDebug"
...just insert that line and leave the rest as is...
Now you can reboot to restart the display with the verbose mode debug. Find the correct log file:
ls -ltr /var/log/Xorg.*.log | tail -n 1
(probably Xorg.0.log, but with VR it might differ; also check if there is a second log file *with the same timestamp via “ls -ltr /var/log/Xorg.*.log | tail -n 2” since there might be two displays now)
Inside that log you will find information about the “ModePool”. After EDID is read there will be a brief paragraph about every mode the VR headset reported, and whether that mode is considered valid or invalid. After all modes have been enumerated in the log there will be a summary section about “ModePool” which states which modes were accepted. It sounds like none will be listed.
However, if you use the headset on a Linux system where it works, then you could view the modes available while it runs by using the command xrandr (just make sure you are looking at the modes of the headset and not another monitor). You could compare those modes to the log file; there is a very tiny chance that one of the modes are not listed in the log, and perhaps a new default fallback mode could be used to select that mode. Odds of this are not good.
I will follow your instructions and get back to you with the xorg.log data, but you are absolutely sure that the kernel hdmi.2.c file doesn’t filter out the resolution of my display in the lines
320 if (mode->xres > 4096 || mode->yres > 2160)
321 return false;
This doesn’t look like a fallback mode to me, just a restriction that disables my resolution of my display. Other posts that I linked have said for my display to comment out those lines to enable my display. Does this Clarify anything, or is that really just a fallback mode and I have to check the logs?
The log will tell you if it was filtered out. The driver itself is a “cut down” driver for the iGPU, and the GPU itself probably has some die differences (I’m guessing it resembles the laptop version) and so even if it were connected directly to the PCIe bus with a dGPU driver it probably is still a narrower set of supported output specs. I can’t guarantee the file doesn’t limit it, but NVIDIA did put in every mode it thinks the GPU is capable of. Whether there is a way to create a custom mode I don’t know, but I’m doubtful. The fallback mode for monitors which don’t support EDID don’t use a custom mode, but maybe you’d get lucky if you edited and tried different things (I’m doubtful).
Xorg.0.log (16.1 KB)
here is the log for the display. What can you discern from this?
Your monitor is either failing or does not have correct wiring (which can be at the Jetson end).
Long ago monitors could not “self describe”. These were the days of VGA, and one either depended on support of a default mode the monitor could handle, or else a “driver”. However, the driver was just a database of the monitor’s capabilities and was not itself a driver; this data was given to the GPU driver. Then the plug-n-play revolution started, and for monitors, the first plug-n-play was the digital DVI (analog DVI was nothing more than VGA on a different connector). HDMI and DisplayPort have EDID data on the monitor itself, and the GPU can query the monitor (similar for digital DVI).
There is a wire on HDMI which is the “DDC” wire. There is a 3.3V i2c data bus on this wire, and when the GPU provides power to the monitor’s i2c hardware (remember that the monitor must have the ability to be queried even when turned off), the EDID data (actually EDID2 these days) is sent over the DDC wire as an i2c signal.
That EDID trigger would be what one might call the hot plug detect. Either when the monitor is plugged in, or if already plugged in, when the computer boots. Your monitor is not replying.
Is this an HDMI or DisplayPort device? If so, then it should be ok.
If this monitor has the ability to send EDID over the DDC wire, then your carrier board might have the wrong device tree. The power for the i2c circuitry is supplied by the HDMI wire to the monitor, and if the device tree does not bring up that power rail, then there will be no EDID. If the i2c circuitry is itself not routed correctly to the module (remember there are several optional lane routings and the device tree sets those up), then even if there is power to the monitor, then the actual i2c signal won’t do anything. Lastly, if the hot plug detect fails, then it means that even if power is available and even if the i2c is set up correctly, then the HDMI connector won’t bother to bring up power for the DDC’s i2c. Or if there is an adapter which does not correctly translate the DDC wire, then the EDID will again be missing.
You might want to monitor “dmesg --follow”, and then unplug and replug the monitor. Is there a log note about monitor detection? Compare the note of a working ordinary monitor. Does the other monitor work? If nothing is shown in logs, then hot plug detect is missing (which is another pin on the HDMI connector which the device tree can modify). If something does show up, then comparing what shows up for that and some ordinary HDMI monitor can narrow it down.
Bottom line, the monitor is not communicating with the GPU driver.
It is an HDMI device, and in the logs it was detected - it just said it didn’t have or couldn’t detect an edid. The detected device is the LS060R1SX01, that is my display. I will try dmesg —follow. I will also try some XRANDR commands. However, the log said it was defaulting to a fallback mode, which you said earlier was what my kernel was specifying. Does this mean that I now need to adjust the kernel to no disqualify its resolution? This nano works fine with other displays.
Something is preventing the EDID query. Since the display was detected we have to assume that hot plug works and EDID would have been found if the rest of the chain for EDID worked. You shouldn’t try to override any modes until EDID works and then only if there might be a default mode which is compatible and the current fallback is not compatible.
You say this is an LCD is HDMI. Do you have another “ordinary” HDMI monitor you can try which works? If you do, and you monitor “dmesg --follow” as you plug in the “ordinary” monitor, does this (or the Xorg logs) show that EDID functions? If any HDMI monitor has working EDID, then the failure in the EDID chain is not in the Jetson itself. It is quite possible that the monitor does not respond to EDID queries on the DDC wire. If other monitors also fail to get the EDID information, then it means that perhaps the device tree is incorrect for that particular carrier board (note that if the carrier board is not the developer’s kit carrier board, then likely it needs firmware changes in the form of the device tree being edited to tell the module about HDMI layout).
Actually, I just noticed you said the Nano works with other displays, so it is the LCD itself which is not replying. Do you have any detailed documents on this device? Sometimes such a device does not follow the correct procedure of allowing the GPU to power the i2c circuitry of the display, in which case you might need to change the sequence of powering on and/or connecting the display (this is not a kernel issue, but if EDID cannot be resolved, then it is possible that if you have a list of modes and you find one that should work, then the kernel can be told to use that as the fallback mode when EDID fails).
https://cdn.compacttool.ru/downloads/Sharp%20LS055R1SX04.pdf. These are the specs on the DISPLAY, but upon further research I realized the HDMI DRIVER BOARD could be the problem. It came with my display off Amazon, and is the MIPI LCD Controller Board VS-CXMIPI-V1. I checked and rechecked the Xorg logs and edid is not found. Could that driver board be the problem? I don’t know where to find specs on the driver board, but maybe you have insight? I’m wondering at this point if it’s just time to try what people did in the other posts and recompile the kernel to remove the resolution restrictions, because they had the same set up as me.
When adding an HDMI board it would have to be programmed to respond to queries with the timings and values of the display. It is highly likely that this is the problem. I’m guessing there is either some way to program that driver board, or else an empty ROM slot which you could drop a ROM into which was programmed via something like an EEPROM programmer. Everything depends on being able to store the monitor specs into that board.
What you are seeing are not resolution restrictions. You’re seeing what happens when the GPU driver is completely in the dark about what resolution is available. Maybe there are many supported modes?
“In the old days” (before EDID) there was a small set of “standard” modes available, and all monitors had at least one of those modes it was compatible with. One could tell the driver to try each mode until one was found which worked. Likely your LCD uses only “non-standard” modes (relative to 40 years ago), but maybe one of those modes does work…only it would be a terrible choice, e.g., maybe it works with 640x480 on some tiny spot in the middle of the screen. If you knew a compatible mode, then you could set the driver (via kernel edit) to use one of those modes as a fallback (EDID would still be missing, but you’d rig the game to “get lucky” with the fallback mode). The driver for the iGPU on the Jetson will not allow you to use xrandr to run modes which are not in the EDID, and you don’t have EDID, and so you must either (A) add EDID via the HDMI board, or (B) set a fallback mode.
It is so much better to just program the HDMI driver board. You really need the manual and/or specs regarding programming that board, and in turn, you need the specs used in that programming which apply to your monitor (how can you program it if you don’t know what settings to use? how can you set a default fallback mode if you don’t know which modes work?).
Incidentally, setting a mode has a number of timings associated with it. It isn’t a simple case of saying you want 1440x2560. You’d also need pixel clock values and color depth. Color depth is easy, but pixel clocks are something the specs of the monitor are needed for (in detail).
I will look into the specs on the driver board, but I will need a complete guide on how to program the driver board because I have no idea how to do that. Also, an added detail is that while the display is connected to my nano, it stays dark but the backlight blinks every few seconds as if it is trying to work. I don’t know if that is relevant, but I thought I’d mention it. Last concern is that even if I do program the HDMI board, the resolution is still supposed to be filtered out by the kernel but maybe I don’t understand that correctly. Anyways, how would I program the hdmi board?
The flash instructions will be very specific to that driver board and won’t in any way care about the Jetson. There is a tool you can use once you have an EDID you are proposing to flash into that board:
https://www.edidreader.com/
That tool will turn the EDID into plain English and is very useful when validating or comparing an EDID.
I don’t think the backlight is relevant. Maybe it indicates some other issue, e.g., power, but I don’t know.
If the EDID is correctly flashed, then when you plug that board into the Jetson the logs should show a list of every mode the EDID reports, along with what the driver thinks about the mode (this is because you have “ModeDebug”). Whether or not one of those modes are valid we don’t know yet. If none of those modes are accepted by the driver, then it won’t matter what edit you make in the driver, it simply won’t work in those modes. If this does work, and if a mode is available, then one of those modes should occur automatically. If multiple modes show as valid, and if you want a different (valid) mode, then xrandr would allow you to select the other valid mode.
That HDMI board will have its own documentation which will be very specific to it. There is no telling what the instructions are without the documentation because every one of those boards will essentially have custom instructions. Maybe it will even involve adding a particular ROM to the board, in which case you’d have to use an external chip programmer; or perhaps there is an EEPROM already installed and you would be allowed to erase and reprogram what is there (and currently there is no EDID so we don’t know).
Keep in mind that you could use a different HDMI board if this one is not providing the information needed.