Kernel 5.9 - Unable to compile the rpm for Fedora 33

[enriqueartal]

I have been trying to get a new rpm since it does not work for the kernel 5.9. The problem is that I cannot build it since at some point it mixes 1.7 and 1.8 evdi versions. In the log I get:

• umask 022
• cd /var/tmp/displayportecebwC
• cd displaylink-1.7.0
• cd evdi-1.7.0/library/
• /usr/bin/make -O -j4 V=1 VERBOSE=1
  make[2]: Entering directory '/var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/library'
  cc -I../module -std=gnu99 -fPIC -c -o evdi_lib.o evdi_lib.c
  make[2]: Leaving directory '/var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/library'
  make[2]: Entering directory '/var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/library'
  cc evdi_lib.o -shared -Wl,-soname,libevdi.so.0 -o libevdi.so.1.8.0 -lc -lgcc
  cp libevdi.so.1.8.0 libevdi.so
  make[2]: Leaving directory '/var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/library'
• RPM_EC=0
  ++ jobs -p
• exit 0
  Ejecutando(%install): /bin/sh -e /var/tmp/displayport6I0Vg6/rpm-tmp.cF83IO
• umask 022
• cd /var/tmp/displayportecebwC
• '[' /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386 '!=' / ']'
• rm -rf /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386
  ++ dirname /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386
• mkdir -p /var/tmp/displayportVFCZyu
• mkdir /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386
• cd displaylink-1.7.0
• mkdir -p /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/libexec/displaylink/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/src/evdi-1.7.0/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/lib/systemd/system/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/lib/systemd/system-preset/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/lib/systemd/system-sleep/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/etc/logrotate.d/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/etc/udev/rules.d/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/etc/X11/xorg.conf.d/ /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/var/log/displaylink/
• pushd /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/src/evdi-1.7.0
  /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/src/evdi-1.7.0 /var/tmp/displayportecebwC/displaylink-1.7.0
• cp -a /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/Kconfig /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/LICENSE /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/Makefile /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/dkms.conf /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_connector.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_cursor.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_cursor.h /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_debug.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_debug.h /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_drm.h /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_drv.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_drv.h /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_encoder.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_fb.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_gem.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_i2c.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_i2c.h /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_ioc32.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_main.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_modeset.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_painter.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_params.c /var/tmp/displayportecebwC/displaylink-1.7.0/evdi-1.7.0/module/evdi_params.h .
• popd
  /var/tmp/displayportecebwC/displaylink-1.7.0
• cp -a evdi-1.7.0/library/libevdi.so.1.7.0 /var/tmp/displayportVFCZyu/displaylink-1.7.0-2.rawhide.20201103T083103Z.i386/usr/libexec/displaylink/
  cp: cannot stat 'evdi-1.7.0/library/libevdi.so.1.7.0': No such file or directory

There is another (maybe) unrelated issue. I can only install or erase the rpm with rpm, not with dnf.

[elguero]

Correct. EVDI 1.8 does not work with the currently released DisplayLink driver, 5.3.1.

Kernel 5.9 requires some patches to EVDI. We are waiting on upstream to merge into EVDI 1.7.

Please see: DisplayLink/evdi#225 and DisplayLink/evdi#228

PS: If you depend on DisplayLink, I would stick to the prior kernel 5.8 in Fedora 33 until this is resolved upstream.

[enriqueartal]

I cannot build the rpm even if I am in kernel 5.8, is it normal? In the log it seems that there is some mess between evdi 1.7 and 1.8.
Anyway, thanks for your advise, I will keep a 5.8 kernel.

[elguero]

If you are on Fedora 33, you can use the latest package released here. No need to compile a new RPM. Even though it says for Fedora 32, it works on Fedora 33 still.

To clean out anything left over which might be causing issues installing, check out this comment: #149 (comment)

In regards to compiling, the logs above does not show the command you used. If you did a simple 'make`, it should have worked. I just tested it using the latest from this repo.

[enriqueartal]

I do not understand the problem, it happens in two different computers. I tried both make and make rawhide, after a make clean. And just in case I clone the git repo in another directory.
Anyway, thanks for you work!

[sickcodes]

You can use 5.9.x with DisplayLink/evdi#228 😊

I wouldn't recommend staying on 5.8 but I also don't recommend using random PRs. Choice is yours, but the PR works good!

