v1.7.0 cherry-pick abucodonosor's fix: Adjust to kernel 5.9

[sickcodes]

Cherry picked #227 for v1.7.0

Which is the branch we use on https://aur.archlinux.org/packages/displaylink/

Thank you @abucodonosor !

[sickcodes]

Tested @abucodonosor's fix for devel but for 1.7.0: #227

sudo pacman -R evdi-git #used -Rns
yay --getpkgbuild evdi-git
cd evdi-git
sed -i -e s/DisplayLink/sickcodes/g PKGBUILD
makepkg -si
sudo modprobe evdi
sudo systemctl disable displaylink.service
# removing 99-displaylink.rules is necessary for me
# sudo rm sudo /etc/udev/rules.d/99-displaylink.rules
reboot
sudo systemctl start displaylink

Tested on Targus USB 3.0 travel dock.
Tested on Lenovo USB 3.0 docking station.

[bnavigator]

This is great! Any plans to merge and release 1.7.1? Any word on when the new DisplayLink will be released and we can use 1.8.1 (with #227 merged)?

[bnavigator]

Which is the branch we use on https://aur.archlinux.org/packages/displaylink/

It's actually used on https://aur.archlinux.org/packages/evdi-git. You can use any (patched) evdi-1.7.0 with current displaylink.

[joren485]

Because of #225 (comment), this PR should probably be closed.

#227 will be merged into devel and devel will be merged into master to have one commit with the necessary changes instead of two on multiple branches (as I understand it).

[sickcodes]

Because of #225 (comment), this PR should probably be closed.

#227 will be merged into devel and devel will be merged into master to have one commit with the necessary changes instead of two on multiple branches (as I understand it).

It should but we need the 5.9 patch in the 1.8.x tag and the 1.7.x tag.

Devel is 1.8

https://github.com/DisplayLink/evdi/blob/devel/library/Makefile

Master is 1.7

https://github.com/DisplayLink/evdi/blob/master/library/Makefile

It has to be fixed in both, up to you guys though 😅

[bnavigator]

They should just merge #227 and release a new DisplayLink using evdi-1.8.1 with the new API.

After DisplayLink being sold to Synaptics, I developed hopes for a faster and more community friendly release policy. Those hopes have not been met so far.

[robotard]

Agreed with sickcodes...

I mean, it's not an issue, we can all backtrack to 5.8... Just leaves you without testers I guess?

No drama...
DLSupportTool_Output_2020-10-18T05:24:47.664267.zip

[bnavigator]

https://www.displaylink.org/forum/showthread.php?p=90855#post90855

I just tested this and can confirm it to be working on Linux Mint 20 (Ubuntu 20.04 base) w/ Kernel 5.9.1.

Thanks a lot.

[sickcodes]

Will this get merged or are you backporting #227 @displaylink-dkurek

[sickcodes]

Any updates? Should this be closed?

[RandieM]

Hello there!

Is this fix specific to Arch Linux? I am trying to install it on Fedora 33 with kernel version 5.9.8 and I get the following error (after running "make"):

CFLAGS="-Werror -Wextra -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializers" make -C module 
make[1]: Entering directory '/tmp/evdi/module'
make -C /lib/modules/5.9.8-200.fc33.x86_64/build M=$PWD
make[2]: Entering directory '/usr/src/kernels/5.9.8-200.fc33.x86_64'

  ERROR: Kernel configuration is invalid.
         include/generated/autoconf.h or include/config/auto.conf are missing.
         Run 'make oldconfig && make prepare' on kernel src to fix it.

make[2]: *** [Makefile:719: include/config/auto.conf] Error 1
make[2]: Leaving directory '/usr/src/kernels/5.9.8-200.fc33.x86_64'
make[1]: *** [Makefile:71: module] Error 2
make[1]: Leaving directory '/tmp/evdi/module'
make: *** [Makefile:13: all] Error 2

Is this a different issue or am I doing something wrong?

[bnavigator]

Hi,

The fix is not specific for Arch Linux. You may have seen the discussion about Ubuntu.

Your error message is not specific to this fix. Your build environment is not set up correctly. Do you have experience with rpm builds? Checkout https://github.com/displaylink-rpm/displaylink-rpm. It should take care of all the BuildRequirements you need.

Add the following lines to displaylink.spec.

• Patch0: https://github.com/DisplayLink/evdi/pull/228.patch#/displaylink-pr228.patch in the header
• %patch0 in the %prep section

Provide the file from that URL (without the #... part) as displaylink-pr228.patch and try to build the new package with make or rpmbuild.

In case of trouble, please open a discussion in displaylink-rpm. This PR is not the right place for this.

[bnavigator]

Note that there is a brand new discussion regarding this:
displaylink-rpm/displaylink-rpm#154

... and displaylink-rpm/displaylink-rpm@2ac08f5#commitcomment-44251308

[sickcodes]

Not gonna lie, people are running all sorts of configurations:

• vulnerable kernel 5.8 unable to use evdi 1.8 (useless dock, useless screen taking up desk space)
• vulnerable kernel 5.8 using evdi 1.7
• running 5.9 unable to use 1.8 (useless dock, useless screen taking up desk space)
• running 5.9 using custom patches for evdi 1.7 master

Getting very confusing, people are using all sorts of patches. What's wrong with applying the cherry-pick to the 6 month old master, which is the only one that works?

I don't fully get how the repo works since master doesn't work for anyone but all this PR does is do 1 backport.

v1.7.0.1? Is it time for a new branch 1.7?

[bnavigator]

I would just call it 1.7.1.

But obviously the people at DisplayLink only care about their released package for Ubuntu 😞.

Although there is some influx from users, who complain about DisplayLink not working with their system, this GitHub repo is not meant to be a source for the general community. And because the license is not FOSS, the burden is offloaded to community package maintainers for distros, who know how to deal with the publicly available sources. Arch/Manjaro have a working setup with the AUR packages for evdi and displaylink. openSUSE has my package from the build service (built on @stoecker's work), and the Redhat/Fedora family has displaylink-rpm, although @elguero refuses to apply the patch there and prefers to wait until pigs fly displaylink releases a patched evdi.

[abucodonosor]

@sickcodes @bnavigator

off-topic

Is any of you playing with 5.10rc kernels?

Maybe someone could test fix from: #234 (comment)

[sickcodes]

@sickcodes @bnavigator

off-topic

Is any of you playing with 5.10rc kernels?

Maybe someone could test fix from: #234 (comment)

Testing tonight! 😛

[robotard]

Not meaning to sound funny though... If you reply from the DisplayLink titled github, you're very likely to get people who's software has been broken asking for fixes...?

Thankfully, there appear to be people such as @sickcodes (thanks matey) actually trying to get something together that ultimately appears to get us all off our your backs... Not to mention, if we're all willing to be testers for the code drops here, isn't that not only the FOSS mentality, but strength in numbers...?

[bnavigator]

I think you are confused. I am neither speaking for DisplayLink nor do I want anyone get off my back. I would very much appreciate if DisplayLink would consider to support the community efforts outside of Ubuntu with greater enthusiasm. But sadly that is not the case.

[sickcodes]

Can someone kindly create a new branch v1.7.1

as I have moved this PR to a new branch, ready to be PR'ed again:
https://github.com/sickcodes/evdi/tree/v1.7.1

Similar to:
https://github.com/DisplayLink/evdi/tree/v1.6.3
https://github.com/DisplayLink/evdi/tree/v1.6.4

[bnavigator]

That's not how git works. You don't have to match branch names between remotes for PRs

[sickcodes]

I know, I've already created 1.7.0 on my master (this PR)

Need DisplayLink to create a new branch v1.7.1, so this PR gets closed, and then PR the new branch?

[bnavigator]

No. You could open a new PR from sickcodes/v1.7.1 to DisplayLink/master. You (and they) can even change the target branch late ron.

You just can't change your source branch for the existing PR. For that you have to open a new one. But please take into account that if you do than and then continue to work on your master branch all the links to https://github.com/DisplayLink/evdi/pull/228.patch, which we have been advertising will not deliver the original patch anymore.

A better option is to leave your own master as-is and do future work in a new branch until all of this mess has been resolved.

[sickcodes]

Thought that was what I did, have made a mistake, ignore my last two comments. Leaving this PR, as-is!

Testing the 5.10rc now via @abucodonosor

[sickcodes]

5.9.10 just came thru for arch so testing by default @abucodonosor

EDIT: it's not 5.10 soz will try get

[bnavigator]

Could you please discuss 5.10 in #234 or a new issue/PR? The title here says 5.9

[sickcodes]

Is this getting merged? We're almost at 5.10 kernel, would this mean DisplayLink has skipped official support for 5.9?

Unofficial dirty installation of unofficial evdi 1.7.1 for 5.9.x Kernel:

git clone git@github.com:sickcodes/evdi.git
cd evdi
git checkout -f master
make
sudo make install

You will have to manually uninstall evdi, only if 1.8 ever works.

EDIT: evdi 1.8 works on 5.10rc6 as seen in: #237, thank you @abucodonosor!

EDIT: evdi 1.7 works on 5.10rc6 as seen in: #237, thank you @abucodonosor!

[robotard]

With a lot of help from SicklCodes I've finally got my Displaylink working under 5.9.10...

I had previously followed the patch from post 2, but this did not appear to work... Among trying lots of different fixes, it seems that a patch from SickCodes' repo seemed to bring it all together...

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

It would be great if this could be included with the current DisplayLink offering

It also seems as though the displaylink-driver.service was not starting automatically., but was found to be present from typing 'systemctl status display' and tapping tab twice (without hitting enter).

You can then test whether it will start with 'sudo systemctl start displaylink-driver.service'

This worked for me to bring my additional 2 displays (1xHDMI and 1xDVI) from my DisplayLink adapter... I also had the HDMI straight from my Ryzen 7 laptop (with Nvidia MX350) working in parallel with the DVI from the DisplayLink alongside the laptop screen...

[displaylink-dkurek]

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 :)

[elguero]

@displaylink-dkurek Yes, that will be helpful. Any plans to make a tagged release from that branch? Over in displaylink-rpm, the build scripts use the tagged releases from this repo.

Thanks for your help.

[displaylink-dkurek]

Ah, I see, script is getting tar.gz... What if it would clone specific branch from repo?
I would wait with creating a new tag (v1.7.1 probably) until we actually have kernel 5.10 released.
Probability that something will change at this point is low but it's in rc mode.

[bnavigator]

Technically it doesn't matter if they use a tag or branch for the source of the tar.gz archive, they could fetch
https://github.com/DisplayLink/evdi/archive/v1.7.x.tar.gz

But AFAIK displaylink-rpm is very reluctant to ship "non-released" versions.

[bnavigator]

You could tag 85f3ec1 for kernel 5.9 support only. That one has been tested (as 1.7.0 + patch) on many systems. Release another version when kernel 5.10 is out.

[elguero]

Waiting until 5.10 is released to tag is fine.

Yes, that is an option. I cannot speak for the original authors of the displaylink-rpm project but in my experience, using tagged releases provides more stability than using branches if said branches are going to receive code changes.

Taking on the task of maintaining patches for someone else's project is not very desirable as a volunteer. @bnavigator is correct. The community is hesitant to take this on due to past experience in trying to do this. Usually, the project here has been pretty good about updating before any significant time passes in regards to breakage with kernel releases.

Right now, the whole v1.8.0 being released without a version of DisplayLink drivers that can work with it has thrown a wrench in the flow of things over in the displaylink-rpm project.

[displaylink-dkurek]

Good idea, thanks :)
v1.7.1 tag and release were made. Will get back to the tagging when kernel 5.10 will be released .

Also noticed that you can download a tar.gz from a specific commit, like
https://github.com/DisplayLink/evdi/archive/85f3ec152ac67a227123e0a383a091f9c340d796.tar.gz

[displaylink-dkurek]

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