search

DisplayLink / evdi

Extensible Virtual Display Interface
MIT License
689 stars 179 forks source link

displays not detected on linux 6.2 + evdi 1.12 or 1.13 #406

Closed mrTsjolder closed 1 year ago

mrTsjolder commented 1 year ago

I had a running system with linux 5.18 (I think) and evdi 1.12.0 and recently decided to update my system again (yes, I do not update regularly anymore, because typically there would be issues with evdi so that I lose my monitors). I updated my system to 6.2.2 and applied the patches in #401 to evdi 1.12.0 to get evdi running. Although most peripherals of the docking station are working, none of my monitors show up. I also tried the recently published 1.13.0 code, but I do not manage to get my monitors working anymore.

Things that I have tried (with evdi 1.13.0):

However, no matter what I try, nothing appears in the logs (no monitors, but also no errors).

Is it possible that the 1.13.0 release requires a displaylink manager update again?

ynnckvdv commented 1 year ago

Only thing that I could find is this is the latest comment here: https://aur.archlinux.org/packages/evdi-git Nothing more. Having issues regarding this as well.

TheFattestUnicorn commented 1 year ago

Same here, did exactly the same on a Lenovo 40AF docking station. Everything is recognised except Displays. Have to wait for a fix, or go back to kernel 5.15.

displaylink-emajewsk commented 1 year ago

Is it possible that the 1.13.0 release requires a displaylink manager update again?

Yes. DisplayLinkManager checks if the correct major and minor version of the evdi module is loaded. Only the patch part may differ. Because of this, compiling devel won't always work.

bastoune commented 1 year ago

We pay for this dock and we cannot use it. @displaylink-emajewsk please tell us when it will work on linux kernel 6 ?

mrTsjolder commented 1 year ago

@displaylink-emajewsk In that case, would it be possible to make a 1.12.1 release that incorporates the changes required to make things work on linux 6?

As a general path forward: have you ever considered adopting semantic versioning? It would really be nice if evdi could have more frequent updates (e.g. for every breaking change in the kernel) than the DisplayLinkManager. In return for those frequent updates, the community could help report/resolve bugs more quickly for newer kernels.

displaylink-emajewsk commented 1 year ago

We pay for this dock and we cannot use it. please tell us when it will work on linux kernel 6 ?

@bastoune Arch Linux isn't officially supported. I am sorry. Only Ubuntu LTS kernels are. We're trying to support the newest kernels in a timely manner, but there are a bunch of factors at play outside of our control.

In that case, would it be possible to make a 1.12.1 release that incorporates the changes required to make things work on linux 6?

@mrTsjolder Technically, you could run ci/set_version 1 12 1 from the Evdi repo (current devel). Then install both libevdi and evdi kernel module. I've just tried it with the released DLM 5.6.1 and it works on my test machine, but your mileage may vary.

As a general path forward: have you ever considered adopting semantic versioning?

We were actually supposed to follow semver from the start, if we are to trust evdi documentation. I have raised this issue before, and unfortunately the upcoming release still works like that, but hopefully future versions will comply to semver.

It would really be nice if evdi could have more frequent updates (e.g. for every breaking change in the kernel) than the DisplayLinkManager.

I agree.

mrTsjolder commented 1 year ago

@displaylink-emajewsk I tried the same stuff I tried with evdi 1.13.0 with your suggested 1.12.1 release. Still, my displays do not show up (everything else works as expected).

As I mentioned, I do not get any errors. I included a recording of the kernel buffer when I plug in the USB of my docking station (i.e. output of dmesg -W). Maybe someone is able to spot something that can help with debugging.

The evdi messages in the kernel buffer are

[    5.757886] evdi: [I] Initialising logging on level 4
[    5.757889] evdi: [I] Atomic driver: yes

PS: I can try increasing the logging level if that would be helpful (and if you tell me how to do that).

evdi_logs.txt

djallits commented 1 year ago

Hi @displaylink-emajewsk

Whoever plays the role of product owner/manager for DisplayLink from Synaptics, I am assuming, is also the same person for EVDI. I acknowledge that the Linux Community pales compared to your macOS and Windows user base, but there is still a substantial market here. Does any feedback from the community represented here make it in front of their eyes?

The DisplayLink team takes some abuse from time to time, from me included, usually around the time there are Linux Kernel updates, so I want to thank you for always being even-keeled and offering a bit of transparency to us here.

VitoFe commented 1 year ago

It would really be nice if evdi could have more frequent updates (e.g. for every breaking change in the kernel) than the DisplayLinkManager.

I agree.

Wouldn't it be easier and more streamlined if the whole driver was open sourced and shipped in the kernel? It would not break for each kernel release and updates would be more frequent and community driven.

SamSpiri commented 1 year ago

New linux kernels is no surprise for everyone except here :D

olof-nord commented 1 year ago

Hello @mrTsjolder, if you haven't tried it already, you might want to try out evdi-compat-git by varungarg from the AUR. Saying this as you listed Arch Linux as your OS in the description. That package worked for me, it uses a fork of evdi repo that is on 1.12 and has the Linux 6.x patch.

flowrange commented 1 year ago

I can confirm that @olof-nord's solution works on Arch Linux with kernel 6.2.6 :+1:

mrTsjolder commented 1 year ago

Turns out that I installed (and re-installed) the 5.6-1 release of the displaylink package (in the AUR) instead of the 5.6.1-3 release. Installing the correct displaylinkmanager resolved my issues.

The solution proposed by @displaylink-emajewsk worked without a problem. Is there any reason why there could not be an official 1.12.1 release?

SimonSchwendele commented 1 year ago

Turns out that I installed (and re-installed) the 5.6-1 release of the displaylink package (in the AUR) instead of the 5.6.1-3 release. Installing the correct displaylinkmanager resolved my issues.

The solution proposed by @displaylink-emajewsk worked without a problem. Is there any reason why there could not be an official 1.12.1 release?

Breaking changes bump evdi to 1.13.0. They're apparently waiting for the displaylink release to be "ready"

gringus commented 1 year ago

Alternatively you can lower minor version in library/evdi_lib.h and rebuild to workaround the problem (tried on both 6.1 and 6.2 kernels):

--- library/evdi_lib.h
+++ library/evdi_lib.h
@@ -13,7 +13,7 @@ extern "C" {
 #endif

 #define LIBEVDI_VERSION_MAJOR 1
-#define LIBEVDI_VERSION_MINOR 13
+#define LIBEVDI_VERSION_MINOR 12
 #define LIBEVDI_VERSION_PATCH 0

 struct evdi_lib_version {
displaylink-emajewsk commented 1 year ago

Does any feedback from the community represented here make it in front of their eyes?

@djallits Yes. I forward and voice all the concerns and frustrations I see here or on the unofficial AUR, plus a whole bunch of my own.

Is there any reason why there could not be an official 1.12.1 release?

@mrTsjolder The reason is mostly historical. There's certainly room for improvement, but any changes are subject to business needs.

mrTsjolder commented 1 year ago

@displaylink-emajewsk Just to make sure: with "official", I just meant a v1.12.1 tag and/or a corresponding github release pointing to this tag. I understand that it is silly to have two releases pointing to the same code, but I do not see how this relates to "business needs". In the end, this is merely a technicality in a github repository.

@gringus It is probably more convenient to use the ci/set_version script, which also changes version numbers in other files.

I will close this issue since my original problem has been solved, but I don't believe that this will be the last confusion/frustration due to this particular versioning scheme.

PS: I used the script to create a 1.12.2 version from the v1.13.1 branch and this still seems to work on linux 6.2.