Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Kernel 5.9 breaks DisplayLink #225

Closed
robotard opened this issue Oct 13, 2020 · 75 comments
Closed

Kernel 5.9 breaks DisplayLink #225

robotard opened this issue Oct 13, 2020 · 75 comments
Labels
bug

Comments

@robotard
Copy link

Initially please make sure the problem hasn't been already addressed:

Some information for baseline would help a lot:

  • Linux distribution and its version
  • Linux kernel version
  • Xorg version (if used)
  • Desktop environment in use

Please provide good title for the issue and description.
If you can give us logs they will be welcome but please don't paste long listings
as they will make it hard to read the thread, instead you can use other services
for sharing raw text like pastebin or gist.
Also anything that may help to understand the problem will be appreciated
(configuration files, screenshots, photos, video capturing the problem).

Thanks!
@abucodonosor
Copy link
Contributor

If you wish I have a testing patch, untested since I don't have any HW to test right now and will only work with a 5.9 kernel.

Patch against latest release:

https://crazy.dev.frugalware.org/evdi-kernel-5.9-test.patch

@robotard
Copy link
Author

robotard commented Oct 13, 2020 via email

@robotard
Copy link
Author

robotard commented Oct 13, 2020 via email

@abucodonosor
Copy link
Contributor

@robotard

It is a bit more than a one-liner:).

The Intel workaround is now somewhat strange but it should, in theory, work like this.

@robotard
Copy link
Author

robotard commented Oct 14, 2020 via email

@displaylink-dkurek
Copy link
Contributor

@robotard
Try with patch -Np1 instead of patch

@abucodonosor
You are delivering great patches, as always 👍, thanks :)
Are you interested in creating PR? :)

I've just checked it with evdi master and v1.7.0 tag - compiles fine.

Note: For usage with DisplayLinkManager 5.3.1 please apply it on
top of tag v1.7.0 (in v1.8.0 there was API change).

Something like this should work:

# get sources
git clone https://github.com/DisplayLink/evdi.git
cd evdi
git checkout v1.7.0

# patch
curl https://crazy.dev.frugalware.org/evdi-kernel-5.9-test.patch | patch -Np1

# install
make
sudo make install

# reboot

@abucodonosor
Copy link
Contributor

@displaylink-dkurek

I can do an PR.

What is the rule now regarding #ifdef's for kernels?

#if KERNEL_VERSION(X, X, X) <= LINUX_VERSION_CODE
  throw in new code
#else ....

IOW, newest changes first in form of <= ?

@displaylink-dkurek
Copy link
Contributor

Yes, exactly. Please use only KERNEL_VERSION(X, Y, Z) <= LINUX_VERSION_CODE format, newest top.
Thanks!

@abucodonosor
Copy link
Contributor

@displaylink-dkurek

Ok done.

#227

@sickcodes
Copy link
Contributor

Works for the 1.7.0 tag too, thanks @abucodonosor & @displaylink-dkurek!

#228

Master was 1 ahead of 1.7.0 tag which worked for me too, any reason why tag was one behind, @displaylink-dkurek?

@robotard
Copy link
Author

Unfortunately no bueno for me

@robotard
Try with patch -Np1 instead of patch

@abucodonosor
You are delivering great patches, as always , thanks :)
Are you interested in creating PR? :)

I've just checked it with evdi master and v1.7.0 tag - compiles fine.

Note: For usage with DisplayLinkManager 5.3.1 please apply it on
top of tag v1.7.0 (in v1.8.0 there was API change).

Something like this should work:

# get sources
git clone https://github.com/DisplayLink/evdi.git
cd evdi
git checkout v1.7.0

# patch
curl https://crazy.dev.frugalware.org/evdi-kernel-5.9-test.patch | patch -Np1

# install
make
sudo make install

# reboot

Thanks again for another swift response :)

