Closed jasonriedy closed 2 years ago
I got it to build under 5.15, but I am soooo not qualified to properly fix it or debug if it actually works. Kinda need this to work on 5.15 (fixes some issues with my hardware)
Edit: I can confirm my evdi fork does indeed work on 5.15 :)
@infinytum:
I am running Slackware64-current. I tried building evdi-kernel under 5.15 and was not able to do so. The error message is the following: evdi-1.9.1/module/evdi_drm_drv.h:23:10: fatal error: drm/drm_irq.h: No such file or directory 23 | #include <drm/drm_irq.h>
What did you have to modify for it to build for you? I also downloaded the zip file from your evdi fork and still had the same issue
@infinytum:
I am running Slackware64-current. I tried building evdi-kernel under 5.15 and was not able to do so. The error message is the following: evdi-1.9.1/module/evdi_drm_drv.h:23:10: fatal error: drm/drm_irq.h: No such file or directory 23 | #include <drm/drm_irq.h>
What did you have to modify for it to build for you? I also downloaded the zip file from your evdi fork and still had the same issue
Are you sure you tried my repo? I removed that import from the file...
@infinytum:
Thank you for your guidance. Somehow, even though the files were in the tar.gz file, as you mentioned, the /tmp for the build was pulling the files from some other location and overwriting them. I copied the three files manually and evdi-kernel was able to build successfully
@FBobbioC Glad that worked out for you!
@infinytum Thanks for your repo, are you interested in other merges as well? Does seem the current developers don't really seem to care.
@infinytum Thanks for your repo, are you interested in other merges as well? Does seem the current developers don't really seem to care.
What merges would you have in mind?
@infinytum #315
However I still think they should do more about the performance issues everyone has when using this module.
@francoism90 Merged that PR into my repo.
Thank You everyone here! I just made fork package for arch users with kernel 5.15+ which use the @infinytum fork for source. https://github.com/aaronrancsik/evdi-arch
@aaronrancsik Awesome! Obligatory I use arch BTW, will take a look at it :)
@infinytum Would you be interested in merging this change: https://github.com/francoism90/evdi/commit/5be03ad88fa52e88cc47815fec3cb43730dcd10b
It seems to mostly fix the logging issues when using options evdi initial_loglevel=0
, they are still being reported elsewhere, but my knowledge about these kind of things is limited. I would like to remove my repo as I'm not a C developer. :)
@displaylink-emajewsk @displaylink-mlukaszek @displaylink-dkurek @lspintzyk Could we have these changes merged? Currently broken in Arch Linux.
Hi All, we are planning to refresh the branch here on GitHub and we are indeed planning to include key PRs - sorry for the delay, the team have been occupied with other work and could not pick this up earlier.
Hello, could you merge the patch soon ? All Arch users are blocked and need to use the fork of francoism90. Thanks
I can compile the Kernel for 5.14 and 5.15, but the Module doesn't work. My screens stay black.
@robmaster2016 Are you using Wayland or Xorg? It doesn't work for me at all on Xorg, but it does work fine on Wayland.
@francoism90 @robmaster2016 It does work for me. Build for linux 5.15.2. In x11 it works as expected, I created 20-evdo.conf as Arch Wiki says. On wayland on amd card when I disable one of the monitors (mine displaylink has two ports), then the screen goes black. When they are both enabled, then it works. To avoid phantom space, I just dragged that phantom monitor onto another one.
Edit: I just caught it. When hot plugged dl device in x11. When I cold plug it (boot with it already plugged in), then it works.
Hello @displaylink-mlukaszek, many thanks for your input regarding this. Do you have any estimation for when this could be available?
evdi is unfortunately not working for Linux 5.15 at the moment.
Can confirm it works with the latest Debian kernel upgrade (5.15.3)
It would be helpful to know the platform (CPU, graphic card) that does run the upgraded code.
There is only one real Debian platform (amd64) ;) Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
This is something that the team is actively working on. You should see PRs getting verification and getting landed, so evdi itself would let you be compatible with fresh kernels again soon. We are currently targeting to release a full driver update in December, this requires much more testing that just evdi.
@displaylink-mlukaszek Thanks for the update, I'm looking forward to the new improved evdi module. :)
@infinytum: I am running Slackware64-current. I tried building evdi-kernel under 5.15 and was not able to do so. The error message is the following: evdi-1.9.1/module/evdi_drm_drv.h:23:10: fatal error: drm/drm_irq.h: No such file or directory 23 | #include <drm/drm_irq.h> What did you have to modify for it to build for you? I also downloaded the zip file from your evdi fork and still had the same issue
Are you sure you tried my repo? I removed that import from the file...
infinytum@273fbb0#diff-c00b60aa62f1d5ca62e486eff56f6f9a22e5659f0fcd1731e8cf83c95c409bc7L23
This worked for me on kernel 5.15.4, Fedora 35. I hope new releases for Kernel 15+ are coming soon.
I ran into this on Ubuntu 21.10 Impish. I use https://github.com/AdnanHodzic/displaylink-debian to manage display link, which is basically a big shell script to run a bunch of commands I don't quite understand that gets all the kernel modules and systemd stuff in place.
For reference, this is what I did to get my monitors working again after updating to kernel 5.15.4.
displaylink-debian
script to uninstall everythingran displaylink-debian
to install the latest versions of evdi
and friends, reboot and plug the dock back in.
At this point, my docked keyboard/mouse work, but the monitors are blank. The displaylink-driver.service
systemd service is constantly restarting itself (can see that in /var/log/syslog
or running systemctl status displaylink-driver.service
). The service is trying to ensure the evdi
module is installed, and then if needed, runs dkms install evdi/1.9.1
. That dkms
is failing due to the drm_irq.h
problem this issue is about.
evdi
source code: sudo chown -R $USER /usr/src/evdi-1.9.1
edited those files to apply the changes mentioned earlier by @nilathedragon at https://github.com/nilathedragon/evdi/commit/273fbb0a67eca5f60fd2aaab0e25076dae4d8a3a#diff-c00b60aa62f1d5ca62e486eff56f6f9a22e5659f0fcd1731e8cf83c95c409bc7L23
At this point, the constant restarts of displaylink-driver.service
finally succeed in running dkms install evdi/1.9.1
, and the service is up and running. However, my monitors still didn't work.
/etc/X11/xorg.conf.d/20-displaylink.conf
, and reboot. This file was created by displaylink-debian
, and didn't do the right thing for me.If you're not using displaylink-debian
, then patching /usr/src/evdi-1.9.1
and running sudo dkms install evdi/1.9.1
might be sufficient.
So I use fedora 35 and for me the simplest solution is this:
Install the displaylink driver rpm from https://github.com/displaylink-rpm:
wget https://github.com/displaylink-rpm/displaylink-rpm/releases/download/v5.4.0-1/fedora-34-displaylink-1.9.1-1.x86_64.rpm
sudo dnf install ./fedora-34-displaylink-1.9.1-1.x86_64.rpm
(Maybe) Install the source files for the current kernels:
sudo dnf install kernel-devel
Clone the fork of evdi from nilathedragon:
git clone https://github.com/nilathedragon/evdi
Copy the contents of evdi/modules to /var/lib/dkms/evdi/1.9.1/source/
sudo cp -r ./evdi/module/* /var/lib/dkms/evdi/1.9.1/source/
Compile & Install the the new module manually for the first time:
sudo dkms autoinstall
With this steps, on each kernel upgrade the dkms autocompiles the module and you don't have to worry about the version magic error and because of the great work of nilathedragon, it also works on the newer kernels.
Please, please push this upstream in a meaningful way. This ish is ridiculous. Some OEM somewhere must be demanding this as well.
@jasonriedy I'm running evdi on Linux 5.15 using this repo. What are you missing?
Full integration with systems. The semi-automatic compatibility with internal API changes that comes with being in-kernel. Doing this dance just to use my monitors is ridiculous.
I am fully with you. Basically upon upgrading each new Linux kernel, the battle begins to bring the monitor(s) back again. I must say, I cannot recommend anyone to buy a device which requires this driver.
Sorry to break anyone's bubble, but real Linux users normally do not whine about doing some work. This package needs to be compiled and installed since it is not part of the kernel. I use three external monitors with the Dell D3000 USB 3.0 docking station and understand that the extra work needs to be done after any kernel upgrade
On 12/4/21 19:52, Olof wrote:
I am fully with you. Basically upon upgrading each new Linux kernel, the battle begins to bring the monitor(s) back again. I must say, I cannot recommend anyone to buy a device which requires this driver.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/DisplayLink/evdi/issues/308#issuecomment-986150417, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIKMHD5JOCV7OGRDPKDMMFDUPLAUDANCNFSM5D4JPXJQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Hello, I've been doing this "dance" the last 5 years and learned a bit about Kernel modules which I don't mind but can understand the frustration felt by others since it hasn't always been easy. I wanted to ask the group if there is any issue with the suggestion by @bprfh to benefit from the dkms autocompile. I've tested it with the recent 5.15.6 Kernel update and worked like charm.
@jasonriedy This is because evdi
isn't part of the Linux-kernel (yet).
It would indeed be better to have this merged upstream, so users don't have to worry about building this themselves with DKMS, etc.
For now, package managers can use the latest commit, hopefully they do release a stable version this month.
@jasonriedy Do you know if there are any plans to get this merged upstream? I would gladly like to help to get it done (but did not done it before).
It would be great if we got it merged in de kernel before the next longterm kernel which would be likely in the Debian Bookworm release.
@wvdakker We'd like nothing more than to be merged upstream. However, for various reasons, that doesn't seem to be in the cards in the near future.
Until then we officially support only Ubuntu LTS kernels.
@displaylink-emajewsk If you'd like nothing more than that, make it happen. Note that HDCP is in the kernel, so "security" isn't an excuse. I should not have purchased this dongle.
So from a casual outsider where does this sit? No support for any other kernel than Ubuntu LTS? I picked up a display link device and seeing the issue described trying to run on Pop!_OS 5.15.5-76051505-generic
So from a casual outsider where does this sit? No support for any other kernel than Ubuntu LTS? I picked up a display link device and seeing the issue described trying to run on Pop!_OS
5.15.5-76051505-generic
Yeah, I just happened to upgrade my System76 machine today as it was overdue and now my DisplayLink is also broken. I'm feeling like I need to just invest in a different dock and stay away from DisplayLink. And I'm not saying this is the DisplayLink developers fault.
At the end of the day I just need things to stay working.
@timnolte Have you tried my instructions? If it doesn't work, try checking out this repo with the devel branch and then do the same steps again
@bprfh I just don't have time right now as I have a lot of work to get done. This happened on my work machine and fortunately it had a built-in external monitor connection I could use to at least get me by for now.
Sorry to break anyone's bubble, but real Linux users normally do not whine about doing some work. This package needs to be compiled and installed since it is not part of the kernel. I use three external monitors with the Dell D3000 USB 3.0 docking station and understand that the extra work needs to be done after any kernel upgrade.
Such claims are the reason why Linux never made it as a mainstream Desktop system. My work requires me to actually "use" my computer for tasks that pay my bills. Fiddling around with displaylink stuff on every kernel upgrade does not pay my bills....
To be clear I did finally get it working with the adapter I had bought, but I had terrible ghosting on all my displays and just "broken" looking rendering. Sub-optimal at best and definitely not usable for day to day work. Will be returning the adapter unfortunately.
Took a chance hoping for the best, but it just didn't work out for my current setup.
Followed steps listed here in combination with displaylink-debian in case it helps anyone else.
To be clear I did finally get it working with the adapter I had bought, but I had terrible ghosting on all my displays and just "broken" looking rendering. Sub-optimal at best and definitely not usable for day to day work. Will be returning the adapter unfortunately.
Took a chance hoping for the best, but it just didn't work out for my current setup.
Followed steps listed here in combination with displaylink-debian in case it helps anyone else.
This did not do the trick for me. Now it is complaining about missing drm/drm-drv.h
In file included from /var/lib/dkms/evdi/1.9.1/build/evdi_platform_dev.c:30:
/var/lib/dkms/evdi/1.9.1/build/evdi_drm_drv.h:20:10: fatal error: drm/drm_drv.h: Aucun fichier ou dossier de ce type 20 | #include <drm/drm_drv.h>
Running Debian Sid with follwing kernel :
5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26) x86_64 GNU/Linux
displaylink-debian.sh downloads and extracts the contents of the official DisplayLink Ubuntu driver.
@chriscarpenter12 If this is correct (I cannot verify, not running Debian), this would overwrite the evdi files each time. When do you overwrite the files? Think @F4FXL keeps getting the old one.
Better would be DisplayLink just releasing a new evdi module.
If this is correct (I cannot verify, not running Debian), this would overwrite the evdi files each time. When do you overwrite the files?
After running dkms build evdi/1.9.1
the debian installer script seemed to detect it was already available ¯_(ツ)_/¯
Better would be DisplayLink just releasing a new evdi module.
Can't agree more. I was just trying to get something working.
I ran into this on Ubuntu 21.10 Impish. I use https://github.com/AdnanHodzic/displaylink-debian to manage display link, which is basically a big shell script to run a bunch of commands I don't quite understand that gets all the kernel modules and systemd stuff in place.
For reference, this is what I did to get my monitors working again after updating to kernel 5.15.4.
1. ran the `displaylink-debian` script to uninstall everything 2. reboot, unplug the dock 3. ran `displaylink-debian` to install the latest versions of `evdi` and friends, reboot and plug the dock back in. At this point, my docked keyboard/mouse work, but the monitors are blank. The `displaylink-driver.service` systemd service is constantly restarting itself (can see that in `/var/log/syslog` or running `systemctl status displaylink-driver.service`). The service is trying to ensure the `evdi` module is installed, and then if needed, runs `dkms install evdi/1.9.1`. That `dkms` is failing due to the `drm_irq.h` problem this issue is about. 4. gave myself permission to the `evdi` source code: `sudo chown -R $USER /usr/src/evdi-1.9.1` 5. edited those files to apply the changes mentioned earlier by @nilathedragon at [nilathedragon@273fbb0#diff-c00b60aa62f1d5ca62e486eff56f6f9a22e5659f0fcd1731e8cf83c95c409bc7L23](https://github.com/nilathedragon/evdi/commit/273fbb0a67eca5f60fd2aaab0e25076dae4d8a3a#diff-c00b60aa62f1d5ca62e486eff56f6f9a22e5659f0fcd1731e8cf83c95c409bc7L23) At this point, the constant restarts of `displaylink-driver.service` finally succeed in running `dkms install evdi/1.9.1`, and the service is up and running. However, my monitors still didn't work. 6. Remove `/etc/X11/xorg.conf.d/20-displaylink.conf`, and reboot. This file was created by `displaylink-debian`, and didn't do the right thing for me.
If you're not using
displaylink-debian
, then patching/usr/src/evdi-1.9.1
and runningsudo dkms install evdi/1.9.1
might be sufficient.
This worked for me! PopOS update broke my display, this was the 3rd fix I tried and it works perfectly so far :)
Pop!_OS 21.10 - 5.15.5-76051505-generic
@amija004 did you do all of those steps or just
If you're not using displaylink-debian, then patching /usr/src/evdi-1.9.1 and running sudo dkms install evdi/1.9.1 might be sufficient. On you Pop!_OS? I'm also on Pop!_OS, but using an actual System76 machine, so i don't really want to install a much that is not included and risk future update issues.
When I try to just patch the EVDI 1.9.1 source on my Pop!_OS 21.04 system(System76 hardware), and then run sudo dkms install evdi/1.9.1
I get an error the following error:
ERROR (dkms apport): kernel package linux-headers-5.15.5-76051505-generic is not supported
Error! Bad return status for module build on kernel: 5.15.5-76051505-generic (x86_64)
@wvdakker We'd like nothing more than to be merged upstream. However, for various reasons, that doesn't seem to be in the cards in the near future.
Until then we officially support only Ubuntu LTS kernels.
GA or HWE Kernel?
As a heads-up evdi cannot build on kernels at or beyond 5.15. Looks like drm_irq.h actually isn't used, but I don't know my ioctls well enough to poke at the compat_alloc_user_space() issue.
Really wish this were upstream. Really wish I had done the research to find the binary blob issue. sigh.