Arduino UNO Q – No video signal via USB-C DisplayPort Alt Mode due to incorrect preferred display mode

Official Hardware UNO Family UNO Q
1

Mod edit:

Please see the linked topic in German if you wish to help with this topic.

Thank you

Arduino UNO Q – No video signal via USB-C DisplayPort Alt Mode due to incorrect preferred display mode

German version: This is the English translation of my original German post. If needed, please refer to the German post for the original wording and troubleshooting context.

German Version Link: Arduino UNO Q – Kein Videosignal über USB-C DisplayPort Alt Mode wegen falschem bevorzugtem Displaymodus

Summary

I had an issue with my Arduino UNO Q: the board booted correctly into Debian and was fully reachable via SSH/network, but there was no video output over USB-C DisplayPort Alt Mode.

The monitor only showed: 

No Signal

and then went into standby mode.

After further troubleshooting, it turned out that the display output itself was working. The actual problem was the automatically selected preferred display mode reported by the monitor: 

1024x600 @ 59.85 Hz

Linux detected this mode correctly and also set it as the active mode, but in my USB-C hub / HDMI setup it did not produce a usable video signal.

As soon as I manually forced the following mode: 

1920x1080 @ 60 Hz

the image appeared immediately.

Hardware / Setup

Hardware used:

  • Board: Arduino UNO Q
  • Operating system: official Arduino Debian image
  • Kernel:
Linux dashboard 7.0.0-g122c2c22d838

Display connection:

Arduino UNO Q
→ USB-C DisplayPort Alt Mode
→ USB-C hub with HDMI output
→ HDMI monitor

Tested hardware:

  • Anker 332 USB-C Hub 5-in-1
  • another USB-C hub with HDMI output
  • HAMTYSAN 10.1" HDMI monitor with 1024x600 resolution
  • regular HDMI PC monitor
  • several HDMI cables

Both monitors work correctly when connected to a normal Windows PC.

Original symptoms

The UNO Q booted normally. The following things worked:

  • Debian Linux
  • SSH
  • Wi-Fi
  • USB
  • Xorg
  • LightDM
  • XFCE

However, the monitor always showed: 

No Signal

So the system itself was fully reachable, but there was no visible local display output.

Initial diagnosis

At first, the graphics diagnosis looked as if everything had been initialized correctly.

modetest and xrandr showed: 

DP-1 connected
link-status: Good
DPMS: On
EDID detected

The preferred detected mode was: 

1024x600 @ 59.85 Hz

xrandr showed something like this: 

Screen 0: minimum 320 x 200, current 1024 x 600, maximum 16383 x 16383
DP-1 connected primary 1024x600+0+0
   1024x600      59.85*+
   1920x1080     60.00
   1280x720      60.00
   ...

From Linux's point of view, the monitor was connected, the EDID was read, and an active display mode was set. Nevertheless, the screen stayed black or showed “No Signal”.

Key finding

Via SSH, I then ran the following command: 

sudo env DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/:0 \
xrandr --output DP-1 --mode 1920x1080 --rate 60

After that, the image appeared immediately.

This confirmed that:

  • The USB-C / DisplayPort Alt Mode output works in principle.
  • The HDMI hub is able to output a video signal.
  • The monitor can receive a valid signal.
  • The UNO Q display output is very likely not defective.

The actual problem seems to be the automatically selected preferred mode: 

1024x600 @ 59.85 Hz

This mode was detected by Linux as valid and activated, but through my USB-C DisplayPort Alt Mode to HDMI chain it did not result in a visible signal.

The standard mode: 

1920x1080 @ 60 Hz

works reliably.

Xauthority issue when using xrandr via SSH

At first, I tried: 

sudo DISPLAY=:0 XAUTHORITY=/var/lib/lightdm/.Xauthority xrandr

This worked in one state, but later failed with: 

Authorization required, but no authorization protocol specified
Can't open display :0

I found the correct Xauthority file by checking the running Xorg process: 

ps aux | grep -E "Xorg|X " | grep -v grep

Output:

/usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch

Therefore, the working command was: 

sudo env DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/:0 \
xrandr --output DP-1 --mode 1920x1080 --rate 60

Persistent workaround

To avoid having to run the command manually via SSH after every boot, I created a small script: 

sudo nano /usr/local/bin/fix-display-mode.sh

Content:

#!/bin/sh

sleep 4

env DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/:0 \
/usr/bin/xrandr --output DP-1 --mode 1920x1080 --rate 60

exit 0

Then I made it executable:

sudo chmod +x /usr/local/bin/fix-display-mode.sh

After that, I created a systemd service: 

sudo nano /etc/systemd/system/fix-display-mode.service

Content:

[Unit]
Description=Force working display mode on DP-1
After=lightdm.service
Wants=lightdm.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/fix-display-mode.sh
RemainAfterExit=yes

[Install]
WantedBy=graphical.target

Enabled and started the service:

sudo systemctl daemon-reload
sudo systemctl enable fix-display-mode.service
sudo systemctl start fix-display-mode.service

Status check:

systemctl status fix-display-mode.service

The service runs successfully:

Active: active (exited)
ExecStart=/usr/local/bin/fix-display-mode.sh (code=exited, status=0/SUCCESS)

After a reboot, the image now appears automatically.

Scaling / DPI adjustment

After forcing 1920x1080, the image was visible, but the desktop interface was too small. Therefore, I set the XFCE DPI value to 144, which is approximately equivalent to 1.5x scaling.

First, I had to install dbus-x11: 

sudo apt install dbus-x11

Then I set the DPI value:

sudo -u arduino DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/:0 \
xfconf-query -c xsettings -p /Xft/DPI -n -t int -s 144

Check:

sudo -u arduino DISPLAY=:0 XAUTHORITY=/var/run/lightdm/root/:0 \
xfconf-query -c xsettings -p /Xft/DPI

Output:

144

Conclusion

The original problem looked like a complete failure of the video output, because the monitor only showed “No Signal”.

In reality, the display path itself was working. The problem was the automatically selected preferred EDID mode: 

1024x600 @ 59.85 Hz

This mode was detected by Linux and set as active, but through my USB-C DisplayPort Alt Mode to HDMI setup it did not produce a usable signal.

Forcing: 

1920x1080 @ 60 Hz

fixes the problem.

Possible causes:

  • EDID / preferred mode issue
  • Timing incompatibility with 1024x600 @ 59.85 Hz
  • Problem in the USB-C DisplayPort Alt Mode to HDMI conversion chain
  • Kernel / DRM / bridge driver behavior during automatic mode selection

The current workaround is to automatically force the working mode 1920x1080 @ 60 Hz via xrandr after LightDM has started.

I hope this helps others with a similar issue.

If anyone finds a cleaner or more permanent solution, feel free to add it to this topic. Otherwise, the workaround described above may be useful for anyone running into the same problem.

1 Like
Uno Q suddenly blacks out after plugout and plugin