5.11.0-rc1 Building #249
Comments
|
Re the compile error listed above in evdi_modeset.c for the origin/devel branch, what's happened is that the atomic_flush has changed to pass struct drm_atomic_state *state instead of struct drm_crtc_state *old_state, so I think evdi_modeset.c just needs changing to something like this: butt when I try to compile 5.11-rc2, I still get all the other errors listed above for the origin/1.7.x branch. |
|
Thank you @rockorequin I will your snippet shortly! |
|
@sickcodes No problems! For the other errors, it looks like the last two commits to drm_drv.h are what broke things: You can get around this by enabling CONFIG_DRM_LEGACY in the Makefile ccflags:
With the above change, the errors about preclose and enable_vblank/disable_vblank disappear for me. But I still get errors about the GEM and PRIME callbacks due to this commit: and that looks like a more complicated fix. |
|
I got evdi to build with 5.11-rc2 using the patch at https://gist.github.com/rockorequin/f3047e748bcba9be9d1fff06f472dbda, but I haven't got a DisplayLink monitor atm to test it with. The patch cheats by using the CONFIG_DRM_LEGACY define in the Makefile so that I didn't have to remap the vblank etc function callbacks. |
|
Thanks @rockorequin, builds perfect on devel branch! git clone https://github.com/DisplayLink/evdi.git && cd evdi
git checkout -f devel
curl "https://gist.githubusercontent.com/rockorequin/f3047e748bcba9be9d1fff06f472dbda/raw/93b4792bb11ffe0a77973a6335d3e5c751dcf053/evdi-devel-5.11-rc2.patch"
git apply --verbose --ignore-whitespace evdi-devel-5.11-rc2.patch
make # && sudo make installDid you want to write the PR? I also had to add Even though I have two displaylink things, I also cannot test 1.9 as we're still on 1.7.x. I think we will also need to cherry-pick the fix to 1.7.x, I will attempt that now with your fix! |
|
Not sure if it works yet tho, no screen activity on 1.7.x with 5.11rc2 but I'll poke around with starting/stopping the service, maybe @abucodonosor might know something. |
|
Is it the Should that be |
|
@sickcodes Thanks for your help, contribution and enthusiasm. Did @rockorequin give the go ahead to submit his patch as a PR? I think I missed that somewhere. Just trying to put myself in his place, unless he said to go for it. The current kernel 5.11 release candidate is only the second one. It would be nice if someone could test this on actual hardware since all that appears to have been done are compile tests. Just my 2 cents. It is great to see the contributions from the community to hopefully help keep us from falling behind again with new kernel releases. |
|
the accepted syntax for this module is: so the logic is swapped :). I didn't looked what changed bc a big batch of DRM stuff will hit rc3++, but those defines lin your patch look wrong to me. |
Unfortunately, I don't have any time to look at this right now. I may have some time next week. |
|
Sorry ya'll, I already committed it locally and was only 1 click away from a PR so I pushed it anyway. Can confirm 1.7.x doesn't run yet with the changes above on two DisplayLink hardware devices. I will triple check if I have made an error and I think I have. How can I check why it won't run? |
|
I tried the patch from @rockorequin with your instructions @sickcodes, but no success yet. I'm getting this on Something new about this? |
|
Ok, I figure out that the |
|
Yeah, we are having some null pointer deference when connecting the device: |
|
@microhobby You need to use evdi 1.7.2 --> #245 |
|
@elguero yes I figure out this also, cause when I try to use from I'm getting the null pointer deference running the 1.7.2 |
|
ok, so I think I found the root cause: I change it and tested and now works for @sickcodes I sent you a PR, sickcodes#1, so if you are going to continue and send a PR to this repository you already have my contribution to your work. Thanks, also to @rockorequin to the great work. |
Thanks for that! Hey @rockorequin are you still here? :)
@microhobby do you think we can fix the style, as per @abucodonosor's request? :) |
|
@sickcodes yeah for sure, check my MR I used what I think is the expected way: #if KERNEL_VERSION(5, 11, 0) <= LINUX_VERSION_CODE
struct dma_buf_map map;
#endif |
|
Merged on https://github.com/sickcodes/evdi/tree/v1.7.x
|
|
Great work @rockorequin @microhobby! Working for me on 5.11-rc6 using branch https://github.com/sickcodes/evdi/tree/v1.7.x CC: @bnavigator if you wanna test sudo pacman -R evdi || sudo pacman -R evdi-git
yay --getpkgbuild evdi
cd evdi
sed -i -e s/DisplayLink/sickcodes/g PKGBUILD
sed -i -e s/^pkgver\=/pkgver\=1.7.x\ \#/g PKGBUILD
sed -i -e s/^md5sums/old_md5sums/g PKGBUILD
perl -i -p -e s/^old_md5sums/md5sums\=\(\'SKIP\'\)\\nold_md5sums/g PKGBUILD
makepkg --nodeps -si
sudo modprobe evdi
sudo systemctl disable displaylink.service
reboot
# no reboot froze
sudo systemctl start displaylink
|
|
Forgot to mention, the external display is working now on 5.11 so if you want to get this into 7.1.x it's good to go functionally @displaylink-dkurek thanks to @rockorequin & @microhobby! |
|
@sickcodes trying to reproduce your results here, but I get a dependency error with DisplayLink. |
|
|
|
No, use a proper version string for evdi. "1.7.x" does not work with the resolver. |
|
Should I change my branch name or just submit this as a PR so people can test? |
|
You have to change how you generate your version number (The pkgver sed command in your post above, maybe?). |
Hey @sickcodes good spot, that line needs to be changed to #elif or this branch doesn't compile with earlier kernels like 5.8. Great to see you've got it working! I don't have a monitor to test it on but this branch installs for me on both kernels 5.8 (with the #elif fix) and 5.11-rc7. |
ok, I had no system freezes (maybe I need to test with the new changes from @rockorequin), but the issue with the shutdown did. If you have any logs to share it will be of great help. I'll see if at the weekend I can do some analysis on the shutdown issue. |
|
Fwiw, Ubuntu 21.04 has now moved to the 5.11 kernel. 5.10 seems to be available for now luckily. I installed the driver for Ubuntu's 5.11.0-11-generic kernel with these lines modified in evdi_gem_free_object
|
|
I switched to the LTS kernel and everything -- evdi (but not evdi-git), udl, displaylink -- seemed to be working properly. However, no matter what I reconfigured, I still couldn't get the USB monitor to work. Xrandr would occasionally recognize the monitor, but whenever I tried to initialize it, nothing would show up on the screen. The working screens would flash black, turn back on, but the USB monitor remained black. Xrandr would display error 4 in the terminal. At other times, Xrandr simply doesn't recognize the monitor, while dmesg always recognizes the displaylink/USB device. I've pretty much tried everything following the Arch Wiki page!! I'm starting to think it's my hardware that's incompatible. I'm using Plugable USB 2.0 HDMI/VGA adapter. Am I just out of luck as it pertains to the current hardware? |
|
There seem to be at least two separate things happening related to the freezes. I checked journalctl after one freeze (when I tried changing the layout) and it It indicated the bug was at drivers/dma-buf/dma-buf.c:1269. (Unfortunately there was no further info.) But based on the generic 5.11.0 kernel is in dma_buf_vunmap() at the line BUG_ON(!dma_buf_map_is_equal(&dmabuf->vmap_ptr, map)); I also tried ssh'ing into the laptop when I tried to recreate the same freeze, but this time there was no kernel bug. The ssh session continued operating normally, but the laptop screen was blank except for a frozen mouse cursor. Killing the session via loginctl didn't fix anything, so it was as if the graphics drivers had locked up. |
Anyone reading, this PR no longer works. How does one debug this properly? @microhobby have you tried 5.11.6? I can't activate displays at all anymore, early 5.11 was working though! Have two blank screens on my desk, like many others on 5.11 😬 |
I have a USB2 and USB3 one let me check tomrorow but you are correct my 5.10.23 USB2 displaylink doesn't work on LTS anymore and I wasn't sure why! Perhaps I have old files around but I will test the USB3 part as, like many DisplayLink paying customers, we need our screens and hardware to work. So in terms of debugging, @displaylink-mlukaszek can you give us the decryption codes for the displaylink driver logs? -logging and -debugging are not helpful at all, whatsoever 😂 |
|
I emailed PSIRT @ Synaptics about disgraceful logging: https://cwe.mitre.org/data/definitions/778.html |
Thanks for trying to help!! It magically started working yesterday on the LTS kernel. I had left the USB plugged in from a Windows session; when I logged in (to Linux), the USB screen just turned on lol. Before that, I had spent some more effort trying to fix it by installing additional Intel drivers and changing one of the xorg config documents contrary to the Arch Wiki. Anyway, unfortunately, it still wasn't usable, because everything became incredibly slow and laggy. Journalctl showed that some bytes of the EDID -- different ones at varying times -- weren't being read. Installing a package called read_edid didn't fix it. I ended up breaking the kernel while trying to fix the problem lol. I'm going to try again on the LTS at a later time (have to reconfigure everything ugh), but any ideas would be greatly appreciated. |
|
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS PGothic";
panose-1:2 11 6 0 7 2 5 8 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS PGothic";}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0mm;
text-align:justify;
text-justify:inter-ideograph;
font-size:10.5pt;
font-family:"游ゴシック",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;}
/* Page Definitions */
@page WordSection1
{size:612.0pt 792.0pt;
margin:99.25pt 30.0mm 30.0mm 30.0mm;}
div.WordSection1
{page:WordSection1;}
-->
|
|
Just updated my system to the dev release of ubuntu (hirsute), which has kernel |
Good to know, did you uninstall 1.9 first? I also fell for this the first time I installed both. Unless 1.9 is ready? |
|
I've got this driver working for me in Linux 5.11 (Wayland only - see below) using the rockorequin-sickcodes-microhobby-patch-1.7.x branch and the patch at https://gist.github.com/rockorequin/9f16d3dd2a3278c3d19d7871a72a4092 (I tried pushing to the branch but I don't have access). ie I fetched the branch with this command: and then I applied the patch in the gist and built it for kernels 5.10 and 5.11 using dkms (I have symlinked /usr/bin/evdi-1.7.2 to the evdi/module folder and then I can use "sudo dkms install -m evdi -v 1.7.2 -k " to build and install the module). In the patch, I removed CONFIG_DRM_LEGACY from the Makefile and removed the vblank functions for linux 5.11+. The other changes are mostly cosmetic (comments) but I did add a check to the return value from dma_buf_vmap and now it sets obj->vmapping to NULL on error. I wouldn't have thought this was happening often, but it is possible that on error obj->vmapping was being set to some random value instead of NULL and causing chaos. I'm running Ubuntu 21.04, Linux 5.11.0-11-generic and evdi in a Wayland session. I haven't tried suspend/resume yet but logging out and back in, rebooting, and removing the monitor are all working without crashing. However, isn't working under X11 in either Linux 5.11.0-11-generic or 5.10.0-14-generic. The good news is that it doesn't crash the kernel any more. gnome-settings recognises that there is a monitor attached, but it only allows me to have chose "Single Display" - when I try to change it, it reverts back to a single display. |
|
@arif-ali: are you using a Wayland or an X11 session? |
|
Fwiw, I also got evdi working (in Wayland) for kernel 5.12-rc4 using the patch at https://gist.github.com/rockorequin/f61fcb0217194997a2a3e8c4da260e4c. It's a bit hacky because I just copied in the functions that have been removed or made internal. |
@rockorequin you have to add my branch as a remote, you can cherry pick it, and then push to your own fork, then submit PR across to mine, or just fork it, and I'll PR everything over to yours I guess we are skipping 5.11 😂 I'll give your gist a go today on 5.12! |
|
Testing 5.12 rc6 Can you fork evdi @rockorequin I'll PR all the code to my your repo |
|
@rockorequin Although hirsute defaults to wayland, I have stuck with X11, as there were issues with Google Meet, and other stuff or work related stuff. So, my default was X11, and as I did a @sickcodes I had 1.7.2 installed before, but the kernel I was using had already been removed, and hence the evdi driver was no longer there anymore. So, I've just straight to 1.9.0, with the 2 patches in this thread |
[user@hostname ~]$ uname -a
Linux hostname 5.11.8-arch1-1 I think this PR stopped working around 5.11.5 or 5.11.6 but I'm going straight to 5.12 instead, will report back with @rockorequin's patch! |
git clone \
--branch rockorequin-sickcodes-microhobby-patch-1.7.x \
https://github.com/sickcodes/evdi
cd evdi
wget -O rockorequin.5.12.patch https://gist.githubusercontent.com/rockorequin/f61fcb0217194997a2a3e8c4da260e4c/raw/1b3fd7f686e93b7c410b7d212174b53a5f5f8019/gistfile1.txt
patch -p1 < rockorequin.5.12.patch
make
sudo make install@rockorequin Thanks for this! I got the following on [user@hostname evdi]$ make
CFLAGS="-Werror -Wextra -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializers" make -C module
make[1]: Entering directory './evdi/module'
cat: /etc/redhat-release: No such file or directory
make -C /lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build M=$PWD
make[2]: Entering directory '/usr/lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build'
cat: /etc/redhat-release: No such file or directory
CC [M] ./evdi/module/evdi_drv.o
./evdi/module/evdi_drv.c: In function ‘drm_gem_dumb_destroy’:
./evdi/module/evdi_drv.c:87:24: error: unused parameter ‘dev’ [-Werror=unused-parameter]
87 | struct drm_device *dev,
| ~~~~~~~~~~~~~~~~~~~^~~
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:271: ./evdi/module/evdi_drv.o] Error 1
make[2]: *** [Makefile:1851: ./evdi/module] Error 2
make[2]: Leaving directory '/usr/lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build'
make[1]: *** [Makefile:77: module] Error 2
make[1]: Leaving directory './evdi/module'
make: *** [Makefile:8: all] Error 2 |
|
@sickcodes: I also recommend the patch at https://gist.github.com/rockorequin/9f16d3dd2a3278c3d19d7871a72a4092 as it ensures a failed alloc doesn't try to continue with random memory (that's the one I need to get around to pushing to you). Re your warning, it looks like we should define the function drm_gem_dumb_destroy with __always_unused: When you say that it stopped working around 5.11.5, what are the symptoms? It's not working for me in X11 at all (in 5.10, 5.11, 5.12), but under Wayland it works in both 5.11 (the latest Ubuntu 21.04 kernel, which must be at least 5.11.5) and 5.12-rc4. By it doesn't work I mean that although X recognises there is a monitor, it won't allow me to turn it on. |
Will try both patches now Same error in 5.11.6: unable to turn it on. Not sure exactly when it started however. Unable to debug encrypted displaylink logs. I'm gonna dump the firmware on the device and see if I can enable decrypted logging. |
I've just logged out, and logged back in again, and realised I was now using Wayland and not xorg. So those patches worked for me in Wayland :) Distro: Ubuntu 21.04 (devel) patched using these 2 patches |
|
@rockorequin very close! I forked your gist and added git clone \
--branch rockorequin-sickcodes-microhobby-patch-1.7.x \
https://github.com/sickcodes/evdi
cd evdi
wget -O rockorequin.5.12.patch https://gist.githubusercontent.com/sickcodes/2c62b829fdb2d9f98f547e27dd1c85f5/raw/1543ab1d9891c7181bf57df3d08ff2555b514b36/gistfile1.txt
wget -O rockorequin2.5.12.patch https://gist.githubusercontent.com/rockorequin/9f16d3dd2a3278c3d19d7871a72a4092/raw/c746cacd365116366886beb1092a7dd78bd6d16b/gistfile1.txt
patch -p1 < rockorequin.5.12.patch
patch -p1 < rockorequin2.5.12.patch
make
# sudo make install[user@hostname evdi]$ make
CFLAGS="-Werror -Wextra -Wall -Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializers" make -C module
make[1]: Entering directory './evdi/module'
cat: /etc/redhat-release: No such file or directory
make -C /lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build M=$PWD
make[2]: Entering directory '/usr/lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build'
cat: /etc/redhat-release: No such file or directory
CC [M] ./evdi/module/evdi_drv.o
CC [M] ./evdi/module/evdi_modeset.o
CC [M] ./evdi/module/evdi_connector.o
CC [M] ./evdi/module/evdi_encoder.o
CC [M] ./evdi/module/evdi_main.o
CC [M] ./evdi/module/evdi_fb.o
CC [M] ./evdi/module/evdi_gem.o
./evdi/module/evdi_gem.c:47:5: error: no previous prototype for ‘drm_prime_sg_to_page_addr_arrays’ [-Werror=missing-prototypes]
47 | int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page **pages,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:271: ./evdi/module/evdi_gem.o] Error 1
make[2]: *** [Makefile:1851: ./evdi/module] Error 2
make[2]: Leaving directory '/usr/lib/modules/5.12.0-rc4-1-git-00004-g84196390620a/build'
make[1]: *** [Makefile:77: module] Error 2
make[1]: Leaving directory './evdi/module'
make: *** [Makefile:8: all] Error 2 |
|
I removed the CFLAG warnings and installed, rebooting FLAGS=-Werror -Wextra -Wall #-Wmissing-prototypes -Wstrict-prototypes -Wno-error=missing-field-initializersEdit: 🥺🤣 no good Lemme try Wayland... |
|
btw, tried on Xorg just now, and nope, it doesn't work. It detects the monitors, but when applying the setting, it hangs for ~10 seconds, and back to main screen. So, its only wayland for me |
|
@sickcodes: does it stop your error if you make drm_prime_sg_to_page_addr_arrays a static function? I've updated the 5.12 patch at https://gist.github.com/rockorequin/f61fcb0217194997a2a3e8c4da260e4c to include the __always_unused and also to make drm_prime_sg_to_page_addr_arrays static. |
Haven't had much time recently to test, I will try shortly. |
|
FWIW latest testing verison: seems to be working...! |
Ready and able to test!
origin/devel
origin/v1.7.x
origin/master
The text was updated successfully, but these errors were encountered: