If you’re switching from displaylink-mod, get rid of that from the kernel modules directory first, or both udlfb and it may try to load.
Displaylink driver linux install#
Then “make sudo make install sudo depmod -a” as usual. There’s lots of room to optimize further yet, but this opens the possibility of not needing a custom X server at all for displaylink hardware, which would simplify the linux distribution rollout strategy. This makes for easier performance testing and workaround testing for X server specific problems.Īnd where previously, the fbdev driver was much slower than the displaylink custom (90% slower on some tests), it’s now within a few percentage points of difference – often not enough to notice. We now have a single kernel framebuffer driver that can support either roberto’s custom X driver (“displaylink”), or the standard fbdev X driver (“fbdev”), just by switching the “driver” line in the “server” section of nf.
That work isn’t completely done, but it’s at a working milesone. So the goal has been to merge the best aspects of both codelines - and get them merged into the kernel.
Displaylink driver linux drivers#
So drivers like the existing xf86-video-fbdev won’t work.īy contrast, Jaya Kumar’s defio-based DisplayLink codeline does work with xf86-video-fbdev or any standard fbdev client, but hasn’t been competitive performance-wise. Unfortunately, these drivers won’t work with standard frambuffer clients that use a mmap’d framebuffer, because they’ll simply never refresh any area of the screen without damage notification. All the directions on the wiki have pointed to these drivers so far. They’ve relied on Roberto’s custom X server, with some custom IOCTLs, to make use of precise X damage information. Of the three DisplayLink Linux framebuffer driver lines, udlfb and displaylink-mod (written by Roberto DeIoris) have had the best performance by a significant margin. You can now get a version of udlfb with improved performance and support for any fbdev client.
0 kommentar(er)
