If evdi module is something you manually compiled and it does not get automatically updated with each kernel update, such as akmods do, then a single kernel update will prevent use of that module until you manually recompile it.
The module must be compiled to match the kernel in use. Akmod packages handle that automatically for you but manual compiled packages require a manual recompile.
The displaylink.service OTOH is another issue. Did you install displaylink from an rpm repo or create it manually? Was that service ever active? or installed?
When I am trying to enable displaylink-driver.service instead, I get
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
I expect this means that you don’t explicitly enable the service—something else should as required.
It’s probably worth asking the folks on the GitHub repo who are providing the rpm for instructions on what needs to be done if they don’t already provide them?
Thank you very for the help. The GitHub repo stated that I should sign the module because of secure boot. The displaylink-driver.service is now active and I can use my docking station.