Dell Latitude laptop + WD19 dock - HDMI connected monitor asleep

Hi all,

I’ve been running Manjaro for not long, so it might be a case of pointing me to the proper Arch wiki page :slight_smile:

I have a Dell Latitude 5510 laptop connected to a WD19 dock (the base USB-C version, not the S nor the thunderbolt one) and the monitor connected to the HDMI port of the latter stays black, despite being registered properly.

  • It all works on the Windows partition. It also works in Manjaro with the HDMI cable in the laptop port, so it has to be an issue with the dock.
  • BIOS and dock firmware are up-to-date :
# fwupdmgr get-updates
[...]
Devices with the latest available firmware version:
[...]
 • WD19
 • PC SN530 NVMe WDC 512GB
 • System Firmware

(confirmed in the windows partition)

  • And the second monitor is detected:
# xrandr --current
Screen 0: minimum 320 x 200, current 1921 x 2160, maximum 16384 x 16384
eDP-1 connected primary 1920x1080+1+1080 (normal left inverted right x axis y axis) 344mm x 194mm
   [... Laptop monitor ...]
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
DP-1-1 disconnected (normal left inverted right x axis y axis)
DP-1-2 disconnected (normal left inverted right x axis y axis)
DP-1-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 476mm x 268mm
   1920x1080     60.00*+  50.00    59.94  
   1680x1050     59.88  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.90  
   1280x800      59.91  
   1280x720      60.00    50.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       60.00    59.94  
   720x400       70.08 

It properly shows in display settings and get my cursor “through it”.

  • I tried fiddling with the relevant BIOS options with no success. (I can’t put my hands back on a post suggesting that an option to “always allow Dell dock” or something like that needed to be deactivated, but couldn’t find such option.)

Any clue?

There is a similar issue on the forum, that got closed with no solution.

Hello,

See if this discussion might give you some hints:
https://bbs.archlinux.org/viewtopic.php?id=252985

Hi,

Thanks for the answer! Yes, I saw that thread earlier, however, it is not of much help, sadly. I don’t own the thunderbolt version of the dock, so most of the troubleshooting steps he does won’t work, and I merely have an Intel iGPU, so forget about the bumblebee workaround (which he abandoned in the end, anyway).

Could it be that the HDMI signal is somehow recognised as a DisplayPort one? The USB-C cable indeed is a DP one, and it appears to not be an issue for others though…

# xrandr --verbose
[...]
DP-1-3 connected 1920x1080+0+0 (0x99) normal (normal left inverted right x axis y axis) 476mm x 268mm
        Identifier: 0x83e
        Timestamp:  1847369
        Subpixel:   unknown
        Gamma:      1.0:1.0:1.0
        Brightness: 1.0
        Clones:    
        CRTC:       1
        CRTCs:      0 1 2
        Transform:  1.000000 0.000000 0.000000
                    0.000000 1.000000 0.000000
                    0.000000 0.000000 1.000000
                   filter: 
        EDID: 
                00ffffffffffff00220e2e3401010101
                141d010380301b782a9665a35b4fa327
                125054a10800d1c081c0a9c0b3009500
                810081800101023a801871382d40582c
                4500dc0c1100001e000000fd00323c1e
                5011000a202020202020000000fc0048
                50203232770a202020202020000000ff
                00434e43393230305651510a2020019e
                02031ab149001f041303120211016803
                0c001000002200e2002b023a80187138
                2d40582c4500dc0c1100001e023a80d0
                72382d40102c4580dc0c1100001e0000
                00000000000000000000000000000000
                00000000000000000000000000000000
                00000000000000000000000000000000
                0000000000000000000000000000004d
        max bpc: 12 
                range: (6, 12)
        HDCP Content Type: HDCP Type0 
                supported: HDCP Type0, HDCP Type1
        Content Protection: Undesired 
                supported: Undesired, Desired, Enabled
        Broadcast RGB: Automatic 
                supported: Automatic, Full, Limited 16:235
        audio: auto 
                supported: force-dvi, off, auto, on
        link-status: Good 
                supported: Good, Bad
        CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 
                0 1 
        CONNECTOR_ID: 129 
                supported: 129
        non-desktop: 0 
                range: (0, 1)
  1920x1080 (0x99) 148.500MHz +HSync +VSync *current +preferred
        h: width  1920 start 2008 end 2052 total 2200 skew    0 clock  67.50KHz
        v: height 1080 start 1084 end 1089 total 1125           clock  60.00Hz
[etc...]

Hi,

A little update (and bump :grimacing:).

I have tried with a Sitecom CN-389 USB-C hub and got the same result : the monitor is detected properly, and can be activated, itself detects something is connected, but doesn’t display anything, i.e. it stays idle. Edit : tried with a simple usb-c to hdmi adapter and got the same result.

As a reminder, it works properly on a windows partition (with both hubs) and when I plug the HDMI cable directly into the laptop, so the hardware and firmware are not at fault.

xrandr and inxi outputs unchanged. I just note, once again, that the monitor is listed as a DP output, as far as I understand it, while it is connected as HDMI-2 when directly plug :

Monitors: 2
 0: +*eDP-1 1920/344x1080/194+1+1080  eDP-1
 1: +DP-1-8 1920/476x1080/268+0+0  DP-1-8

I may speak nonsense, but could it be that X sends “DP formatted data” instead of “HDMI data” to the monitor and that would be the cause of the issue? If so, is there a way to fiddle with xrandr and change that ?

Note : I was persuaded DisplayLink driver wasn’t needed, since my devices are not listed on their site as containing a relevant chip, so didn’t try until now. I gave it a go. It required building the git build of edvi. Either way, xrandr --listproviders only lists one provider : modesetting, so it doesn’t seem to resolve my issue.