Unfortunately no bueno for me here... I dis mention that I'm a Groovy Gorilla (20.10) too right? Here's my kernel info:
uname -a Linux robstas-um433iq 5.9.0-050900-generic #202010112230 SMP Sun Oct 11 22:34:01 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I've attached the DLSupportTool output for your perusal too, and am more than happy to do any testing you need for both this fix, and anything that I may be able to help with in the future... Am usually close to latest Ubuntu/Kernel versions too :)
DLSupportTool_Output_2020-10-15T07:16:25.723360.zip

@sickcodes
Copy link
Contributor

sickcodes commented Oct 15, 2020 •
edited

Working on 5.9 with 1.7.0, love you @abucodonosor

git clone https://github.com/DisplayLink/evdi
cd evdi
git checkout -f master
git remote add abucodonosor https://github.com/abucodonosor/evdi.git
git fetch --all
git cherry-pick abucodonosor/issue-225 --no-commit
make

Or

git clone https://github.com/sickcodes/evdi
git checkout -f master
cd evdi
make

@displaylink-dkurek
Copy link
Contributor

@sickcodes
Tag v1.7.0 is made on devel branch, and then devel is merged to master. So master has one extra 'merge' commit on it.
This is made this way so tagged version is the same commit as we are shipping with DisplayLinkManager.

@bnavigator bnavigator mentioned this issue Oct 15, 2020
Merged
@PathosEthosLogos
Copy link

Working on 5.9 with 1.7.0, love you @abucodonosor

git clone https://github.com/DisplayLink/evdi
cd evdi
git remote add abucodonosor https://github.com/abucodonosor/evdi.git
git fetch --all
git cherry-pick abucodonosor/issue-225 --no-commit
make

Or

git clone https://github.com/sickcodes/evdi
cd evdi
make

I tried both of these methods and it gives me error 2.

cat: /etc/redhat-release: No such file or directory
CFLAGS="-Werror -Wextra -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializers" make -C module
make -C /lib/modules/5.8.11-1-MANJARO/build M=$PWD
make[2]: Entering directory '/usr/lib/modules/5.8.11-1-MANJARO/build'
make[2]: *** No targets specified and no makefile found.  Stop.
make[2]: Leaving directory '/usr/lib/modules/5.8.11-1-MANJARO/build'
make[1]: *** [Makefile:71: module] Error 2
make: *** [Makefile:13: all] Error 2

I also tried the code block in the comments of https://aur.archlinux.org/packages/displaylink but even the first line sudo pacman -R evdi-git #used -Rns does not seem to work, saying that evdi-git is not found.

@abucodonosor
Copy link
Contributor

@PathosEthosLogos

there is something wrong with your kernel source. You are also compiling against 5.8.11, while that should work just fine with the patch, it should work the same without. The patch only adjusts some API changes for the 5.9 kernel.

@bnavigator
Copy link

I also tried the code block in the comments of https://aur.archlinux.org/packages/displaylink but even the first line sudo pacman -R evdi-git #used -Rns does not seem to work, saying that evdi-git is not found.

If you haven't installed evdi-git you don't need to uninstall it.

@PathosEthosLogos
Copy link

Yeah I tried installing evdi-git as well, but that didn't work.

I think I'll just install 5.9 kernel. Hopefully other things won't break and hopefully this will work.

@bnavigator
Copy link

bnavigator commented Oct 15, 2020 •
edited

@PathosEthosLogos, do you understand the commands you are trying to execute? Because if not, please stay away from any AUR package, because you are exposing yourself to a big security risk.

@sickcodes' code block does this:

  • sudo pacman -R evdi-git remove a previously installed evdi-git. If you don't have it don't execute this line. As an Archlinux user, you should learn how to operate pacman. This line is also not necessary. You are just about to build a new evdi-git package which can replace the old installed one.
  • yay --getpkgbuild evdi-git Get the build recipe.
  • sed -i -e s/DisplayLink/sickcodes/g PKGBUILD replace the source repository from DisplayLinkt to @sickcodes' one. Big security risk if you can't trust @sickcodes and did not check the current contents of @sickcodes' master branch. (Note for the intermediate user: Better apply the patch from v1.7.0 cherry-pick abucodonosor's fix: Adjust to kernel 5.9 #228, which you checked yourself.)
  • makepkg -s build the recipe. Basically the Archlinux version of your failed make tries above. It will make sure you have dkms installed. Also make sure to install the correct linux-headers for your kernel (Listed as optional requirements with pacman -Qi dkms).

