Synaptics uses patents to push a Rust DisplayLink driver off GitHub

Vino was an unusual project: a clean-room, Rust-written DRM/KMS kernel driver that aimed to make DisplayLink DL3 docks behave like ordinary Linux displays. It reached the point where it lit panels on three dock families, replacing both the out-of-tree EVDI kernel module and the closed-source DisplayLinkManager daemon that Linux users normally depend on. Then Synaptics, which owns DisplayLink, sent cease-and-desist notices and a patent attorney's letter. Mike Lothian took the GitHub repository down. The dispute is now a test case for how patent claims interact with independent driver development, and for whether "AI-assisted" changes anything legally. It does not, but the case is being discussed as if it might.

The facts, as reported by Phoronix, Tom's Hardware, and the correspondence on the Linux kernel mailing list, are specific enough to reason about. Synaptics does not allege that Lothian copied its code. It alleges that his implementation of the DisplayLink protocol infringes two UK patents. That distinction matters: this is a patent case, not a copyright case, and the defenses available are different.

What Vino actually was

DisplayLink is a family of chips and protocols for sending video over USB. On Windows, a vendor driver handles it. On Linux, the usual stack is the EVDI kernel module plus the proprietary DisplayLinkManager userspace daemon. That stack works, but it is out-of-tree and closed, which means it lags kernel changes and cannot be audited or fixed by the community.

Vino took a different route. It was a Rust driver implementing the DisplayLink protocol directly in the kernel's DRM/KMS subsystem. By late August 2026 it supported three dock families: Ella (DL-3x00), Ridge (DL-6xxx, including Dell's D6000), and Navarro (DL-7400). Phoronix describes it as clean-room reverse-engineered and partly AI-developed. Tom's Hardware reports that Lothian used Anthropic's Claude during development.

That combination, Rust plus reverse engineering plus an LLM, is exactly the kind of project the current toolchain makes possible and the current legal environment makes risky. A single developer can now build a kernel driver for a proprietary protocol in a memory-safe language, using an assistant to accelerate the tedious parts. The technical barrier has fallen. The legal barrier has not.

The patents Synaptics is asserting

According to the reporting, Synaptics asserts two UK patents. GB2484736 covers sending screen updates over a general-purpose network such as USB or Ethernet. GB2485613 covers a display controller that decompresses data only as needed. Both are described by Synaptics as fundamental to DisplayLink's proprietary technology, and the company provided claim charts that it says show the infringement.

The claim charts are the heart of the case. A patent claim is a precise legal boundary, and infringement turns on whether an implementation practices every element of a claim. A claim chart maps each element to the accused product. If the mapping is wrong, or if the claim is invalid, the case weakens. The community's argument is not that patents are illegitimate in general. It is that these particular claims cover functionality the hardware must perform to interoperate, and that the prior art and the patent pool's licensing terms change the analysis.

There is a practical asymmetry here. Synaptics can afford patent attorneys and claim charts. A hobbyist cannot, even when the legal argument is strong. The cost of responding is itself a tool, and the cease-and-desist letter is designed to impose it. That is why the case has attracted attention beyond the small world of DisplayLink users.

How the dispute escalated

Tom's Hardware reports that the dispute began in July 2026, when Lothian asked a Synaptics engineer for help with bugs. A company partnerships lead then raised patent concerns, and the legal department sent a cease-and-desist letter. The kernel mailing list correspondence lists notices dated 17 August and 5 October 2026.

When Lothian asked for details of how his code infringed, Synaptics escalated. Assistant general counsel Andrew Bateman said the company would bill him "to recoup the cost and effort required to create such documentation of your infringing acts," according to Tom's Hardware. Bateman also said that open-sourcing the driver would mean "eviscerating DisplayLink's competitive advantage," and told Lothian that if he wanted to notify the media or publicize the response, he was encouraged to do so.

That last line is unusual. Companies usually prefer silence, and a lawyer inviting publicity is either a confident signal or a misjudgment. Either way, it had the effect of putting the correspondence in front of a much larger audience. Synaptics has made no public statement on the case, so the account is one-sided, but the documents are public and the company has not disputed their content.

Lothian's defense

In an October reply to Clive So, a partner at the London firm J A Kemp, Lothian wrote that he does not accept that any act of his infringes either patent. His argument has three parts, each of which is a recognizable patent defense.

First, he argues that the claims were granted only after a network-transport feature was added, and that the feature was not new. He cites the 1998 RFB/VNC remote-display specification as prior art. If the feature was already disclosed before the priority date, the claim should not have been granted, or should be narrowed. Prior art is the standard way to attack a patent's validity.

Second, he argues that the patented methods are performed by the dock itself, which users bought lawfully. This is an argument about who practices the claim. If the dock, not the driver, carries out the decompression and transport steps, then the driver may not be the infringing actor. The patent exhaustion doctrine can also limit what the patentee can control after a lawful sale.

Third, he argues that Synaptics, which acquired DisplayLink in July 2020, is a member of the Open Invention Network, the Linux patent non-aggression pool, and that its affiliates' patents fall under that licence. He became a licensee on 17 August. He asked the firm to identify any provision or Limitation Election that excludes the DisplayLink patents, and said any proceedings belong in Scotland's Court of Session.

