Make the Linux driver open source and get it into the kernel
If the DisplayLink driver existed in the kernel, it would be SO much easier for the users to get it working. In my role as Chief Digital Officer for a large company (of 8000 people), I would probably have bought 500 of these devices IF the driver were just upstream (you know, how Linux devices normally "just work" without the aggro common in the Windows world). However, the annoyance of a manual driver install, especially when it's broken on updates to newer kernels, is just something I wouldn't want to invest in. Please consider that proprietary drivers are serious impediment to sales, and just work with a willing community upstream.
-
Stolen Maker 020 commented
Dealing with proprietary drivers that require manual installation can be frustrating and time-consuming, especially in large-scale environments where efficiency matters most. In the same way, when facing a locked or stuck safe, relying on a professional for kluis open maken scheveningen ensures a fast, secure, and hassle-free solution, saving you time and avoiding unnecessary complications. https://slotenmaker020.nl/
-
Reinder Feenstra commented
The products and technology look great,, but without proper Linux support it is a no-go for me. I've learned my lesson with other hardware which didn't have open drivers, it breaks from time to time resulting in waisting time to get it fixed again.
-
Amy Brooks
commented
Turning a Linux driver into open source and getting it into the kernel is a multi-step process that requires clean code, proper licensing, and careful upstream collaboration. Here's a practical roadmap:
Choose a license & clean IP — Select a GPL-compatible license (GPLv2 is kernel standard). Remove/prove ownership of any third-party blobs. Add SPDX headers.
Follow kernel style & APIs — Run checkpatch.pl, follow the Kernel Coding Style, use kernel APIs (no userspace hacks), and avoid proprietary interfaces.
Modularize & document — Split into well-scoped files, add Kconfig, Makefile, and driver docs (Documentation/), device tree bindings if relevant.
Write tests — Provide regression tests, runtime checks, and reproduce steps for maintainers; include samples and stress tests.
Create a development tree — Host a public git repo, keep a clear commit history, and sign off commits (Signed-off-by:).
Engage maintainers early — Find the right subsystem maintainers and mailing lists (LKML, subsystem list), send small logical patches with proper cover letters. Expect review cycles and iterate on feedback.
Submit patches via email/git — Use git send-email or pull requests if requested; include Cc: stable@vger dot kernel dot org for stable backports when applicable.
Respond to reviews & testing — Address comments, add suggested changes, and provide test results (CI, autobuilders). Persistence and good communication matter.
Get MAINTAINERS entry — Once accepted, add yourself or the team as contacts in the MAINTAINERS file if appropriate.
Ongoing support — After upstreaming, continue maintenance (bugfixes, API changes, backports).
If you also provide web interfaces or dashboards around the driver (device management, logs, or OTA updates), consider engaging web application maintenance services(https://www.cmarix.com/support-maintenance.html) to keep those companion tools secure and up to date while your kernel code evolves.
-
Alexander Dirun commented
A company I worked with adopted devops development services, and the results were impressive. They improved deployment speed, reduced downtime, and automated processes. The site I came across shows how to achieve similar outcomes. It’s a balanced explanation with use cases. I think it’s a great resource if you’re evaluating vendors. Read more on the site https://apprecode.com/services/devops-development to understand devops development services in depth.
-
Kiçik Ferhat commented
Importante
-
Christophe WERMELINGER commented
I just install DisplayLink driver on a 2019 HP Pavilion laptop running on Linux Mint 22.1 ... All packages seem to be properly installed (with or without secure boot), but no way to get display on my 2 ASUS VU249CFE screens.
And driver installation is not that easy.
Very disappointed, if the issue remains, I will send back my Port Designs docking station and get refund.
It would be so easy to have an open source linux driver !! -
area51pilot commented
I completely agree! I upgraded to Ubuntu 25.04 aand checked all my software except this. I forgot to make sure drivers were available even though this happens all the time with new releases on an updated kernel. :-|
At the very least make sure the drivers are available for download.
-
Sam Vervaeck
commented
Just adding to the heap of comments. This issue is THE reason I'm returning my purchase.
-
Rémi Letot
commented
ouch, I'm so happy that I came here before buying for my client... So, no displaylink today :-(
-
Ezequiel Partida commented
Wow,, I am very impress.. This post was on january 21, 2017, almost 7 years ago and still it is only available for ubuntu and not in kernel, and the one for fedora only works for fedora thanks for fedora systemd scriplets.
In the company I work we have more than 80 of this devices and I have recommended to use other brand which is much cheaper and linux compatible since I guess other distro customers are NOT important for displaylink / synaptic.
-
JohnChris Franklin (Chris) commented
@DisplayLink - You just lost ANOTHER customer using Linux. My next order of docks will be Thunderbolt based.
-
82UN0
commented
Distributor ID: Ubuntu Description: Ubuntu 22.04.3 LTS Codename: jammy
Display HDMI not working after installing Kernel : 6.2.0-26-generic #26~22.04.1-Ubuntu & synaptics-repository-keyring.debWhy have to fear every kernel change?
-
Matthijs W
commented
It’s absolutely unacceptable that this driver keeps breaking. It has cost me many hours to troubleshoot issues with my DisplayLink stuff. I advice against buying DisplayLink for Unix based hardware, please save yourself the trouble and buy a thunderbolt dock instead.
-
Daniele Turra commented
Up
-
TurtleNeck
commented
It's astounding that this issue has received the highest number of votes, and yet there has been no response from Displaylink. It's evident that there is a large Linux community that is willing to help with development, and many more who would use it. It's baffling to me that the company has not deemed it necessary to respond. The driver ought to be included in the Linux kernel; otherwise, it will inevitably fail with each new release and be fixed only after the kernel release becomes obsolete.
-
82UN0
commented
I agree, again and again.
Today it is not advisable to recommend DisplayLink to other Linux users. And since they are also often on Windows, they will not have to trust this brand that takes its users hostage ...
Either you provide updates or you release the code.
Displaylink's attitude is really pathetic -
Dunc P commented
5 year since this comment and still nothing. What a shame.... oh I mean what a SHAM!
-
Mike Hodson commented
Hello, we need opensource. Otherwise thunderbolt 4 is more useful. Damn intel, I want AMD.
-
Dylan Taylor commented
So much this. Just broke again on kernel 6.1/6.2. This wouldn't happen if it were a mainline module.
-
Josh Harding commented
absolutely critical the DisplayLink driver is injected into the kernel! PLEASE PLEASE PLEASE work on making this happen!