-
Notifications
You must be signed in to change notification settings - Fork 184
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
v1.7.0 cherry-pick abucodonosor's fix: Adjust to kernel 5.9 #228
Conversation
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. |
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)? |
It's actually used on https://aur.archlinux.org/packages/evdi-git. You can use any (patched) evdi-1.7.0 with current displaylink. |
Because of #225 (comment), this PR should probably be closed. #227 will be merged into |
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 😅 |
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. |
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... |
https://www.displaylink.org/forum/showthread.php?p=90855#post90855
|
Will this get merged or are you backporting #227 @displaylink-dkurek |
Any updates? Should this be closed? |
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"):
Is this a different issue or am I doing something wrong? |
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.
Provide the file from that URL (without the #... part) as In case of trouble, please open a discussion in displaylink-rpm. This PR is not the right place for this. |
Note that there is a brand new discussion regarding this: ... and displaylink-rpm/displaylink-rpm@2ac08f5#commitcomment-44251308 |
Not gonna lie, people are running all sorts of configurations:
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? |
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 |
off-topic Is any of you playing with 5.10rc kernels? Maybe someone could test fix from: #234 (comment) |
Testing tonight! 😛 |
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...? |
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. |
Can someone kindly create a new branch
|
That's not how git works. You don't have to match branch names between remotes for PRs |
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? |
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. |
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 |
5.9.10 just came thru for arch so testing by default @abucodonosor EDIT: it's not 5.10 soz will try get |
Could you please discuss 5.10 in #234 or a new issue/PR? The title here says 5.9 |
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.7 works on 5.10rc6 as seen in: #237, thank you @abucodonosor! |
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 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... |
OK, so I've just pushed new branch |
@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. |
Ah, I see, script is getting tar.gz... What if it would clone specific branch from repo? |
Technically it doesn't matter if they use a tag or branch for the source of the tar.gz archive, they could fetch But AFAIK displaylink-rpm is very reluctant to ship "non-released" versions. |
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. |
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. |
Good idea, thanks :) Also noticed that you can download a |
OK, with all of this I will close the PR. Thanks all for your involvement and comments :) |
Cherry picked #227 for v1.7.0
Which is the branch we use on https://aur.archlinux.org/packages/displaylink/
Thank you @abucodonosor !