Dell XPS 13 with USB C dock connection works 50:50

I have a Dell XPS 13 (9380) running Fedora 34 with a Dell Dock WD15.

On my docking station I have a 27" monitor connected via Displayport, a keyboard, a mouse and networking. I have this setup at home and at work.

I’ve had this combination since june 2019 and across multiple Linux OS’es (Fedora and Ubuntu) I’ve had this issue:

Usually when I connect my computer to the docking station it only detect power and not the screen or keyboard. But if i plug into another port it works. It is like this around 45% of the times. 50% of the time it works in first try and in 5% of the times it is really hard to get it to work. Maybe I have to try all ports or restart my laptop before it works. It is the same issue both at my home and work setup.

Both dock and laptop has the latest firmware offered via

I would like help with how I can debug this issue. I am not sure if it is a configuration issue or a bug in somewhere. It is not hard to trigger, but as I wrote I cannot know for sure if I’m going to have a issue when I connect my laptop.

My old ThinkPad with a docking station never had reliability issues like this, but it didn’t run with USB-C either.

Anybody who can help me proceed so that I can try to fix this issue?

Thanks in advance!

If the OS is already running (suspended) when it is connected to the dock then something is needed to trigger the port reconfig so the drivers are loaded for the dock.

I would suspect that the optimum solution would be to either turn the laptop off or hibernate (as compared to suspend) before connecting it to the docking station. That way when restarted it will automatically look at attached devices during boot and configure them properly.

I realize there is a speed difference in start-up vs resume-from-suspend, but do you not use more time in recovery than would be lost to start-up?

Another possibility would be to have the machine active (already resumed) before docking it so the active OS sees the dock when attached and can reconfigure devices immediately. I don’t know if I would accept the risk in connecting two already active electronic devices though.

I almost always have my laptop on standby and turn it on before connecting to the docking station.

It is faster to recover than it is to close all of my stuff and open it again.

This thing about reconfiguration sounds right, but I’m not sure how to debug it. Any hints?

1 Like


Do not use standby/suspend while detached. Instead sacrifice the few seconds extra for a normal startup that gives you the docking station already configured.

The machine has to SEE the new device at the time it is attached to trigger udev to do the new configuration. Thus, if it is in suspend when attached it does not receive the trigger that starts the config for the newly attached docking station. Starting up from suspend restarts the system EXACTLY as it was when suspended. It does not search for new devices since suspend is a standby/sleep/powersave condition that is not used for attaching new devices.

It appears you have a choice.

  1. Use suspend and do not configure the docking station
  2. do not use suspend and the docking station will be configured at start up after it is attached.

Maybe someone else can tell you how to manually trigger the machine to reconfigure for the newly attached docking station but I don’t even have a docking station to play with.

Booting is not fast. It usually takes around 31s. Resume is much faster than that, and that is even without considering having to reopen whatever I was doing.

I always disconnect my dock before my computer go to standby, and I also wake the computer before connecting the docking station. But this does not really help docking station discovery.

Is the answer really that standby just is so broken that it cannot work? No way to manually triggering?

Having someone that cannot even wait 30 seconds for a machine to boot just floors me.

Most of that time can be used in arranging things on your desk, getting seated, and generally preparing for whatever is next.

I would guess that waking the laptop up, plugging it into the docking station, then doing all I stated above takes considerably more than 30 seconds. Walking up to the desk, plugging into the docking station, then booting, even before sitting down and prepping your desk would not take much more time. I am sure a simple time motion study will show where you can avoid the delay by having the boot running at the same time as doing something else.

Yes, if I sat down, turned on the machine, and started work on it instantly the 30 second delay might be noticeable. But not so much if I have a few other tasks to prepare.

I cannot answer the last part since I do not use dell and do not have a docking station.

Let me get back on topic. I did not intended to start a discussion of sleep vs reboot and I think I’ve taken that discussion too far off topic.

What I really seek is means to debug this.

It works, but only sometimes. In order to know why it only works sometimes I need some help to debug it. There is so much I do not know about inner workings of Linux and I really hoped someone could point me in the right direction so that I could try to debug it myself.

1 Like

Did you sort it out?

If not, my first suggestion would be to look in the journal (see journalctl) and compare the messages from a successful connection with an unsuccessful one. There might be a clue there.

Maybe you already did that?

1 Like

No, not yet. Still an open issue. I’ve even tried to not use sleep as suggested but that does not help. The issue is not related to sleep at all. It can happen from a clean boot when connecting/disconnecting the docking station.

I’ve tried a bit, but there is just so much not sure what to look out for. I’ll try to do that some more.

I’ve also tried rawhide kernel which mostly made it worse.

I did manage to capture some kernel logs one time where it was persistently bad, but I managed to a picture without hard reset. Thus pretty direct time-frame. I see several kernel errors happening, but not sure why or if it is a bug in the kernel or a configuration error or a hardware fault.

Also FYI: I’ve updated to Fedora 35