Go Back   DisplayLink Forum > DisplayLink Graphics Technology > Linux and Open Source

Reply
 
Thread Tools Search this Thread Display Modes
Old 10-30-2017, 10:09 AM   #11
Wunsz
Junior Member
 
Join Date: Oct 2017
Posts: 11
Default

Quote:
Originally Posted by k001 View Post
This seems like a device wants to sleep, and the kernel can't prevent it and is losing it.
That actually gave me an idea. I've attached the dell dock to USB described as 2-2.1 and did:

Code:
echo on | sudo tee /sys/bus/usb/devices/2-2.1/power/level > /dev/null
echo 2 | sudo tee /sys/bus/usb/devices/2-2.1/power/autosuspend > /dev/null
essentially disabling autosuspend on this bus. Will test how it works, but you may want to try it too.

Edit: For XPS 9560 USB-C Port it will be:
Code:
echo on | sudo tee /sys/bus/usb/devices/4-1.1/power/level > /dev/null
echo 2 | sudo tee /sys/bus/usb/devices/4-1.1/power/autosuspend > /dev/null

Last edited by Wunsz; 10-30-2017 at 10:18 AM.
Wunsz is offline   Reply With Quote
Old 10-30-2017, 06:36 PM   #12
k001
Junior Member
 
Join Date: Oct 2017
Posts: 17
Default

Quote:
Originally Posted by Wunsz View Post
That actually gave me an idea <...>
essentially disabling autosuspend on this bus. Will test how it works, but you may want to try it too.
I tried this as well some time ago, and tried again today. Doesn't change anything

The other thing I tried is powering the laptop from the usual power supply (I guess if you plug it it, power over USB-C is disabled, but I can't check that).

Yet another thing to try was not setting external display to be primary (i.e. keep the internal panel, eDP1, as primary).

Unfortunately, none of the above helps, I am still getting disconnects. My gut feeling it is bad hardware (either the Thunderbolt controller, or the displayport hardware in the dock, or maybe even both).

Continuing my research, I found that some people say changing the Wi-Fi board from Atheros or Broadcom to Intel makes the Thunderbolt controller work better. As my Atheros 10k wifi is noticeably bad (bad performance, occasional lockups and kernel oopses) I am going to change it anyway and will report back if it helps (I doubt it, but worth a shot).

The next thing I found is, there's so called "USB-C alternate mode" that (among the other things) enables external displays to be connected through USB-C. It looks like, Dell XPS 13 9360 has two DisplayPorts routed to USB-C. I have yet to figure out what dock is required for that (Dell TB-16 I guess) and whether or not it works for Linux.
k001 is offline   Reply With Quote
Old 11-03-2017, 06:37 AM   #13
Wunsz
Junior Member
 
Join Date: Oct 2017
Posts: 11
Default

A new info,
I have noticed that the disconnects happens much less frequently when charging an empty battery (on USB-C) or discharing the laptop (USB3 without adapter).

Any ideas?
Wunsz is offline   Reply With Quote
Old 11-07-2017, 10:18 PM   #14
k001
Junior Member
 
Join Date: Oct 2017
Posts: 17
Default

Quote:
Originally Posted by Wunsz View Post
A new info,
I have noticed that the disconnects happens much less frequently when charging an empty battery (on USB-C) or discharing the laptop (USB3 without adapter).
I tried it, haven't noticed any differences. Ended up sending the D6000 back, and will make sure to never buy anything with DisplayLink logo again. What I regret is the time I spent trying to make this non-working thing actually work. I mean, in theory (let's compress video and send it over USB for the dock to decompress and show) it sounds OK, in practice, it does not work, and even when it is (maybe in Windows?), it uses lots of CPU, which is not OK.

My research shows that the Thunderbolt (aka USB-C) port in Dell XPS 13 9360 has two displayport outputs wired (using USB-C alternate mode), and with a proper dock/adapter you'll have two working display outputs. So, I have now ordered Dell TB16 dock; Linux reviews are pretty positive (there was a bug making its Ethernet working at full speed, 1 gbps, but it seems it is fixed in latest kernels).
k001 is offline   Reply With Quote
Old 01-11-2018, 01:29 PM   #15
edclement
Junior Member
 
Join Date: Jan 2018
Posts: 11
Default working solution

After a few days of struggling, I managed to find a solution on Ubuntu 17.10. Hope this works for everyone having problems with the D6000 dock. Below format is markdown (to lazy to convert it)

## Instructions for fixing the blanking monitor on dock issue within Ubuntu.
**Make sure to reboot after making the changes!**

#### Disable USB AutoSuspend
* `sudo gedit /etc/default/tlp` and change the below value from `1` to `0`

```
USB_AUTOSUSPEND=0
```