Note: I do not say, you can't trust @sickcodes, but he is a random person on the internet as anyone else here is.

@abucodonosor
Copy link
Contributor

@bnavigator

Well, you are right but one can compare the fork and the original online even, right now no difference.

@sickcodes

I think you forgot to push something out in your fork? :)

@bnavigator
Copy link

@bnavigator

Well, you are right but one can compare the fork and the original online even, right now no difference.

Yes, of course. master...sickcodes:master is the same as just examining https://github.com/DisplayLink/evdi/pull/228/files. But if you just replace the repo in the PKGBUILD and don't look at anything, this is dangerous.

@sickcodes

I think you forgot to push something out in your fork? :)

?
It's all there, otherwise no PR would have been possible.

@sickcodes
Copy link
Contributor

I forgot to insert the malware 🤪

@PathosEthosLogos
Copy link

Haha yeah, I knew all except sed.

But it seems like updating to 5.9 kernel didn't fix it. Same 'Error 2' with some additions.

cat: /etc/redhat-release: No such file or directory
CFLAGS="-Werror -Wextra -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializers" make -C module 
make -C /lib/modules/5.9.0-1-MANJARO/build M=$PWD
make[2]: Entering directory '/usr/lib/modules/5.9.0-1-MANJARO/build'
  AR      ~/evdi/module/built-in.a
  CC [M]  ~/evdi/module/evdi_drv.o
/home/pathos/evdi/module/evdi_drv.c:94:3: error: 'struct drm_driver' has no member named 'gem_free_object'; did you mean 'gem_open_object'?
   94 |  .gem_free_object = evdi_gem_free_object,
      |   ^~~~~~~~~~~~~~~
      |   gem_open_object
/home/pathos/evdi/module/evdi_drv.c:94:21: error: initialization of 'void (*)(struct drm_device *)' from incompatible pointer type 'void (*)(struct drm_gem_object *)' [-Werror=incompatible-pointer-types]
   94 |  .gem_free_object = evdi_gem_free_object,
      |                     ^~~~~~~~~~~~~~~~~~~~
/home/pathos/evdi/module/evdi_drv.c:94:21: note: (near initialization for 'driver.lastclose')
/home/pathos/evdi/module/evdi_drv.c: In function 'evdi_platform_probe':
/home/pathos/evdi/module/evdi_drv.c:175:20: error: 'struct dev_archdata' has no member named 'iommu'
  175 |  pdev->dev.archdata.iommu = INTEL_IOMMU_DUMMY_DOMAIN;
      |                    ^
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:283: /home/pathos/evdi/module/evdi_drv.o] Error 1
make[2]: Leaving directory '/usr/lib/modules/5.9.0-1-MANJARO/build'
make[1]: *** [Makefile:71: module] Error 2
make: *** [Makefile:13: all] Error 2

@sickcodes
Copy link
Contributor

You haven't cherry-picked @abucodonosor's changes yet you're building the DisplayLink/master

@abucodonosor
Copy link
Contributor

I forgot to insert the malware

No, you forgot devel is the default branch. so one need to clone your fork and checkout master :)

@abucodonosor
Copy link
Contributor

@sickcodes

git clone https://github.com/sickcodes/evdi

will clone devel branch, your patch pulled from me doesn't exist in devel so make will fail on a 5.9 kernel:)

@abucodonosor
Copy link
Contributor

@PathosEthosLogos

That error is now different you are missing my patch :)

@sickcodes
Copy link
Contributor

Yeah you're right, need to checkout master first. The AUR PKGBUILD from @bnavigator checks out master so I am missing that in my above comment.

I was supposed to commit to devel tag 1.7.0?

