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:
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?
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.
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:
@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.
Hi, I somehow managed to get my DisplayLink adapter working on latest
This is what the Containerfile of my custom image looks like:
RUN curl -o /etc/yum.repos.d/fedora-multimedia.repo https://negativo17.org/repos/fedora-multimedia.repo
COPY --from=ghcr.io/ublue-os/akmods-extra:fsync-40 /rpms/ /tmp/rpms
RUN find /tmp/rpms
RUN rpm-ostree install /tmp/rpms/kmods/kmod-evdi*.rpm
COPY build.sh /tmp/build.sh
RUN mkdir -p /var/lib/alternatives && \
/tmp/build.sh && \
ostree container commit
According to the BlueBuild docs and the akmods repo, the evdi module is not installed from ublue’s COPR, but from negativo17’s multimedia repo, so we need to add it, that’s where we get the evdi-kmod-common* from.
