Closed sickcodes closed 3 years ago
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:
static void evdi_crtc_atomic_flush(
struct drm_crtc *crtc
#if KERNEL_VERSION(5, 11, 0) >= LINUX_VERSION_CODE
, __always_unused struct drm_atomic_state *old_state
#else
, __always_unused struct drm_crtc_state *old_state
#endif
)
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:
commit 57bb1ee6034046be70aed33fd6d447bb2b7261fa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Nov 4 11:04:21 2020 +0100
drm: Compile out legacy chunks from struct drm_device
You can get around this by enabling CONFIG_DRM_LEGACY in the Makefile ccflags:
ccflags-y := -Iinclude/drm -DCONFIG_DRM_LEGACY
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:
commit d693def4fd1c23f1ca5aed1afb9993b3a2069ad2
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Wed Sep 23 12:21:59 2020 +0200
drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver
Several GEM and PRIME callbacks have been deprecated in favor of
per-instance GEM object functions. Remove the callbacks as they are
now unused. The only exception is .gem_prime_mmap, which is still
in use by several drivers.
What is also gone is gem_vm_ops in struct drm_driver. All drivers now
use struct drm_gem_object_funcs.vm_ops instead.
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 install
Did you want to write the PR?
I also had to add -DCONFIG_DRM_LEGACY
to line 44 for kbuild, in addition to the dkms build which your patch fixed.
e.g.
ccflags-y := -isystem include/drm $(CFLAGS) $(EL8FLAG)
ccflags-y := -isystem include/drm $(CFLAGS) $(EL8FLAG) -DCONFIG_DRM_LEGACY
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 #elsif
statement?
Should that be #elif
?
@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.
@rockorequin
the accepted syntax for this module is:
#if KERNEL_VERSION(X, Y, Z) <= LINUX_VERSION_CODE
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.
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.
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 dmesg
:
[ 3.195586] evdi: loading out-of-tree module taints kernel.
[ 3.197004] evdi: module verification failed: signature and/or required key missing - tainting kernel
[ 3.197519] evdi: [I] Initialising logging on level 5
[ 3.197521] evdi: [I] Atomic driver: yes
[ 3.197558] evdi: [D] evdi_platform_add_devices:145 Increasing device count to 4
[ 3.197642] evdi: [D] evdi_crtc_init:394 drm_crtc_init: 0 p00000000cb1b80e7
[ 3.197652] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 3.197658] evdi evdi.0: [drm] Cannot find any crtc or sizes
[ 3.197668] evdi: [W] evdi_painter_send_update_ready_if_needed:706 Painter does not exist!
[ 3.198780] [drm] Initialized evdi 1.9.0 20201210 for evdi.0 on minor 0
[ 3.198800] evdi: [I] Evdi platform_device create
[ 3.254690] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 3.254716] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 3.254718] evdi: [I] Task 396 (plymouthd) of process 396 (plymouthd)
[ 3.354205] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 3.354227] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 3.354230] evdi: [I] Task 396 (plymouthd) of process 396 (plymouthd)
[ 4.856145] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 4.856164] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 4.856167] evdi: [I] Task 396 (plymouthd) of process 396 (plymouthd)
[ 5.402913] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 5.402917] evdi: [I] Task 641 (gpu-manager) of process 641 (gpu-manager)
[ 5.402953] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 5.402955] evdi: [I] Task 641 (gpu-manager) of process 641 (gpu-manager)
[ 5.403008] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 5.403010] evdi: [I] Task 641 (gpu-manager) of process 641 (gpu-manager)
[ 6.471511] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 7.926715] Modules linked in: uvcvideo(+) rtsx_usb videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 uas ecdh_generic videobuf2_common videodev ecc usb_storage snd_hda_codec_hdmi snd_seq_dummy snd_hrtimer snd_usb_audio snd_usbmidi_lib usbhid mc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp ath10k_pci snd_hda_intel ath10k_core snd_intel_dspcfg snd_hda_codec snd_hda_core kvm_intel snd_hwdep overlay kvm ath snd_pcm snd_seq_midi joydev snd_seq_midi_event crct10dif_pclmul nouveau binfmt_misc mac80211 mei_hdcp snd_rawmidi ghash_clmulni_intel aesni_intel snd_seq nls_iso8859_1 crypto_simd input_leds cryptd glue_helper snd_seq_device snd_timer drm_ttm_helper rapl i915 cfg80211 intel_cstate snd serio_raw ttm efi_pstore soundcore mei_me mxm_wmi ee1004 mei libarc4 hid_multitouch intel_pch_thermal i2c_algo_bit acpi_tad mac_hid acpi_pad sch_fq_codel evdi(OE) drm_kms_helper cec rc_core drm fb_sys_fops
[ 8.259156] evdi: [D] evdi_painter_dpms_notify:715 (dev=0) Notifying dpms mode: 3
[ 8.259161] evdi: [W] evdi_painter_send_event:321 Painter is not connected!
[ 29.691976] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 29.691980] evdi: [I] Task 1939 (Xorg.wrap) of process 1939 (Xorg.wrap)
[ 29.872282] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 29.872342] evdi: [D] evdi_painter_framebuffer_size:594 Scanout buffer not set.
[ 29.872344] evdi: [D] evdi_painter_mark_dirty:621 (dev=0) Skip clip rect. Scanout buffer not set.
[ 29.872352] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 30.131851] evdi: [D] evdi_painter_dpms_notify:715 (dev=0) Notifying dpms mode: 3
[ 30.131855] evdi: [W] evdi_painter_send_event:321 Painter is not connected!
[ 30.352443] evdi: [D] evdi_painter_dpms_notify:715 (dev=0) Notifying dpms mode: 3
[ 30.352447] evdi: [W] evdi_painter_send_event:321 Painter is not connected!
[ 30.921058] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 32.213576] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 33.732400] evdi: [D] evdi_driver_postclose:234 (dev=0) Process tries to close us, postclose
[ 33.732404] evdi: [I] Task 1 (systemd) of process 1 (systemd)
[ 76.206256] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
[ 127.881311] evdi: [D] evdi_detect:94 (dev=0) poll connector state: disconnected
Something new about this?
Ok, I figure out that the DisplayLinkManager
was not running.
Now I have the screen receiving signal, but no image all black.
Yeah, we are having some null pointer deference when connecting the device:
[ 3298.507373] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3298.507384] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3298.507416] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3298.507420] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3298.507441] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3298.507444] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3298.507473] evdi: [D] evdi_detect:90 (dev=0) painter is connected
[ 3298.507476] evdi: [D] evdi_detect:92 (dev=0) poll connector state: connected
[ 3298.507481] evdi: [D] evdi_painter_get_edid_copy:228 (dev=0) EDID valid
[ 3316.038136] evdi: [D] evdi_painter_dpms_notify:654 (dev=0) Notifying dpms mode: 0
[ 3316.038149] evdi: [D] evdi_painter_mode_changed_notify:701 (dev=0) Notifying mode changed: 1920x1080@60; bpp 32;
[ 3316.038152] evdi: [D] evdi_log_pixel_format:680 pixel format XR24 little-endian (0x34325258)
[ 3316.038155] evdi: [D] evdi_painter_dpms_notify:654 (dev=0) Notifying dpms mode: 0
[ 3316.047829] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 3316.047833] #PF: supervisor read access in kernel mode
[ 3316.047834] #PF: error_code(0x0000) - not-present page
[ 3316.047836] PGD 800000014b017067 P4D 800000014b017067 PUD 14b28c067 PMD 0
[ 3316.047840] Oops: 0000 [#3] SMP PTI
[ 3316.047843] CPU: 5 PID: 11217 Comm: ThreadedDevice_ Tainted: G D W O 5.11.0-rc5-MicroHobby+ #5
[ 3316.047845] Hardware name: SAMSUNG ELECTRONICS CO., LTD. 800G5M/800G5W/NP800G5M-XG2BR, BIOS P11RDV.075.170829.XJ 08/29/2017
[ 3316.047846] RIP: 0010:dma_buf_vmap+0x2a/0x120
[ 3316.047850] Code: 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 49 89 f4 53 48 89 fb 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 <80> 7e 08 00 48 c7 06 00 00 00 00 74 04 c6 46 08 00 48 85 db 0f 84
[ 3316.047852] RSP: 0018:ffff9eca4209fc48 EFLAGS: 00010246
[ 3316.047854] RAX: 0000000000000000 RBX: ffff90dbcb2ed000 RCX: 0000000000000000
[ 3316.047856] RDX: ffff90dbb5a70000 RSI: 0000000000000000 RDI: ffff90dbcb2ed000
[ 3316.047857] RBP: ffff9eca4209fc80 R08: 0000000000000000 R09: 0000000000000000
[ 3316.047858] R10: ffff90db9abee040 R11: 0000000000000438 R12: 0000000000000000
[ 3316.047860] R13: ffff9eca4209fd00 R14: ffff90db9abee000 R15: ffff90db8a019200
[ 3316.047861] FS: 00007f9b1b7fe640(0000) GS:ffff90e29ed40000(0000) knlGS:0000000000000000
[ 3316.047863] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3316.047864] CR2: 0000000000000008 CR3: 0000000128274001 CR4: 00000000003706e0
[ 3316.047866] Call Trace:
[ 3316.047867] ? __ext4_journal_stop+0x3c/0xb0
[ 3316.047873] evdi_gem_vmap+0x2a/0xd0 [evdi]
[ 3316.047879] evdi_painter_grabpix_ioctl+0x42c/0x520 [evdi]
[ 3316.047883] ? generic_perform_write+0x133/0x1c0
[ 3316.047887] ? __check_object_size+0x4d/0x150
[ 3316.047891] ? atime_needs_update+0x73/0xd0
[ 3316.047894] ? touch_atime+0x33/0x140
[ 3316.047896] ? _cond_resched+0x1a/0x50
[ 3316.047898] ? mutex_lock+0x13/0x40
[ 3316.047900] ? evdi_painter_connect_ioctl+0x250/0x250 [evdi]
[ 3316.047905] drm_ioctl_kernel+0xae/0xf0 [drm]
[ 3316.047929] drm_ioctl+0x245/0x400 [drm]
[ 3316.047956] ? evdi_painter_connect_ioctl+0x250/0x250 [evdi]
[ 3316.047960] ? vfs_read+0x188/0x1c0
[ 3316.047963] __x64_sys_ioctl+0x91/0xc0
[ 3316.047967] do_syscall_64+0x38/0x90
[ 3316.047970] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 3316.047973] RIP: 0033:0x7f9b65a1331b
[ 3316.047975] Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1d 3b 0d 00 f7 d8 64 89 01 48
[ 3316.047977] RSP: 002b:00007f9b1b7fd2a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
[ 3316.047979] RAX: ffffffffffffffda RBX: 0000000002aa8d20 RCX: 00007f9b65a1331b
[ 3316.047980] RDX: 00007f9b1b7fd380 RSI: 00000000c0286442 RDI: 00000000000000ad
[ 3316.047982] RBP: 00007f9b1b7fd2e0 R08: 00007f9ae8001fd0 R09: 0000000000000000
[ 3316.047983] R10: 0000000000000000 R11: 0000000000000202 R12: 00007f9b1b7fd470
[ 3316.047984] R13: 00007f9b40002100 R14: 00007f9b40001840 R15: 00007f9b1b7fd760
[ 3316.047986] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo nft_counter xt_addrtype nft_compat nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables libcrc32c nfnetlink br_netfilter bridge stp llc ccm rfcomm cmac algif_hash algif_skcipher af_alg bnep rtsx_usb_ms btusb rtsx_usb_sdmmc memstick btrtl btbcm btintel uas bluetooth hid_corsair uvcvideo usb_storage videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 rtsx_usb videobuf2_common videodev ecdh_generic ecc snd_seq_dummy snd_hrtimer overlay binfmt_misc nls_iso8859_1 snd_usb_audio snd_usbmidi_lib usbhid mc snd_hda_codec_hdmi ath10k_pci intel_rapl_msr intel_rapl_common ath10k_core mei_hdcp x86_pkg_temp_thermal intel_powerclamp coretemp ath kvm_intel snd_hda_codec_realtek kvm snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg joydev snd_hda_codec snd_hda_core snd_hwdep crct10dif_pclmul ghash_clmulni_intel mac80211 aesni_intel snd_pcm crypto_simd cryptd glue_helper
[ 3316.048033] snd_seq_midi snd_seq_midi_event rapl nouveau i915 snd_rawmidi cfg80211 snd_seq snd_seq_device snd_timer intel_cstate snd input_leds drm_ttm_helper serio_raw ttm efi_pstore mxm_wmi mei_me ee1004 mei hid_multitouch libarc4 soundcore intel_pch_thermal i2c_algo_bit sch_fq_codel evdi(O) acpi_tad mac_hid acpi_pad drm_kms_helper cec rc_core drm fb_sys_fops syscopyarea sysfillrect sysimgblt parport_pc ppdev lp parport ip_tables x_tables autofs4 hid_generic nvme nvme_core r8169 crc32_pclmul ahci intel_lpss_pci libahci intel_lpss i2c_hid idma64 i2c_i801 hid xhci_pci i2c_smbus realtek xhci_pci_renesas virt_dma pinctrl_sunrisepoint video wmi
[ 3316.048070] CR2: 0000000000000008
[ 3316.048072] ---[ end trace 494a1fa7abaeffe4 ]---
[ 3316.102393] RIP: 0010:dma_buf_vmap+0x2a/0x120
[ 3316.102397] Code: 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 49 89 f4 53 48 89 fb 48 83 ec 18 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 <80> 7e 08 00 48 c7 06 00 00 00 00 74 04 c6 46 08 00 48 85 db 0f 84
[ 3316.102399] RSP: 0018:ffff9eca43ea7c48 EFLAGS: 00010246
[ 3316.102401] RAX: 0000000000000000 RBX: ffff90db8bcd1400 RCX: 0000000000000000
[ 3316.102402] RDX: ffff90db8eb218c0 RSI: 0000000000000000 RDI: ffff90db8bcd1400
[ 3316.102404] RBP: ffff9eca43ea7c80 R08: 0000000000000000 R09: 0000000000000001
[ 3316.102406] R10: 0000000000000002 R11: 0000000000000000 R12: 0000000000000000
[ 3316.102411] R13: ffff9eca43ea7d00 R14: ffff90db9abee000 R15: ffff90dbb0145e00
[ 3316.102412] FS: 00007f9b1b7fe640(0000) GS:ffff90e29ed40000(0000) knlGS:0000000000000000
[ 3316.102414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 3316.102416] CR2: 0000000000000008 CR3: 0000000128274001 CR4: 00000000003706e0
[ 3316.530472] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.530477] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.530491] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.530493] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.530504] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.530505] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.530520] evdi: [D] evdi_detect:90 (dev=0) painter is connected
[ 3316.530521] evdi: [D] evdi_detect:92 (dev=0) poll connector state: connected
[ 3316.530523] evdi: [D] evdi_painter_get_edid_copy:228 (dev=0) EDID valid
[ 3316.690871] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.690878] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.690895] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.690897] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.690927] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3316.690929] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3316.690949] evdi: [D] evdi_detect:90 (dev=0) painter is connected
[ 3316.690951] evdi: [D] evdi_detect:92 (dev=0) poll connector state: connected
[ 3316.690954] evdi: [D] evdi_painter_get_edid_copy:228 (dev=0) EDID valid
[ 3336.780649] evdi: [D] evdi_painter_dpms_notify:654 (dev=0) Notifying dpms mode: 3
[ 3336.780787] evdi: [D] evdi_painter_dpms_notify:654 (dev=0) Notifying dpms mode: 3
[ 3336.981947] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3336.981950] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3336.981963] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3336.981965] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3336.981974] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3336.981975] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3336.981988] evdi: [D] evdi_detect:90 (dev=0) painter is connected
[ 3336.981990] evdi: [D] evdi_detect:92 (dev=0) poll connector state: connected
[ 3336.981991] evdi: [D] evdi_painter_get_edid_copy:228 (dev=0) EDID valid
[ 3337.142897] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3337.142900] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3337.142912] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3337.142913] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3337.142921] evdi: [D] evdi_detect:97 (dev=0) painter is disconnected
[ 3337.142922] evdi: [D] evdi_detect:99 (dev=0) poll connector state: disconnected
[ 3337.142934] evdi: [D] evdi_detect:90 (dev=0) painter is connected
[ 3337.142935] evdi: [D] evdi_detect:92 (dev=0) poll connector state: connected
[ 3337.142937] evdi: [D] evdi_painter_get_edid_copy:228 (dev=0) EDID valid
@microhobby You need to use evdi 1.7.2 --> https://github.com/DisplayLink/evdi/issues/245
@elguero yes I figure out this also, cause when I try to use from devel
even running the DisplayLinkManager
I did not have the device state changed to connected. Now I'm using the https://github.com/sickcodes/evdi/tree/v1.7.x
I'm getting the null pointer deference running the 1.7.2
ok, so I think I found the root cause:
dma_buf_vmap(obj->base.import_attach->dmabuf, obj->vmapping);
I change it and tested and now works for v5.11-rc6
. I'm right now writing this on my Displaylink screen 😎.
@sickcodes I sent you a PR, https://github.com/sickcodes/evdi/pull/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.
ok, so I think I found the root cause:
dma_buf_vmap(obj->base.import_attach->dmabuf, obj->vmapping);
I change it and tested and now works for
v5.11-rc6
. I'm right now writing this on my Displaylink screen sunglasses.@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? :)
@rockorequin
the accepted syntax for this module is:
#if KERNEL_VERSION(X, Y, Z) <= LINUX_VERSION_CODE
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.
@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
@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
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.
==> Finished making: evdi 1.7.x-1 (Sat 06 Feb 2021 08:30:31 PM EST)
==> Installing package evdi with pacman -U...
loading packages...
warning: downgrading package evdi (1.7.2-1 => 1.7.x-1)
resolving dependencies...
looking for conflicting packages...
error: failed to prepare transaction (could not satisfy dependencies)
:: installing evdi (1.7.x-1) breaks dependency 'evdi>=1.7.0' required by displaylink
==> WARNING: Failed to install built package(s).
Open ./PKGBUILD and delete DisplayLink from the dependencies before this command
makepkg --nodeps -si
No, use a proper version string for evdi. "1.7.x" does not work with the resolver.
1.7.x
is the named branch from DisplayLink https://github.com/DisplayLink/evdi/tree/v1.7.x
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?).
Is it the
#elsif
statement?Should that be
#elif
?
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.
Is it the
#elsif
statement?Should that be
#elif
?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.
Thanks for that @rockorequin! Feel free to adjust and submit the PR as I can confirm it's working on my hardware in 5.11 on Arch :)
@microhobby Has also confirmed in this great video working on Ubuntu: https://youtu.be/6RvZyuAds1Y
@sickcodes Thanks I can now see the external monitor, however I've discovered a secondary issue on Manjaro where optimus-manager has some conflict. Without the optimus-manger installed I cannot see the 2nd monitor now available via displayport, removing this has the 2nd monitor discoverable (I see it in dispaly manager and nvidia settings) however I cannot enable it. Seems like a Manjaro specific problem at the moment.
Thanks for your help!
Confirming that optimus-manager is breaking the displaylink service:
[bamu@bamu-omen ~]$ sudo systemctl start displaylink
[sudo] password for bamu:
Job for displaylink.service failed because the control process exited with error code.
See "systemctl status displaylink.service" and "journalctl -xe" for details.
Feb 10 15:31:42 bamu-omen systemd[1]: Starting DisplayLink Manager Service...
Subject: A start job for unit displaylink.service has begun execution
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
A start job for unit displaylink.service has begun execution.
The job identifier is 2449.
Feb 10 15:31:42 bamu-omen modprobe[3160]: modprobe: FATAL: Module evdi not found in directory /lib/modules/5.11.0-1-MANJARO
Feb 10 15:31:42 bamu-omen systemd[1]: displaylink.service: Control process exited, code=exited, status=1/FAILURE
Subject: Unit process exited
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
An ExecStartPre= process belonging to unit displaylink.service has exited.
The process' exit code is 'exited' and its exit status is 1.
Feb 10 15:31:42 bamu-omen systemd[1]: displaylink.service: Failed with result 'exit-code'.
Subject: Unit failed
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
The unit displaylink.service has entered the 'failed' state with result 'exit-code'.
Feb 10 15:31:42 bamu-omen systemd[1]: Failed to start DisplayLink Manager Service.
Subject: A start job for unit displaylink.service has failed
Defined-By: systemd
Support: https://forum.manjaro.org/c/support
A start job for unit displaylink.service has finished with a failure.
The job identifier is 2449 and the job result is failed.
Hmmm says here you haven't got evdi installed in the kernel modules folder for 5.11
Did you update and overwrite the evdi you just bootleg installed?
Or you might be booted into a different kernel than the one you built evdi with.
uname -a
find /lib/modules/ | grep evdi
Yo @microhobby did you want to "forward-port" your changes and @rockorequin's into the devel
branch too? I have one at devel.
I'm still trying to wrap my head around the correct procedure here but I believe fixes get put into devel
and then @displaylink-dkurek cherry-picks them into 1.7.x
. That's what happened last time with @abucodonosor's patch. Happy to be schooled on this though...
@rockorequin
the accepted syntax for this module is:
#if KERNEL_VERSION(X, Y, Z) <= LINUX_VERSION_CODE
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.
Hey @abucodonosor, @rockorequin or @microhobby, can you please let me know how the expected syntax for this should look?
Is >=
logic not allowed?
/* gem hooks */
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 9, 0)
// In 5.9 and below we have gem_free_object
.gem_free_object = evdi_gem_free_object,
#elif LINUX_VERSION_CODE <= KERNEL_VERSION(5, 11, 0)
// In 5.9 and 5.10 this is called gem_free_object_unlocked
.gem_free_object_unlocked = evdi_gem_free_object,
// Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead
#endif
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 11, 0)
// In 5.11+, this is set in the object instance
.gem_vm_ops = &evdi_gem_vm_ops,
#endif
I can change the rest of them as requested, and will submit a PR :)
Also, @rockorequin, in your comment:
#if LINUX_VERSION_CODE < KERNEL_VERSION(5, 9, 0)
// In 5.9 and below we have gem_free_object
Does that mean that I should replace the <
with a <=
?
@sickcodes: I think that it should be:
KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE
ie swap the LINUX_VERSION_CODE and KERNEL_VERSION around and also turn around the comparison operators, ie swap "<" into ">" (or swap "<=" into ">=").
@sickcodes
yes is ofc allowed. Just the coding style of this module needed to have #if KERNEL_VERSION(X, Y, Z) <= LINUX_VERSION_CODE, that's because checkpatch script and the CI.
Hey @rockorequin! One more quick question:
/* gem hooks */
#if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE
// In 5.9 and below we have gem_free_object
.gem_free_object = evdi_gem_free_object,
#elif KERNEL_VERSION(5, 11, 0) >= LINUX_VERSION_CODE
// In 5.9 and 5.10 this is called gem_free_object_unlocked
.gem_free_object_unlocked = evdi_gem_free_object,
// Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead
#endif
#if KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE
// In 5.11+, this is set in the object instance
.gem_vm_ops = &evdi_gem_vm_ops,
#endif
Should the middle elif be 5.10, as per the comment?
/* gem hooks */
#if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE
// In 5.9 and below we have gem_free_object
.gem_free_object = evdi_gem_free_object,
#elif KERNEL_VERSION(5, 10, 0) >= LINUX_VERSION_CODE
// In 5.9 and 5.10 this is called gem_free_object_unlocked
.gem_free_object_unlocked = evdi_gem_free_object,
// Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead
#elif KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE
// In 5.11+, this is set in the object instance
.gem_vm_ops = &evdi_gem_vm_ops,
#endif
As I just built it on 5.11.0-1-git
, but only after changing that line.
5.11 is out so just need confirmation on the above please anyone and this PR will be right on time! https://github.com/DisplayLink/evdi/pull/256
It can be compiled using PR #256 and the change mentioned here: https://github.com/DisplayLink/evdi/issues/249#issuecomment-779177919 but my screen didn't have an output.
Hey @rockorequin! One more quick question:
/* gem hooks */ #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE // In 5.9 and below we have gem_free_object .gem_free_object = evdi_gem_free_object, #elif KERNEL_VERSION(5, 11, 0) >= LINUX_VERSION_CODE // In 5.9 and 5.10 this is called gem_free_object_unlocked .gem_free_object_unlocked = evdi_gem_free_object, // Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead #endif #if KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE // In 5.11+, this is set in the object instance .gem_vm_ops = &evdi_gem_vm_ops, #endif
Should the middle elif be 5.10, as per the comment?
/* gem hooks */ #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE // In 5.9 and below we have gem_free_object .gem_free_object = evdi_gem_free_object, #elif KERNEL_VERSION(5, 10, 0) >= LINUX_VERSION_CODE // In 5.9 and 5.10 this is called gem_free_object_unlocked .gem_free_object_unlocked = evdi_gem_free_object, // Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead #elif KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE // In 5.11+, this is set in the object instance .gem_vm_ops = &evdi_gem_vm_ops, #endif
As I just built it on
5.11.0-1-git
, but only after changing that line.
@moodyhunter gimme thirty mins to test and I'll fix the PR
Fixed as per @rockorequin's inline comment https://github.com/DisplayLink/evdi/pull/256/commits/5ba407efddc8dd9ce6ebad22b909c0fb84429f1a
git clone \
--branch rockorequin-sickcodes-microhobby-patch-1.7.x \
https://github.com/sickcodes/evdi
cd evdi
make
sudo make install
Well done everyone!
Hey @rockorequin! One more quick question:
/* gem hooks */ #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE // In 5.9 and below we have gem_free_object .gem_free_object = evdi_gem_free_object, #elif KERNEL_VERSION(5, 11, 0) >= LINUX_VERSION_CODE // In 5.9 and 5.10 this is called gem_free_object_unlocked .gem_free_object_unlocked = evdi_gem_free_object, // Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead #endif #if KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE // In 5.11+, this is set in the object instance .gem_vm_ops = &evdi_gem_vm_ops, #endif
Should the middle elif be 5.10, as per the comment?
/* gem hooks */ #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE // In 5.9 and below we have gem_free_object .gem_free_object = evdi_gem_free_object, #elif KERNEL_VERSION(5, 10, 0) >= LINUX_VERSION_CODE // In 5.9 and 5.10 this is called gem_free_object_unlocked .gem_free_object_unlocked = evdi_gem_free_object, // Note that gem_free_object_unlocked no longer exists in 5.11 - it needs to be added to the gem object instead #elif KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE // In 5.11+, this is set in the object instance .gem_vm_ops = &evdi_gem_vm_ops, #endif
As I just built it on
5.11.0-1-git
, but only after changing that line.
Based on my original patch and the comment I wrote, I think you need to change the middle elif to this:
#elif KERNEL_VERSION(5, 11, 0) > LINUX_VERSION_CODE
// In 5.9 and 5.10 this is called gem_free_object_unlocked
ie use strictly greater than (>) instead of greater than or equals to (>=) so that it will build on all versions of kernel 5.10.x.
I just tested this branch on a displaylink monitor with kernel 5.11 and it works fine until I try to change anything like the monitor resolution or layout, at which point the entire laptop locks up and I have to power cycle it. :(
I also tried installing this branch of evdi on Ubuntu's linux-image-5.8.0-43-generic and it fails to boot. Removing it from the dkms tree allows it to boot again. Has anyone else tried this?
Mine locked up on the first make install, power cycled, haven't locked up since, smooth sailing.
On 5.11.0 using https://github.com/sickcodes/evdi/tree/rockorequin-sickcodes-microhobby-patch-1.7.x
Do I need to change anything in https://github.com/DisplayLink/evdi/pull/256?
Mine locked up on the first make install, power cycled, haven't locked up since, smooth sailing.
Was that on kernel 5.11, or on 5.8, or both? My 5.11 boots fine but not 5.8.
On 5.11.0 using https://github.com/sickcodes/evdi/tree/rockorequin-sickcodes-microhobby-patch-1.7.x
Do I need to change anything in #256?
I feel that at line 100 the comment should reference kernel 5.8 instead of 5.9, because that is what the #if is testing for.
99: #if KERNEL_VERSION(5, 9, 0) > LINUX_VERSION_CODE
100: // In 5.8.x and below we have gem_free_object
Have you tried changing the resolution of the displaylink monitor or the layout (eg move it to above instead of to the right)? This caused my laptop to lock up with 5.11.
Yeah it does lock me up 😅
I have two DisplayLink devices.
If I change one of the resolutions, that screen freezes at the last frame.
Then I changed the second screen and PC locked up.
My Xfce session starts the displaylink service, and is otherwise disabled, which helped me get around a bug in 5.9 arch edition of evdi.
So I have to set it up the way I like it, freeze up, reboot and I'm good.
Buggy but at least they work when they have the right resolution at runtime! Would be cool if some DisplayLink staff would participate in this discussion 😅
Okay so if I disable "Automatically enable profiles when new display is connected" I'm able to play with one of the screens settings while it is inactive. Didn't lock me up when activated.
When using only one monitor, #256 seems to work perfectly.
When I try to enable two screens at once or try to enable a second screen (after successfully enabling a first screen), I get the same error where my laptop locks up and the screens freeze at the last frame.
What happens if you compile against a kernel that has CONFIG_DRM_LEGACY off?
#ifdef CONFIG_DRM_LEGACY
/* Everything below here is for legacy driver, never use! */
/* private: */
int (*firstopen) (struct drm_device *);
void (*preclose) (struct drm_device *, struct drm_file *file_priv);
int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file *file_priv);
int (*dma_quiescent) (struct drm_device *);
int (*context_dtor) (struct drm_device *dev, int context);
u32 (*get_vblank_counter)(struct drm_device *dev, unsigned int pipe);
int (*enable_vblank)(struct drm_device *dev, unsigned int pipe);
void (*disable_vblank)(struct drm_device *dev, unsigned int pipe);
int dev_priv_size;
#endif
this stuff doesn't exist from the kernel side, but you still access it.
What happens if you compile against a kernel that has CONFIG_DRM_LEGACY off?
#ifdef CONFIG_DRM_LEGACY /* Everything below here is for legacy driver, never use! */ /* private: */ int (*firstopen) (struct drm_device *); void (*preclose) (struct drm_device *, struct drm_file *file_priv); int (*dma_ioctl) (struct drm_device *dev, void *data, struct drm_file *file_priv); int (*dma_quiescent) (struct drm_device *); int (*context_dtor) (struct drm_device *dev, int context); u32 (*get_vblank_counter)(struct drm_device *dev, unsigned int pipe); int (*enable_vblank)(struct drm_device *dev, unsigned int pipe); void (*disable_vblank)(struct drm_device *dev, unsigned int pipe); int dev_priv_size; #endif
this stuff doesn't exist from the kernel side, but you still access it.
Not only access, but assign values, e.g. asigning the enable_vblank
and disable_vblank
methods. This overwrites memory beyond the end of the struct drm
. The kernel code which would use them is compiled out anyway when CONFIG_DRM_LEGACY=n
, so even if they could be assigned there is no utility in doing so.
It is dangerous to add -DCONFIG_DRM_LEGACY
to the cflags. Any build errors which this fixes need to be fixed some other way.
Can confirm lockup when activating second display --right-of eDP-1
using Dell D6000 docking station, using any 5.11.x kernel image, including the evdi
patches in the foregoing discussion.
Using only external display without built-in laptop display does work, but delivers extremely dismal video performance; adequate video performance is only possible when the primary built-in display is also on.
Ready and able to test!
origin/devel
origin/v1.7.x
origin/master