@bnavigator
Copy link

bnavigator commented Oct 15, 2020 •
edited

I was supposed to commit to devel tag 1.7.0?

No, master is correct. There is no 1.7.0 branch.

@joren485 joren485 mentioned this issue Oct 18, 2020
Closed
@bnavigator
Copy link

sudo mv sudo /etc/udev/rules.d/99-displaylink.rules .

Looks wrong. Use

    sudo rm /etc/udev/rules.d/99-displaylink.rules

or

    sudo mv /etc/udev/rules.d/99-displaylink.rules /root/99-displaylink.rules.bak

@sickcodes
Copy link
Contributor

sudo mv sudo /etc/udev/rules.d/99-displaylink.rules .

Looks wrong. Use

    sudo rm /etc/udev/rules.d/99-displaylink.rules

or

    sudo mv /etc/udev/rules.d/99-displaylink.rules /root/99-displaylink.rules.bak

Same effect really, I moved it to current directory to have a look at it 🙃

@bnavigator

This comment has been minimized.

Sign in to view
@bnavigator
Copy link

Here are my
DLSupport logs...

I see no logs. As I said, I did not test the instructions. Are you sure the patched evdi is being compiled and installed?

Also, did you consult https://support.displaylink.com/knowledgebase/topics/103927-troubleshooting-ubuntu ?

@abucodonosor
Copy link
Contributor

@bnavigator @sickcodes

This is not the place to teach people how to do basic packaging tasks for random distributions.

This is getting ridiculous, seriously.

@robotard
Copy link
Author

robotard commented Oct 19, 2020 via email

@robotard
Copy link
Author

robotard commented Oct 19, 2020 via email

@bnavigator
Copy link

People have repeatedly told you, there are no logs attached. Please check the GitHub issue page and clean your posts. The e-mail reply feature of Github apparently does not support attachments.

The fact that you don't have a udev rule, indicates you did either not run displaylink-installer.sh properly or you messed with your installation afterwards, by entering commands, which you don't understand.

In any case, my patience is almost exhausted. Perhaps you should try to fix your system with the help of people over at the Ubuntu user forums instead of insulting people here. Maybe @abucodonosor is right, despite Ubuntu being the only "officially" supported distribution by DisplayLink.

@bnavigator
Copy link

BTW, the official displaylink-installer.sh installs the systemd service as displaylink-driver.service. I am not sure what disabling and manually starting the service achieves (I do not need such a workaround on my system), but here is @sickcodes' code adjusted for that:

Disable DisplayLink service

sudo modprobe evdi
sudo systemctl disable displaylink-driver.service
# removing 99-displaylink.rules is necessary for me
sudo mv /etc/udev/rules.d/99-displaylink.rules /root/99-displaylink.rules.bak
reboot

And then start X, xfce etc.

When you're inside the desktop run:

sudo systemctl start displaylink-driver

@sickcodes
Copy link
Contributor

Here's my 2¢ for anyone lurking:

DisplayLink only works on kernel <=5.8 kernel with evdi 1.7.

Evdi 1.7 is also known as evdi master because evdi 1.8 doesn't work for anyone yet, which is why there are 2 pull requests: one to fix evdi 1.8 by @abucodonosor and one to fix evdi 1.8, cherry picked by me from @abucodonosor.

If you want test your DisplayLink device to work on Linux Kernel >=5.9 then you need to cherry pick @abucodonosor's perfect fix onto the master branch as seen in:
#227

But the kicker is, evdi MUST be on 1.7, hence:
#228

To test @abucodonosor's fix, Ubuntu/Debian/Arch/Manjaro/Fedora/RHEL/CentOS/Pop users would only need to force install DisplayLink, then manually install evdi 1.7 from my PR.

Xorg 1.20.9 MAY crash without deleting the udev rule as specified above.

In which case, try removing the udev rule as indicated above and disabling DisplayLink systemd service, and adding DisplayLink service to start AFTER your desktop loads.