[elguero]

@sickcodes I referenced that issue in an earlier comment.

5.9 just came out at the beginning of this week. Unless there is a security reason requiring one to use the latest and greatest kernel on F33, I don't see why we can't wait a little bit.

The issue is that he is not being able to compile at all on 5.8 or 5.9. We are missing something in the order that we are doing things and I am not seeing it from the logs posted. I am just throwing out ideas to help. From what has been stated, he is getting a mix of the new code in the evdi repo that is under dev (1.8.x) and trying to use the code from this repo which is expecting to work with version 1.7.x. That is what I believe his issue is.

@enriqueartal I would run make clean-all. If you do not clean out everything, the Makefile will use files that have already been downloaded which might be what is causing your mix of evdi versions.

[sickcodes]

Correct, Arch users are using evdi 1.7, with my cherry pick, on 5.9 kernel.

1.8 doesn't work for anyone yet I believe

[enriqueartal]

Thanks for your indications. I was able to build and install the rpm with kernel 5.8 and with make. Trying make rawhide give the error of the first post.
I have just built the rpm with your cherry pick and the installation worked, the module being installed. I will check if everything works.
It is probably unrelated but I used to install this rpm using dnf. I am not sure if there is some change in Fedora 33, but it can be installed only using rpm.

[enriqueartal]

I checked only ethernet and usb and it works. I will check tomorrow vga and hdmi.

[enriqueartal]

I can confirm vga and hdmi also works. I need a reboot for vga to work, but this is not new, it happened with kernel 5.8. Thanks for your help and let me know if some more tests are needed.

[bclindner]

FYI, evdi released 1.7.1 officially today, which adds support for kernel 5.9 🎉

[GrzegorzBB]

Hi, someone was able to install package on Fedora 33 generated after evdi update? Currently dnf asks for following dependencies:

 Problem: conflicting requests
  - nothing provides kernel-ml >= 4.15 needed by displaylink-1.7.0-2.x86_64
  - nothing provides kernel-ml-devel >= 4.15 needed by displaylink-1.7.0-2.x86_64

Which should only be required for RHEL 7 according to 771ecb8

[elguero]

@GrzegorzBB Can you provide details on how you are trying to install?

1.7.1 has an issue that breaks our build here. We are skipping that release here since the agreement with the folks over in the evdi repo is to tag 1.7.2 when kernel 5.10 is released, which should be this weekend. We have been submitting some PRs to help with the next release.

Also, we have not updated things for the 1.7.2 yet. There was a PR for 1.7.2 which was just accepted, depending on where you live, overnight. Things are being ironed out in hopes of a release with kernel 5.9 and kernel 5.10 support by next week.

[GrzegorzBB]

@elguero I simply generated package from master using make without any changes. Before installation I removed old package, than I executed following command:

[grzegorz@vostro15 x86_64]$ sudo dnf localinstall displaylink-1.7.0-2.x86_64.rpm
Last metadata expiration check: 3:53:02 ago on Wed 09 Dec 2020 15:30:23 CET.
Error: 
 Problem: conflicting requests
  - nothing provides kernel-ml >= 4.15 needed by displaylink-1.7.0-2.x86_64
  - nothing provides kernel-ml-devel >= 4.15 needed by displaylink-1.7.0-2.x86_64
(try to add '--skip-broken' to skip uninstallable packages)

Thanks for explanation, fingers crossed ;).

[sickcodes]

@elguero 1.7.2 is not coming out because Derek put both fixes for 5.9 and 5.10 in 1.7.1 he stated

DisplayLink/evdi#237 (comment)

[elguero]

@sickcodes I think you misunderstood. The fix for 5.9 was put in v1.7.x and tagged as 1.7.1. Then the fix for 5.10 was put in v1.7.x which has not been tagged yet. There was an issue with the 1.7.1 tag. The module version was not set properly. That has been fixed and merged into v1.7.x branch.

That means that when 1.7.2 is tagged, it will have the fixes for 5.9, 5.10 and the proper module version (1.7.2) set.

[elguero]

@GrzegorzBB Thanks for the additional info. You pulled down latest code from master and there was an error in the logic of the spec file checking for RHEL distro and version.

Thanks for testing and reporting it.

[elguero]

New release has been created which should resolve this issue.