Arch Linux User Repository

$ uname -r 4.4.1-2-ARCH It seems that after every kernel upgrade, I have to: * wait for the kernel headers to be released (do NOT upgrade the kernel until headers are released). e.g. linux-headers (4.4.1-1 -> 4.4.1-2) this time around. * pacman -Syu (it MUST include the linux-headers that matches the to-be-upgraded kernel) * Reboot (which is required for the new linux-headers to be picked up) * evdi.ko module will fail to load, DisplayLink service will fail to start * pacman -R displaylink * rm -rf ~/build/displaylink (required cause you need to force a rebuild) * git clone https://aur.archlinux.org/displaylink.git ~/build/displaylink * cd ~/build/displaylink * makepkg -sri ...and let it build and build a new evdi.ko module. evdi.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /usr/lib/modules/4.4.1-2-ARCH/kernel/drivers/gpu/drm/evdi/ Now, systemd can start the displaylink.service module again. Is this expected each time the kernel is upgraded? Is there a way tie into the kernel build process to move this "evdi.ko" module over to the new one? Maybe it needs to be installed somewhere else, that is more compatible with system upgrades and not tied to a specific kernel version? -- EDIT: created a discussion thread about placing the evdi.ko somewhere else: https://bbs.archlinux.org/viewtopic.php?pid=1601302 ...unless it must be rebuilt after every kernel upgrade. If that is the case, then this package needs to be updated after every kernel release.

@asch I'm on Xorg-server 1.18.0-3 and I confirm it doesn't work with my AOC LED USB3.0 (using USB2.0 is working though but it's a bit slow). Better than downgrading to xorg-server < 1.16.0, aren't there any other solutions?

Recent version of this binary DisplayLink driver is not compatible with recent version of xorg packages because of ABI changes. I propose to add conflicts as follows: conflicts=('xorg-server<1.16.0' 'X-ABI-XINPUT_VERSION<21' 'X-ABI-XINPUT_VERSION>=22')

@halfur, The reason linux-headers and linux-lts-headers are both optional dependencies of dkms is because you can have either one installed, or even a third-party linux-*-headers package. Making it a dependency of this package would force people that are using other kernels to install a package they don't need. This is the way that all dkms packages, such as nvidia-dkms, handle this. I'll make them optional dependencies in the next release.

"linux-headers" should be added to the dependencies, it's only an optional dependency of dkms, but is required for installing this package after building.

I just released a new package version that should fix the issues installing this package with AUR Helpers. @ryanvade what kernel are you using?

I can't seem to build evdi. Oct 05 10:33:36 ryanvade-arch modprobe[7339]: modprobe: FATAL: Module evdi not found. DKMS is not building the module.

@Hideaki, I think you try to ask this question in this ticket https://github.com/aurapm/aura/issues/351 I'm not a aura expert, but they are (or should be..)

I haven't tested AURA, only manual builds and yaourt. What does AURA do differently? It looks like its failing to extract displaylink's .run package during the build section. Should I move that to the package section?

For those using AURA run aura with the -x statement, so for example aura -Ax displaylink This has to do with some unusual statemens in the package() part. More info here https://github.com/aurapm/aura/issues/351