Radxa x2l issue with HDMI

I have several x2L boards and i have issue with hdmi connection to 10.1 inch screen and realtek controller rtd2660h.
The screen is black without signal till OS desktop starts, than i get signal and screen is working.
So i cannot access bios or any os setup. Same screen works with other computers without any problems.
Radxa x2l boards are also working with other monitors.

So i think there’s some compatibility issues between those two and screen doesn’t get signal to switch on in bios or terminal.

Does someone have a tip? I have tried different bios settings without any luck.

The X2L has 2 hdmi ports, have you tried change the hdmi ports? Or can you connect only one hdmi port at startup and leave the other port unattached for hdmi devices to display?
Or temporarily disconnect the SSD or other boot device and see if it can be displayed under UEFI shell?

I have tried all this combinations and also all other possible combination but in all cases display is not starting till desktop starts.
Only one combination works: connect working monitor than start board up, after i see UEFI shell then disconnect hdmi cable and connect 10 inch screen. In this case it’s till next reboot

This looks like a compatibility issue since other screen works fine. we are works fine with an 11.6" hdmi screen (1080p resolution).
Maybe another HDMI cable help?

day 1 with X2L

TL;DR …
(1) I think I have the same problem described by OP.
(2) I think I have identified actually TWO HDMI-related problems.

By way of background: I think this is my first-ever SBC.

Lots of careful reading around as many sources as I could get (including a lot of posts in this forum), before applying power first time. I haven’t yet installed the heat sink, but the wifi/bluetooth module and an Inland NVMe 256G SSD all in place, and no magic smoke has come out (always a good sign). Oh yeah, and the CMOS battery.

The desired monitor a 10.1" touch screen (aprotii, 1280x800) which I have confirmed to work (with an HDMI cable) on two different desktop boxes (one win10, one Linux Mint). Used known working cable to attach to the X2L. Monitor is powered via a wall wart (not trying to pull power thru the X2L USB-A port). Leaving the touch function unconnected for now, but I’ve confirmed it works on the Mint box.

Several attempts to boot: the behavior of the power LED (long red the first time, then steady white) seemed to be doing what it was supposed to, but nothing showed up on the screen.

Moved the assembly over to my desk, reassigned one of my daily driver’s monitors to the X2L, and tried again. Lo and behold, there’s the boot screen, and I can navigate around there more or less as shown in the instructions. Got me a fresh Debian 12 on a new thumb drive, and was able to fake my way thru installing the OS.

So all that is done, and it’s time to boot the OS for the first time. I’m still on the “regular” desktop monitor. It starts to clearly display a boot sequence (no screen shots, sorry), then the monitor flashes a complaint that the signal has gone out of spec (says I need to change settings to 1920 x 1080 60Hz), and the monitor times out and goes to sleep.

On a hunch, after having read this thread, I disassemble everything, move it back to my workbench, put it all together with the 10.1" aprotii monitor (same setup as before). The only thing different now is that I have an OS on the SSD.

Power up … it’s blank for a while, then … lo and behold, I get a login prompt! I can log in to the user account I established, fake my way around with cd and ls, then properly log out. This is repeatable. No display until the login prompt shows up.

SUMMARY:

(1) one monitor doesn’t work until the boot sequence is done.
(2) the other monitor works at the start, then the signal goes out of its range.

So, what words do I need to look up in order to understand this problem? Is there some kind of config file or BIOS setting that I am missing? Is there some magic about HDMI that maybe I should know?

thanks all

Thanks for your detail information
We have some possible directions for these 2 phenomena

  1. for 10.1’ touch screen, Is the screen not displaying because the monitor response time is longer than regular HDMI monitor?
  2. The model of your desktop monitor? And it is only the tips or impact on use? We checked on some 4K@60Hz monitor w/o problem

BTW, the Intel website say the J4125 SPEC support HDMI 4K@30Hz. https://ark.intel.com/content/www/cn/zh/ark/products/197305/intel-celeron-processor-j4125-4m-cache-up-to-2-70-ghz.html

Hi, thank you for your reply.

The response time of the 10.1" touch screen is claimed to be 3-5 ms.
and the refresh rate is said to be 60Hz

The desktop monitor is several years old, might be HP, definitely not 4k.
Desktop monitor settings: 1920x1080 - 60Hz.

I’m not sure how to interpret “only the tips or impact on use”

thanks

Here is an update:

10.1" touch screen

No change. Still no display until Linux is booted and ready to log in. Once Linux is running, the display runs fine. GNOME tells me that the display resolution is 1280 x 800, and the refresh rate is 54.22 Hz. So we know the X2L and the monitor can work together. I suspect that is a problem of display settings during the startup sequence (which includes the Radxa logo and the GRUB screen).

On a hunch, I tried hitting F7 upon power up. I’m assuming that is successful in causing the X2L to go into the “please select boot device screen” but the monitor sits there patiently without displaying anything. If I had not already seen before what really happens with F7, I would have assumed it had crashed.

So the mis-match is before Linux starts up and takes control of resolution and refresh rate. Maybe the Radxa boot firmware?

Desktop monitor

Now this is very interesting. I had a few HDMI cables lying around and discovered that it makes a difference! The cables that did not function properly were 72" and 18" in length. These did what was already described - would show the first part of the boot sequence /until/ Linux took over, and then the monitor would advise me of a settings mismatch and go blank.

A third cable (of course it would be 42", why didn’t I think of that) worked, all the way from the start, without choking when control of the display is transferred to the OS.

I’m assuming there are some differences between cables. Of note, the longest (72") was also the thickest (and stiffest). The shortest (18") was also the thinnest. And the 42" cable was intermediate in thickness. That blows my hunch that not all conductors are continuous from one end to the other.

I’m not going to cut into the cables to explore what pins are actually connected, or what their shielding looks like. Maybe I’ll go down a rabbit hole to learn about HDMI cables, though if anyone here has some relevant experience, I’d be interested.


So, problem is not exactly solved, but at least I can operate the computer.

Glad there is a way to get working.
For the touch screen, The BIOS stage display is controlled by bios/vbios, and there are claims on the google that it may have something to do with the CSM being Disable.
For the HDMI cable, the number of groups of hdmi cables, the version is 1.4 or 2.0, and the quality of the gold plating of the hdmi connectors, may cause abnormalities in the display.

I tested the claim that the disabled state of CSM might be the source of the blanked display during the boot process.

In the UEFI screen, I ENABLED the CSM. This caused no problems. The NVME 256G drive is still partitioned with GPT. My vanilla Debian 12 (with GNOME for now) booted just fine.

Of course, doing the above interaction with the UEFI screen required me to attach the “standard” desktop monitor. After shutdown, reconnection to the little 10" touch screen, and power-up, the behavior is unchanged.

On a hunch, I tried connecting monitor to HDMI-2, but it does exactly the same thing.

Summary: For my 10.1" touch screen (1280x800), display is blank until some specific point along the boot process (dunno if it’s GRUB or the Linux kernel), then works just fine. For my ordinary desktop monitor, display works properly from the first green Radxa logo.

I infer that this problem originates in the UEFI firmware. If the firmware offers any configurability of display, I haven’t found it in any of the interactive screens. I suppose there is some display resolution hard-coded in the firmware that is incompatible with the little monitor.

I’m totally agree that there must be hard-coded resolution in the bios. I have the same problem with my 10 inch screen 1024×768