Arch users should use https://aur.archlinux.org/packages/evdi-1.7/ from @bnavigator.

I think DisplayLink may benefit from a PPA or a custom APT sources repository (like Spotify sources https://www.spotify.com/us/download/linux/) instead of a shell script installer.

@sickcodes
Copy link
Contributor

Nobody can test 1.8 devel branch, they can only build it, hence why we are all hacking each respective distro's installer to test @abucodonosor fantastic fix on 1.7

@bnavigator
Copy link

To test @abucodonosor's fix, Ubuntu/Debian/Arch/Manjaro/Fedora/RHEL/CentOS/Pop users would only need to force install DisplayLink, then manually install evdi 1.7 from my PR

But that installs the unpatched evdi first. How are you gonna make sure users correctly replace the evdi afterwards?

Not to mention that DKMS has to recompile the evdi kernel module.

I think DisplayLink may benefit from a PPA or a custom APT sources repository (like Spotify sources https://www.spotify.com/us/download/linux/) instead of a shell script installer.

.. which also would be outdated until some developer there would bother to merge the patches and release a new package.

DisplayLink should really make it possible for distributions to include a proper package into their official repositories. But this requires DisplayLinkManager to be open-sourced.

@bnavigator
Copy link

bnavigator commented Oct 19, 2020 •
edited

In which case, try removing the udev rule as indicated above and disabling DisplayLink systemd service, and adding DisplayLink service to start AFTER your desktop loads.

Depends on your dm. The original systemd service unit has After=display-manager.service to take care of that. If you start X differently, you have to adjust, obviously.

@bnavigator bnavigator mentioned this issue Oct 19, 2020
Closed
@bnavigator
Copy link

bnavigator commented Oct 19, 2020 •
edited

@robotard In reply to your logs in #228 (comment)

machine_info.txt

EVDI kernel module version: None

What is the output of sudo dkms status? I guess lsmod | grep evdi is empty? Likely, you did not compile the kernel module. Or rather DKMS did not do it. Did you check the output during the installer for relevant information? Did you finally consult https://support.displaylink.com/knowledgebase/topics/103927-troubleshooting-ubuntu and also https://github.com/AdnanHodzic/displaylink-debian/blob/master/post-install-guide.md?

Here is another resource, with which you should compare the output you get on your system:
https://support.displaylink.com/knowledgebase/articles/684649-how-to-install-displaylink-software-on-legacy-ubun

sudo ./displaylink-driver-xxxxx.run

And your dmesg.txt is empty, probably because you didn't run with enough privileges.

@bnavigator
Copy link

Ubuntu related problems should probably go here https://www.displaylink.org/forum/showthread.php?t=67372 or any other suitable Ubuntu support forum

@robotard
Copy link
Author

robotard commented Oct 25, 2020 via email

@bnavigator
Copy link

I had a nasty accident recently that's put me out for over a week...

Sorry to hear that. Please focus on your recovery rather than on a silly experimental software problem on the internet.

From looking back through terminal, it looks as though I didn't sudo the DLSupportTool, so have reattached here...

You maybe did that in your mail client, but they do not appear on the Github page and the attachment is not sent to anybody. Yet Again. But it will be useless anyway until you resolve the already identified issues.

I've tried the following as above
sudo dkms list
...
Error! No action was specified.

Again, please check the Github issue page directly and stop replying by e-mail. I had noticed my mistake and corrected my comment immediately after I posted it. You likely did not get that by mail notification. The correct command is dkms status

You were also correct with lsmod | grep evdi running correctly but returning nothing...

So the install or module load was not successful.

Not going to lie, my injury entailed a cracked rib, and a blow to the head, so if you may kindly run me through the steps that are required to get latest DisplayLink, evdi, then exchange the evdi in once more, I'd be extremely grateful, and also very happy to test... Thanks for all the help so far..

Please read the comments in this thread directly on the Github page. Some posts were updated and should contain what you need to get started. For everything else, please refer to the linked forums. The Github issue page is not the right place for this. The patch has been tested by enough people and has been merged. We are just waiting on the release by the Displaylink guys.

@robotard
Copy link
Author

sudo dkms status
bbswitch, 0.8, 5.8.0-23-generic, x86_64: installed
bbswitch, 0.8, 5.8.0-25-generic, x86_64: installed
bbswitch, 0.8, 5.8.12-050812-generic, x86_64: installed
bbswitch, 0.8, 5.8.13-050813-generic, x86_64: installed
bbswitch, 0.8, 5.8.14-050814-generic, x86_64: installed
bbswitch, 0.8, 5.8.16-050816-generic, x86_64: installed
bbswitch, 0.8, 5.9.0-050900-generic, x86_64: installed
evdi, 1.7.0, 5.9.0-050900-generic, x86_64: installed
nvidia, 455.28, 5.8.0-23-generic, x86_64: installed
nvidia, 455.28, 5.8.0-25-generic, x86_64: installed
nvidia, 455.28, 5.8.14-050814-generic, x86_64: installed
nvidia, 455.28, 5.8.16-050816-generic, x86_64: installed
nvidia, 455.28, 5.9.0-050900-generic, x86_64: installed

Pulled all as described above, and replying to you directly from GitHub....

FWIW, I had to sudo ./displaylink-installer.sh uninstall then sudo ./displaylink-installer.sh install (see attached).

Also, I'm not sure I follow what you mean regarding the other issues (227 + 228)?

Am I missing the fleetingly obvious? Seemed to build into DKMS ok... ?

DisplayLink Un-Inst.txt
DLSupportTool_Output_2020-10-28T01:08:54.479783.zip

@joren485
Copy link
Contributor

@robotard Could you please move your support questions to the support forum?

People are following this issue to stay up to date with the status of this problem.

@bnavigator
Copy link

This looks much better now.

There is no proof, that you patched the evdi module, but if it is the case, then you can seek help with these logs on the mentioned forums. You can also post a bugreport on https://bugs.launchpad.net/ubuntu/

Please don't use this issue page here. Your problems are not directly connected with Kernel 5.9

@elguero elguero mentioned this issue Oct 28, 2020
Closed
@robotard
Copy link
Author

robotard commented Nov 2, 2020 via email

@elguero elguero mentioned this issue Nov 16, 2020
Closed
@displaylink-dkurek
Copy link
Contributor

OK, so I've just pushed new branch v1.7.x which is basically v1.7.0 with cherry-picked changes for kernel 5.9 and 5.10.
Hope it is fine :)

@displaylink-dkurek
Copy link
Contributor

OK, with all of this i will close the issue. Thanks all for your involvement and comments :)

