DisplayLink Driver Reinstall

I am on bluefin-dx-nvidia:gts, custom-built using image-template. I use multiple monitors, with some on the Pluggable USB DisplayLink adapters, which work great.

My last nightly build seemed to have the DisplayLink drivers removed, which caused those monitors to stop working - I use my machine for work, so I need them.

After rolling back to a pinned version, Cockpit Client now shows the diff from that nightly update:

Removals:

  • displaylink-6.0.0-2.fc39.x86_64
  • kmod-evdi-6.9.7-100.fc39.x86_64-1.14.5-1.fc39.x86_64
  • libevdi-1.14.5-1.fc39.x86_64

How can I safely reinstall DisplayLink to my custom bluefin build? Is it just as simple as adding those packages back or is there a more preferred way?

Can you point me to the last PR/commit that brought those in?

Also, can allow users to choose whether they want to keep DisplayLink drivers?

1 Like

I think adding the packages should fine, and also enabling the service units. evdi is busted in newer kernels, see: feat: Restore evdi to extra by KyleGospo · Pull Request #229 · ublue-os/akmods · GitHub

These things are awful, I think we’ve removed and readded them 4 or 5 times throughout the life of the project. There doesn’t seem to be a middle ground. :frowning:

I am having a similar issue with the latest Bazzite version. On Friday I had no problems connecting to my Dell D6000 with a connected monitor but yesterday when I tried, the monitor no longer connects. I have a hybrid laptop with an Intel/Nvidia cards and running bazzite-nvidia stable image. Even connecting a monitor direct on the hdmi port on my laptop does not work. I believe HDMI is tunnelled over displayport so that tracks.

I tried rolling back and, I can see displaylink, kmod-evdi and libevdi are removed from stable-40.20240815.0 release. So I tried rebasing using stable-40.20240809.0 and that reinstalled the 3 packages again, yet my monitor still refuses to connect via docking station or direct.

I rebased again to the latest (stable-40.20240819.0) and tried installing the latest displaylink package manually with rpm-ostree install with the below command:

“rpm-ostree install ./fedora-40-displaylink-1.14.6-1.github_evdi.x86_64.rpm”

It fails with:

“package displaylink-1.14.6-1.github_evdi.x86_64 from @commandline requires dkms, but none of the providers can be installed”

So I’m not sure what to try next.

@jorge - Could you provide some additional guidance on using akmods and service units? I’m relatively new to this and have been encountering issues.

Here’s what I’ve been attempting: I followed the instructions for akmods with the aim of subsequently installing the driver RPM. However, I’m encountering build errors when I incorporate the following into my Containerfile:

# DisplayLink - Install akmod from extras (since evdi was moved there)
ARG AK_TAG=39

# Added this due to a build error stating it could not find kmod-common
COPY --from=ghcr.io/ublue-os/akmods:main-$AK_TAG /rpms/ /tmp/rpms
RUN find /tmp/rpms
RUN rpm-ostree install /tmp/rpms/kmods/evdi-kmod-common*.rpm

COPY --from=ghcr.io/ublue-os/akmods-extra:main-$AK_TAG /rpms/ /tmp/rpms
RUN find /tmp/rpms
RUN rpm-ostree install /tmp/rpms/kmods/kmod-evdi*.rpm

Is it more effective to use akmods if building directly from a fork (like ublue or bluefin), or does it also work for template-based approaches?

For now, I’m maintaining my pinned build until I can reintegrate the necessary DisplayLink kernel mods and packages. I plan to create a how-to guide to simplify this process for others once I’ve figured it out.

akmods are outside my skill set, I’ll try to get more eyeballs on your questions though!

@j0rge - Thank you - much appreciated!

1 Like

For someone just new to this, is this even worth tinkering and doing? Or is it an easy rpm-ostree install xxxx type situation?

I am on bluefinDX 39.

I’m considering making a custom containerfile to handle this also. However, I’m curious, will this be coming to the surface dx latest anytime soon?

@profetik-777 @arenas93 Maybe this info will help you. I did some research and I believe that what I describe below is the generally accepted process for applying this kind of mod. I would appreciate it if someone corrects me if I’m wrong about that though.

So I tried a couple of things and got it working on to my satisfaction on gts, but it is buggy when I try latest. When I tried latest, whenever I move windows, they have some strange secondary images around them and around the edges of the screen. I don’t know where to start with fixing a bug like that and I believe that I performed the installation correctly. Can someone tell me where I would report an issue like this? Would it be on the akmods-extra github? On gts it still isn’t perfect, because there are still some random pixels that shine as different colors rarely, but it’s usable.

Anyway here are the steps I followed. I hope this info helps someone else who is just getting started also!

  1. I forked the ublue-os/image-template repo here’s my version:
    GitHub - Anodyine/bluefin-surface-dx-nvidia-with-displaylink

  2. Then I ran brew install gh

  3. Then gh auth login

  4. Then followed the instructions to log into my github account

  5. Then I cloned my new repo locally (with git clone).

  6. Next, I followed the instructions in the repo README to enable workflows and setup signing.

  7. Finally I was ready to customize! As you can see in the ContainerFile on lines 18,36, and 39 I edited it to base off of the bluefin-dx-surface-nvidia:gts.

  8. On line 51, I pasted in deerf0x’s code and modified it for my needs. Since I’m on a surface, I changed line 53 from fsync-40 to surface-39.
    (or surface-40 when I was testing bluefin-dx-surface-nvidia:latest more info in the ublue-os/akmods repo)

  9. Then I pushed up my changes and it triggered the github workflow to start! Yay! You can see the actions that have run on my repo here: Workflow runs · Anodyine/bluefin-surface-dx-nvidia-with-displaylink · GitHub

  10. Once the action was finished (the green dot was shown) I went back to my local terminal and ran this command sudo rpm-ostree rebase ostree-unverified-registry:ghcr.io/anodyine/bluefin-surface-dx-nvidia-with-displaylink
    That added the displaylink driver packages.

  11. Then I rebooted and my monitors worked.

I know this is a pretty long process, but the advantage of it is that now you can add your own package installs to build.sh or customize the Containerfile as you find more mods you want. Then you can install this on whatever computer you want whenever you want without reinstalling all of those packages by hand! Wow! I guess this is what is called “infrastructure as code.”

Future improvements:
I wonder if there is a way to enshrine all of my preferred gnome settings, extensions, etc in here also. I use vitals on every computer and it would be great to have it there whenever I install it. Also, I think there is probably a way to make a version of this github action that creates one of these for each akmods-extra tag (fsync-40, surface-39, etc.)

I think I will stay on gts for now since using my dock is a major part of my workflow. Although I do want latest because it make my multitouch touchpad gestures work… Hmm. I guess I can’t have it all yet.

2 Likes

Thanks for the write up, I was able to follow along with a few minor adjustments and personal touches!

After getting a successful build and rebasing I was able to successfully use my Dell UD22 working with my monitors