On 4/3/21 10:39 PM, Frederic Muller wrote:
I enclosed all the steps in that paste here https://paste.centos.org/view/bf947c35 . The full make.log is at "the bottom" of the page (starts line 124).
Great. That log has information about the actual failures, starting on line 143. Searching for that error should lead you here:
https://github.com/DisplayLink/evdi/issues/249
There, the developers are discussing support for kernel 5.11 which isn't present in version 1.7.2. There are other release branches (1.8.0 and 1.9.0) but I would disregard those for now. 1.8.0 is older than 1.7.2 by several months, and 1.9.0 was released the same day as 1.7.2. There are no published releases that will support 5.11:
https://github.com/DisplayLink/evdi/releases
That leaves you with a handful of options, of which I think two stand out. The first would be to simply stick with kernel 5.10. It looks like 5.10.22-200.fc33 is still in the updates repo, and you could fall back to that, and I'd expect the evdi driver to work.
The other option, which is more work, would be to clone the evdi repo from GitHub and manually build the evdi kernel module. It looks like that would be:
git clone https://github.com/DisplayLink/evdi.git git checkout devel sudo make -C module install sudo make clean
If you go that route, you'll need to manually rebuild the module each time the kernel updates (until the displaylink-rpm package is updated to a version that supports your kernel, when such a version is published), and I'm not sure whether you might run into compatibility problems from a version mismatch between the kernel module (which will not be the 1.7 branch) and the userspace components (which will be the 1.7 branch on your system).
Between the two, I'd suggest sticking with kernel 5.10 until the displaylink-rpm catches up. (My employer has a large fleet of DisplayLink hardware, and periodically has to avoid updating our non-Linux desktop operating systems in order to keep them working, accepting the security vulnerabilities that come from delaying updates, which is why I recommend avoiding this hardware whenever possible.)