* `sudo gedit /etc/udev/rules.d/01-usb-dock.rules`. This will create a new file.

```
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="2b95", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="0005", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{idProduct}=="0002", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="1d6b", ATTR{idProduct}=="0003", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04d9", ATTR{idProduct}=="0143", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="04f3", ATTR{idProduct}=="24a1", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0608", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0610", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05e3", ATTR{idProduct}=="0620", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="06c4", ATTR{idProduct}=="c411", TEST=="power/control", ATTR{power/control}="on"
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="17e9", ATTR{idProduct}=="6006", TEST=="power/control", ATTR{power/control}="on"
```

#### Disable Display Power Management
* `sudo gedit /etc/X11/xorg.conf` Append the below options to the file.

```
Section "Monitor"
Identifier "DVI-I-3-2"
Option "DPMS" "false"
EndSection

Section "Monitor"
Identifier "DVI-I-2-1"
Option "DPMS" "false"
EndSection
```

#### Disable audio suspend
* `sudo gedit /etc/pulse/default.pa`. Comment out the line indicated below.

```
### Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle
```

#### Disale USB wake in BIOS
Boot into the BIOS by pressing the F12 key as the machine turns on. Under `Power Management` >> `USB Wake Support` uncheck both boxes.
edclement is offline   Reply With Quote
Old 01-26-2018, 05:43 PM   #16
aplund
Junior Member
 
Join Date: Jan 2018
Posts: 4
Default

I have only just recently come across this hardware.

I too have been experiencing the resetting. At first I thought it was my specific unit as the USB-C power appears to be cut as well and the LED goes from white to red which might indicate that there is some physical link problem. But after reading this forum, I'm starting to doubt that.

The "working solution" posted seem to change vastly too many things to narrow down the problem. It cannot possibly be that _all_ of them are required to fix things.

I'm on ArchLinux so the Ubuntu based instructions need to be converted to my settings. I've tried fiddling with each of these things and none of them individually seem to help.

Can you try removing one fix at a time and see when the issue of disconnections reappears?
aplund is offline   Reply With Quote
Old 01-27-2018, 06:33 PM   #17
edclement
Junior Member
 
Join Date: Jan 2018
Posts: 11
Default

Trust me, I tried each of these individually and as soon as I reverted any one of them the problem started again. It seems to me that any power management that Linux attempts to apply to this unit causes either the unit itself or three connection to cycle.
edclement is offline   Reply With Quote
Old 01-27-2018, 08:41 PM   #18
aplund
Junior Member
 
Join Date: Jan 2018
Posts: 4
Default

I cannot see how bios support for wake on USB could cause these disconnections. That just seems totally orthogonal to the working theory here.

I think concentrating on the power management is a reasonable theory.

If the power management is the issue, then the dropouts should occur with no devices connected. Can anyone confirm that it still happens with no monitor, or other devices attached (you can't do much about the audio drivers).

I need to sort this out, but I only have access to the hardware during the week.
aplund is offline   Reply With Quote
Old 01-29-2018, 03:50 AM   #19
aplund
Junior Member
 
Join Date: Jan 2018
Posts: 4
Default

I have confirmed that this is the bit that makes things work:

Quote:
#### Disable audio suspend
* `sudo gedit /etc/pulse/default.pa`. Comment out the line indicated below.

```
### Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle
```
Interestingly it is only _one_ device that detaches from the bus (the 17e9:6006 device) which can be confirmed by watching "udevadm monitor".

I couldn't figure out why it was disconnecting. I tried all sorts of other approaches using the power/control interface as suggested, but nothing worked.
I think the runtime PM of the audio output was a crucial part. I have a feeling that the CDC ethernet device might have something to do with it as well in as much as determining exactly _when_ a disconnect will occur.

The way this probably should be dealt with is via the DisplayLinkManager process as there is no kernel module for the display link device. The way this is done seems to just access USB data via the usbdevfs interface. I'm not sure if there is a way to stop the runtime PM stuff through that interface, but the DisplayLinkManager binary blob people should work on getting this fixed as nobody else can work on it (by design). Having audio output constantly on is a _hack_ and shouldn't be the way to rely on keeping the USB link up. Perhaps there is a less power intensive hack to achieve the same result.
aplund is offline   Reply With Quote
Old 03-20-2018, 09:14 AM   #20
andreiiar
Junior Member
 
Join Date: Mar 2018
Posts: 1
Default

Quote:
Originally Posted by edclement View Post
#### Disable audio suspend
* `sudo gedit /etc/pulse/default.pa`. Comment out the line indicated below.

```
### Automatically suspend sinks/sources that become idle for too long
# load-module module-suspend-on-idle
```
Indeed this workaround works solely.

Not sure if this is DL bug or PA bug and where to submit it.
andreiiar is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 05:18 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.