# DisplayLink RPM packages a vendor driver as a Fedora RPM > displaylink-rpm is a Makefile and spec file that rebuild the DisplayLink USB display adapter driver as an RPM for Fedora, CentOS Stream, Rocky Linux and AlmaLinux, with the evdi kernel module included. It is a packaging project rather than a driver, and most of its documentation is about which upstream evdi version to build against and how to keep it working under Secure Boot. **displaylink-rpm/displaylink-rpm** — RPM sources for the DisplayLink USB display adapters - Repository: https://github.com/displaylink-rpm/displaylink-rpm - Stars: 812 · Forks: 90 - Language: Makefile - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/displaylink-rpm-displaylink-rpm ## This is a packaging recipe, not a DisplayLink driver The repository is short on code and long on packaging decisions. Its primary language is a Makefile, and the README opens by saying what it is: the recipe for building the DisplayLink driver into an RPM package for Fedora, CentOS Stream, Rocky Linux and AlmaLinux. The driver itself is not written here. It comes from DisplayLink as a zip archive of the Ubuntu-flavored DisplayLinkManager package, and the kernel side comes from the open source evdi library, which the package includes. The README calls the result a package for the USB display adapters, and lists the device families covered: DL-7xxx, DL-6xxx, DL-5xxx, DL-41xx and DL-3xxx. That distinction matters when you evaluate the project. Nobody here is fixing a rendering bug in the USB graphics stack. What the maintainers do is decide which upstream evdi version to ship, wire the download and packaging steps together, and produce a file that a package manager can install. The build outputs are named for the architecture and version, for example an x86_64 RPM and a source RPM, and there is a separate pair of outputs when the evdi library is taken from GitHub rather than from the bundle that ships inside the DisplayLink driver package. ## Three upstream version numbers have to be kept in step The packaging tracks three separate upstream version numbers, and the README explains why that is messy. They are the evdi kernel driver version, the DisplayLinkManager daemon and libraries version, and the download ID number that DisplayLink uses for automatic zip retrieval. The Makefile holds them as three variables near the top, with `DAEMON_VERSION := 6.4.0-22`, `VERSION := 1.15.1` and `RELEASE := 2` at the current release. `DAEMON_VERSION` is the DisplayLinkManager version and it is also part of the name of the zip that gets downloaded, in the form DisplayLink_USB_Graphics_Software_for_Ubuntu followed by the version. `VERSION` is the evdi driver version and it decides the name of the evdi tarball, v followed by the version. `DOWNLOAD_ID` is the query parameter used to retrieve the zip from the DisplayLink website. There is also a `RELEASE` variable with a contribution rule attached: set it to 1 when contributing a new upstream version, and increment it by one when adding other functionality to the spec file for the same upstream version. When a new upstream release arrives, the three variables have to be changed together, and the changelog at the bottom of displaylink.spec has to be updated in the same pull request. For a packager reading this for the first time, that is the whole onboarding: three numbers, one spec file, one changelog. ## make decides which evdi source to build from The build entry point is documented plainly. Running the command `make` from inside the checked out directory downloads the files that are needed and creates an RPM. The Makefile should fetch the pieces itself, so there is no manual download step. Which evdi source gets used depends on the target you pick. A default `make` uses the evdi driver bundled with the DisplayLink driver package. That is the conservative path, and it is the one a packager normally wants, since it pairs the kernel module with the daemon version DisplayLink shipped. If you need a newer evdi release from the evdi GitHub repository, and that version is not in the DisplayLink driver package yet, the README points at a different target: ```bash make github-release ``` There is also a development build. The stated preference is to track the current stable release of the evdi library, because Fedora kernels are often much newer than the ones that release officially supports, and a new kernel can completely break the build. The README frames the resulting bind clearly: you cannot upgrade your kernel without sacrificing your DisplayLink devices, and that is not great if the new kernel carries security or performance fixes. The evdi developers use the `main` branch for all changes, and the README warns that it also includes experimental and less tested changes that may break things in unexpected ways. The suggested order is to try the mainline build first and fall back to a `main` build if it breaks: ```bash make main make github-release ``` For Fedora Rawhide, a single target downloads from the `main` branch and builds: ```bash make rawhide ``` ## evdi version drift is a known upstream mess Behind the choice of build targets sits a version-tracking complaint, and the README explains it in unusual detail. The history is that code in the `main` branch used to be tagged, and that tagged version was what went into the DisplayLink driver package. Recently the maintainers started seeing newer changes appear in the DisplayLink driver package without the evdi library version being changed, and that created confusion and difficulty when it came to maintenance updates. The evdi people have acknowledged the issue and are working on making the process more transparent. The link in the README points at a discussion on the evdi issue tracker about it. For a user, the practical effect is that two RPMs with the same evdi version number may contain different kernel module code. That is exactly the situation where a `main` build versus a stable build choice matters, and it is why the packaging README spends more space on which evdi to build than on how to install the result. The repository also ships a note that it is now buildable cleanly via the spec file, in mock for example, and that source files can be downloaded with `make srpm`. ## Secure Boot on Fedora needs an enrolled Machine Owner Key The evdi kernel module has to be signed on a Secure Boot machine, and the README walks through the Fedora case in four numbered steps. Start by checking whether Secure Boot is actually enabled: ```bash mokutil --sb-state ``` If the answer is no, enrolling a Machine Owner Key is not required and that part can be skipped. From DKMS version 3.0.4 there is no need to create the MOK by hand, because DKMS generates its own key during installation and it only has to be enrolled once by the user. The steps then are: install the tools with `sudo dnf install mokutil dkms`, import the key with `mokutil --import /var/lib/dkms/mok.pub` and follow the enrollment instructions, reboot, and then build and sign the module with `sudo dkms autoinstall`. Verification comes last, with `sudo dkms status` or `sudo systemctl status displaylink-driver.service`. The README notes that after this the HDMI and or DVI ports on the docking station should work. The reboot in the middle is unavoidable, since key enrollment happens in the boot menu. On a workstation you administer yourself that is a minor inconvenience. On a locked-down corporate image it can be a blocker, and the repository does not describe a path around it. ## A Dell D6000 quirk is patched through PulseAudio config The hardware-specific section covers one docking station, and the fix is a commented-out line in the PulseAudio configuration file rather than anything in the driver. The symptom is described precisely. With the Dell D6000, DisplayLink 5.1.26 regularly loses communication with attached monitors, causing them to go blank and enter power-saving mode. At the moment the monitors blank, the kernel logs two messages about the failure to disable device-initiated U1 and U2. The kernel logs look like this: ```bash kernel: usb : Disable of device-initiated U1 failed. kernel: usb : Disable of device-initiated U2 failed. ``` The workaround is to disable power management for the audio device by commenting out a line in `/etc/pulse/default.pa`: ```bash ### Automatically suspend sinks/sources that become idle for too long # load-module module-suspend-on-idle ``` The link behind the workaround points at a DisplayLink forum post. What is worth noting is the shape of this fix. It touches the audio subsystem of the desktop session rather than the display path, because the offending behaviour is the audio device's power management interacting badly with the USB link. This is the only hardware-specific item in the README, so anyone with another DisplayLink adapter should not expect a matching section. ## The repository ships the udev, logrotate and service plumbing Beyond the Makefile and the spec file, the tree contains the files that make an installed package behave correctly on a running system. There is a displaylink-driver.service unit, a displaylink.logrotate file for log rotation, an evdi.conf, and the udev rules and helper scripts: 99-displaylink.rules, displaylink-udev-extractor.sh, displaylink-sleep-extractor.sh and a patch file for the udev script. There is also 20-displaylink.conf and 95-displaylink.preset for the logging side, plus a sources directory. The build side lives in ci/ and .github/, and the README states that packages are built automatically by GitHub Actions and uploaded to GitHub releases. Two workflow badges are shown, one for the build check and one for Rawhide builds. Release numbering on the repository tags tracks the upstream driver rather than the packaging. Version v6.4.0 was published on 2026-10-16 and is labelled as the DisplayLink 6.4.0 driver, v6.3.0-2 on 2026-09-21, and v6.3.0-1 on 2026-07-02. The repository is not archived and the last push was on 2026-10-16, so it tracks upstream releases closely. The licence is MIT. Contributing is straightforward: fork the repository and open a pull request, either for a new upstream version or for a packaging change, and the README says the first kind of contribution is the one it most relies on. ## Conclusion Adopt displaylink-rpm if you run a DisplayLink USB adapter on Fedora, CentOS Stream, Rocky Linux or AlmaLinux and want a distributable RPM with the evdi kernel module already inside it, rather than a vendor install script. Skip it if you are on a distribution that already packages evdi, or if your hardware works through the kernel built-in DisplayLink support, since the RPM only covers the USB display adapter families it lists. Before building, confirm Secure Boot state with mokutil --sb-state, since a signed evdi module needs an enrolled Machine Owner Key, and pin the evdi version in the Makefile if you would rather not track the main branch. ## FAQ ### How do I build the DisplayLink RPM package? Run `make` from within the checked out directory and the Makefile downloads the files it needs and creates the RPM. A source RPM can be produced with `make srpm`. ### What is the difference between make, make github-release and make main? A default `make` builds against the evdi driver bundled with the DisplayLink driver package. `make github-release` uses a newer released evdi version from the evdi GitHub repository, and `make main` builds from the evdi main branch, which the README warns includes experimental changes. ### How do I use DisplayLink on Fedora with Secure Boot enabled? Check with `mokutil --sb-state`, then install mokutil and dkms with `sudo dnf install mokutil dkms`, import the key with `mokutil --import /var/lib/dkms/mok.pub`, reboot, and build the signed module with `sudo dkms autoinstall`. Verification is done with `sudo dkms status` or `sudo systemctl status displaylink-driver.service`. ### Which Linux distributions does displaylink-rpm support? The README names Fedora, CentOS Stream, Rocky Linux and AlmaLinux. Packages are built by GitHub Actions and uploaded to the GitHub releases page, and there is a separate build target for Fedora Rawhide. ## Sources - [displaylink-rpm/displaylink-rpm on GitHub](https://github.com/displaylink-rpm/displaylink-rpm) - [Issues](https://github.com/displaylink-rpm/displaylink-rpm/issues) - [License: MIT](https://github.com/displaylink-rpm/displaylink-rpm/blob/master/LICENSE) - [README](https://github.com/displaylink-rpm/displaylink-rpm/blob/master/README.md) - [Releases](https://github.com/displaylink-rpm/displaylink-rpm/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/displaylink-rpm-displaylink-rpm