When a Driver Challenges the Kernel's Assumptions
Key topics
A heated debate erupts over a driver's developer who challenged the kernel's assumptions, with some commenters scrutinizing the driver's creator for seemingly admitting to referencing an LGPL library while implementing their own under a different license. While some call out the move as dubious, others point out that "Clean Room" reverse engineering isn't always a legal requirement. The discussion takes a practical turn when one commenter suggests approaching the Linux Foundation to access vendor documentation typically shrouded in NDAs, sparking a nuanced conversation about negotiating contract terms for open-source projects. As the thread unfolds, it reveals the complexities of navigating licensing, reverse engineering, and collaboration in the open-source world.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
1h
Peak period
4
4-6h
Avg / period
2.2
Based on 20 loaded comments
Key moments
- 01Story posted
Dec 25, 2025 at 7:32 PM EST
9 days ago
Step 01 - 02First comment
Dec 25, 2025 at 9:01 PM EST
1h after posting
Step 02 - 03Peak activity
4 comments in 4-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 27, 2025 at 4:07 AM EST
7 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Uh I think I think that's way too mean to the email. From a random web form they got some technical information, a useful CC, and offer to have a call. Not bad at all!
Also, my basic theory about hardware problems is that the problem is less that they won't share the docs, and more that even the internal docs suck. When you essentially co-evolve devices and software through many revisions of each over many years, it's easy to get a complete mess that nobody understands.
(Of course, in this specific case, DisplayLink was new, so it's maybe less of a problem.)
I wonder if they'll have no issues with people directly reading their code while happening to implement the same functionality with a closed license? Or a GPL-style one?
Hardly "Clean Room"....
"Clean Room" RE isn't always legally required.
I'd argue that it is. I'd also argue that directly viewing the source doesn't mean you can't write a non-infringing driver.
Unless the source is owned by Oracle, in which case, my hourly rate goes up 100x.
Looking at the answer, I wouldn't call it unhelpful. They were planning to release a source for the library that would essentially implement all the needed data interfaces? That's more than helpful and at least they responded.
I tried contacting Nuvoton for example about their documentation for some of their super I/O chips which lack Linux support (they do document a bunch of their chips pretty well, but for some weird reason not all).
Not only I got no details, I literally didn't even get a response from them at all. So above case is hugely better.
Unless it's just some dumb formality. I can try Linux Foundation.
More info here: https://www.linuxfoundation.org/legal/nda
Source: been there, done that.
"<mglock> DisplayLink TM seems to be very communactive. <mglock> asked the for specs for their DL-120/DL-160 chips, and got a detailed answer withing 4 hours."
While USB-C and DisplayPort have taken over most external displays these days, plenty of all-in-one USB docks still use DisplayLink. Not every device supports DP ALT mode, and some devices (like several of Apple's M chips) don't support more than one external display over DisplayPort, making it a necessity to fall back to alternatives like DisplayLink.
While adding pause / resume functionality certainly solves the problem, it does seem to be a rather far-reaching change. Prior to this work display updates always succeeded, but now everything has to be aware that they can fail just in case userspace is talking to a (increasingly rare) DisplayLink? We have a new type of wait queue (or wait type) for "waiting on TTY operation"? Another approach would be to store two text buffers, one for the current state (ie what DisplayLink is dipslaying) and another for the desired state. Diff the two to determine what to update when the DisplayLink is ready again. It seems like this is basically what happens in graphics mode anyway, with dirty rects (which would just become larger dirty rects basically until the DL is ready for more commands). If this feels too much like policy, make a user-space component.
It seems like a solution which came from "we are deep in the bowels of the device driver, what is simplest possible thing we can do?" and there's nothing wrong with that, but it does end up moving complexity elsewhere somewhat.