The OIN argument is the most interesting one for the Linux ecosystem. OIN is a defensive patent pool: members agree not to assert their patents against other members for Linux-related software. If the DisplayLink patents are covered and Lothian is a licensee, the claim may fail on licence grounds without reaching validity or infringement. That would be a narrow win, but an important one, because it would confirm that the pool does what it was created to do.

Why "AI-assisted" is a red herring

Much of the coverage frames the case around the use of Claude. That framing is understandable and mostly unhelpful. Patent law is concerned with the implementation and its commercial exploitation, not with the tools used to write it. Using an LLM to draft code is no different, legally, from using an IDE, a static analyzer, or a code generator. The liability, if any, attaches to the person who wrote and distributed the code.

There is a real question about authorship and copyright for AI-generated code, but this is a patent dispute about a protocol implementation. The patents are not about how the code was produced. They are about what the code does. A human who writes an infringing implementation by hand is just as liable as one who used an assistant; a human who writes a non-infringing implementation with an assistant is just as safe.

The more interesting AI angle is economic. LLMs lower the cost of producing the kind of specialized, low-level code that used to require a rare combination of kernel expertise and reverse-engineering patience. If that cost falls, more people will attempt projects like Vino. If patent enforcement is cheap and legal defense is expensive, the result is fewer of those projects reaching the point where they matter, regardless of their merits. The tool changes the supply of developers, not the legal standard.

What this means for out-of-tree drivers

Linux depends on out-of-tree drivers for a long tail of hardware. Vendors often do not maintain kernel drivers, or they ship closed userspace daemons that lag kernel releases. Community drivers fill the gap, and they do so without the vendor's permission, which is the whole point of reverse engineering for interoperability.

Patent claims against those drivers are a structural risk. If a company can shut down a community driver with a letter and a threat of fees, the chilling effect extends beyond the specific project. Developers learn that working on certain hardware is legally hazardous, and users lose the option of a free driver. The hardware still works on Windows, where the vendor's stack is licensed and supported. On Linux, it becomes second-class.

This is a good reminder that "clean-room" isn't a legal defence. Clean-room processes are a defence against copyright claims (through copying source). It's not a defence against patents (which protect methods, irrespective of how independently they're implemented). A developer could write every line of code from scratch and still violate a patent that claims their implemented method.

Which is why the OIN argument is so important. Defensive patent pools are one of the few ways for small developers to fight back without engaging a law firm. If OIN coverage is the case, it's a template. If not, it's a reminder that the pool's protections are less than what the community thought.

The Rust dimension

It's interesting what Vino says about Rust in the kernel. A hobbyist implemented a DRM/KMS driver for a proprietary USB display protocol (in Rust). And got it to work on multiple generations of docks. That's some hardcore low-level engineering. The Rust for Linux project has been making the case for years that memory safety makes drivers easier to implement and harder to mess up. Vino's a data point for that, outside of the formal process.

It's offline now. And the author is fighting patent stuff instead of writing code. Either way, it's a loss for the ecosystem. It's good for the kernel when there are drivers available without fear. And the patent claims that go after independent implementations (rather than copying) are why that fear is rational.

The precedent question

The case won't likely lead to a big ruling. Most of these disputes settle or just die before they get to the merits. But that's the point. Without any precedent, each new developer must rehash the same issues from scratch. With less money, less time than the other company. A clear ruling on OIN coverage, or where the patented method is performed in the case of a shared driver/device implementation would be better than a settlement.

In the meantime, the best stance for community driver work is what Lothian did. Have a public record of what you observed, what you inferred, and what was independently implemented. It's not a guarantee, but it's the difference between a defensible position and an expensive position.

Conclusion

The Synaptics dispute isn't about the existence of patents. It's about whether a patent claiming a protocol's basic operation can be used to block an independent non-commercial implementation of that protocol for a platform the vendor doesn't support. Lothian's defences, prior art, where the patented method is performed, and OIN licence are the right things to try out that question. It will have implications beyond DisplayLink docks.

For developers, it's a practical lesson to document what a driver does, and where you got your knowledge. That's what enables a defence. For the ecosystem, it's a lesson that legal defence is now part of driver development. A memory safe language and a good LLM assistant reduce the technical cost of driver development. They don't reduce the cost of defending it. Until the legal tools are better, some hardware will be off-limits in Linux because of reasons other than engineering.

Sources

• LWN, "Synaptics patent claims stop work on DisplayLink drivers" (10 November 2026): https://lwn.net/Articles/1102549/
• MLQ, "Synaptics uses DisplayLink patents to push a hobbyist's open-source Linux driver off GitHub": https://mlq.ai/news/synaptics-uses-displaylink-patents-to-push-a-hobbyists-open-source-linux-driver-off-github/
• Phoronix, "Synaptics Appears To Use Legal Threats To Block Open-Source DisplayLink Driver": https://www.phoronix.com/news/Synaptics-Blocks-Vino-Driver
• Tom's Hardware, "Synaptics sends cease-and-desist order to creator of open-source DisplayLink driver": https://www.tomshardware.com/peripherals/docking-stations-hubs/synaptics-sends-cease-and-desist-order-to-creator-of-open-source-displaylink-driver-dares-him-to-publicize-its-threats-dev-reverse-engineers-displaylink-using-claude-ai-and-rust-synaptics-threatens-to-bill-creator-for-legal-documentation
• Linux kernel mailing list, Lothian's reply: https://lkml.rescloud.iu.edu/hypermail/linux/kernel/2610.1/14966.html

← back to posts