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.)
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to