Hacker News Reader

Comment by fulafel | Hacker News Reader

re "Driver availability and compatibility for Mac/Linux is spotty to non-existent":

Is it true that DisplayLink doesn't work well with Linux? Some years ago people were saying that the usb-to-monitor dongles worked well. A casual web search also gives this impression, with good support provided by the DisplayLink company.

View on HN

You can make Display Link (DL) work with Linux, there are drivers from the vendor and an adaptation script for Debian based distros [1] (and variants for others IIRC). You may have to fiddle with the configuration to avoid issues like minor display corruptions or cursor glitches. I made it work clean once, but in the end I returned the dock. DL is to me a bad idea, except is some specific cases.

The way DL works is that a driver on your PC creates a virtual frame per screen, composed on your PC. Then this screen(s) content is compressed and send to the dock DL chip using a proprietary driver. The chip on the dock reconstructs full images and send that to locally attached screen(s) using local HDMI or DisplayPort interfaces. Now yes, those local interface(s) may run at 60 Hz and be 4k. But the bottleneck is not there, it is in the compression and transmission over the USB link. In my experience, any use-cases with large changing content (e.g.: full screen video) will give a bad experience on a laptop (which is what I used, and is natural with a dock). The compression will ramp up the CPU load on the laptop, the ventilator will get noisy, and the display content was choppy too. It's definitely not the smooth experience you expect from 60 Hz.

I guess DL can provide very good results with a laptop for use-cases with mostly static content: reading documents, spreadsheets, word, etc. Just don't expect to have a nice experience when most of the screen content changes quickly.

So I returned my DL USB-C dock, bought a super cheap one as actually I only have a 1440pt external screen for which any cheap dock will support true 60 Hz, and I have a nice experience. For 60 Hz with 4k it'll have to wait, and it won't be with DL as far as I'm concerned.

[1] https://github.com/AdnanHodzic/displaylink-debian

I was curious about that compression and found an analysis[1] of the DL protocol. The first thing I saw was that it doesn't just render to a framebuffer on the PC, it renders twice, once at 16bpp and another at 8bpp (which it will combine to achieve 24bpp). The use of Huffman encoding seems consistent with the state of compression in 2003 [2]. If doing it today you'd probably go with x264 lossless but that would have been too slow 15 years ago. In conclusion I'd guess the lag is caused by the split framebuffers. Or an inefficient proprietary driver.

[1] https://pdfs.semanticscholar.org/a3ed/739f229315fe8673f227e7...

[2] https://forum.doom9.org/showthread.php?t=165545

The problem is that the driver situation is horrible mess and also that there are three totally incompatible generations of the technology.

The driver that works best is udl, which integrates with KMS/DRI and presents the dongle like additional CRTC and thus allows the existing GPU to be used for acceleration.

There is also udlfb (IIRC both udl and udlfb are in kernel source tree) which tends to be what is used by default by most distributions. udlfb exposes the dongle as additional /dev/fbX device. That means no acceleration to speak off and handling hot-plug is should we say interesting.

Both of the opensource drivers support only USB2 DL dongles.

The there is the binary driver from DisplayLink itself, which I suppose (haven't used it) comes with it's own set of issues, probably starting with the typical issues of binary-only proprietary drivers.

I use display-link dongle as port of USB-C docking station. It plugs and unplugs well, but driver uses a lot of cpu and there is no graphic acceleration. Not sure if would handl 4k video. Great for IDE.

Reply on news.ycombinator.com