@mknw
Copy link

mknw commented Jan 1, 2021 •
edited

It took me a couple hours to understand how to apply the latest changes to DisplayLink for Ubuntu.
Since this seems to be the main thread of reference for incompatibility issues with kernel versions 5.9/10, I think it makes sense to paste here the instructions. I believe the issue isn't about a specific distro, although Arch is mentioned more often.

  1. Download the DisplayLink driver from the official download page. Then run the following commands:

    unzip 'DisplayLink USB Graphics Software for Ubuntu 5.3.1.zip'
    chmod +x displaylink-driver-5.3.1.34.run
    ./displaylink-driver-5.3.1.34.run --noexec --keep

  2. Get the updated evdi version by typing:

    git clone https://github.com/DisplayLink/evdi.git
    cd evdi
    git checkout v1.7.x
    tar cf evdi.tar.gz *
    cp evdi.tar.gz ../displaylink-driver-5.3.1.34

  3. Install displaylink:

    cd ../displaylink-driver-5.3.1.34
    sudo ./displaylink-installer.sh install

This has also been reported here.
If this issue isn't the right place to share this: sorry. But if so, please let me know where else I can share it. Happy new year!

@mknw mknw mentioned this issue Jan 4, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@dummys @robotard @bnavigator @joren485 @PathosEthosLogos @abucodonosor @mknw @displaylink-dkurek @sickcodes