Stage & Mainline the driver

[victoredwardocallaghan]

Hi,

This is a really annoying way to get hw going in 2016+. Can DisplayLink please possibly get this module into staging of the mainline kernel tree so the various distro's such as RHEL (used here) will automatically pick it up.

Kind Regards, Edward.

[displaylink-mlukaszek]

We'd love to, but this requires support from community - sadly, so far nobody created an open-source client application for libevdi, and I'm not sure if we would be successful with finding supporters on dri-devel mailing list with only closed-source client. We're hoping to improve the documentation for the library so it explains how easy it is to write a client. We can also release bindings in other languages if they make it easier for someone to use the library.

[victoredwardocallaghan]

@displaylink-mlukaszek Hi

You may notice my name around mesa-dev and dri-devel ;)

I could possibly write a userland component but the kernel side which is what I am talking about here needs to be in shape and accepted into staging at least. I could possibly talk to David and we could collaborate further if you can make a bit more clear exactly what you mean by "community support" and what the expectation is there?

Cheers, Edward.

[displaylink-mlukaszek]

OK, great :)

If the current shape is not good enough, do let us know how to change it - we've recently been working close with Google on native Chrome OS integration project so I hope things improved already - as in, coding standards should be fine, stylecheck is run as part of integration tests, and the module can be compiled with all recent kernel versions (see Travis job). Having said that, there may be more requirements for the module to be accepted, which I am not aware of.

By community support I mean proving that this module is also needed for someone that does not want or need to use DisplayLink client app (or DisplayLink hardware), but generally needs the ability of getting an extra screen in userspace apps easily - which this project is all about. This probably just means developing a truly useful client for evdi, with fully opened code. What I personally had in mind was a GStreamer source plugin talking to evdi - as it just seems a perfect match that would give flexibility for someone constructing any pipeline he/she needs - and should be relatively quick to develop with just autovideosink for testing. If someone would be willing to take on the development effort of such plugin, that would be awesome.

I believe the quality of multiple monitor support could get much better in Linux if it gets really easy to manage multiple screens. Currently, it is still possible to experience some teething problems when you start to play around with 2-3 extra screens. With the variety of choice for components that could be part of the graphics stack in different distros (and so many variations of their versions that you can get) we simply cannot fix every single use case for multi-monitor setup without community's help.

[RobertCochran]

I wouldn't mind working on an open source client (especially because DisplayLinkManager does not currently work for me), but I would like protocol documentation for the DL-[345]xxx series devices.

I don't particularly feel like going into this project spending more time trying to figure out what to feed the display than actually programming, especially given that most avenues of doing so are legally risky as they are considered 'reverse engineering' which is explicitly prohibited by your EULA.

[RobertCochran]

As things stand now, I've been completely unsatisfied with the current driver situation. I've never had any hardware, either free or proprietary drivers, totally fail to work under Linux in the 5 or 6 years it's been my primary OS. It's not even the common case of 'only partial support' (like most non-Intel GPUs for hardware-accelerated rendering). Nothing at all.

I even tried seeing if I could fix my problem myself. After tearing through the evdi module and libevdi, I ended up getting to a place where I couldn't progress any further because there's no source code available for the DisplayLinkManager. So I posted on the forum... where my post has been sitting practially ignored for over a week. I'm not the only one either. Most of the threads created from 7/29 on have no replies.

I'm pretty frustrated by the whole ordeal. I dropped US$400 for my 2 monitors and I can't even use them because the driver doesn't work for me. Support has been pretty poor too. If the situation doesn't improve within a month or so, I'm thinking heavily of selling the displays off to try and recoup my (so far) total loss on this purchase, along with warning the people I know not to waste their time and money on DisplayLink equipment as things are now.

So seriously.

Please.

Full documentation for the DL series chipset protocol, so that we can write our own driver, and then maybe I can finally use the equipment I paid for. As frustrating as this situation has been, I will be completely satisfied if we get that documentation, or better yet, working open source driver code.

[lehn-etracker]

I've the same problem. Since April, I'm using a D3100 docking station with a XPS13 notebook. The DisplayLink is very unstable under Linux. Since my system gets updated to kernel version 4.7 the DisplayLink is completely broken. I had to switch to a Thunderbold3 adapter (for 18€) which worked out of the box.

[displaylink-mlukaszek]

The point is, EVDI is not a project that's exclusively for DisplayLink hardware, and the stage/mainline request above is for the module - to become part of the kernel, without having to get sources from an external repository. This obviously makes the thing easier to maintain, as for example all the changes in DRM will also be automatically be reflected in the code of the driver.

DisplayLink Ubuntu driver is just one example of a client that uses EVDI - problems with DisplayLink hardware on particular Linux systems are best handled via DisplayLink support page or the Linux Forum. I'd like to keep the GitHub project page strictly for open-source EVDI and libevdi parts.

[evelikov]

@displaylink-mlukaszek your arguments make me wonder.

So one decided to come up with EVDI which isn't exclusively for DL hardware:

• yet it seems like it currently is :-\
• (from the discussion here) there seems to be no communication/guidance with projects. Yet there's expectation that related projects will just write some code to work with EVDI.
• (again solely based on this thread) there is no discussion with users (other projects) about the design, usability, etc of the API.

So all the above feels like "Here we made something, you should be able to use it for your hardware and/or even use it. Just that we did not bother asking you (the user) if the design is good nor are we willing to write some code to get you interested". This is not how open-source works, I'm afraid.

Here is an example based on my experience:

• Describe a problem and propose a solution
• Discuss with possible interested parties and get them hooked up
• Design both kernel and userspace, taking into consideration others' input.
• Get things merged.

[RobertCochran]

@evelikov, thank you. I had the same line of thought, but couldn't figure out a constructive way to express it.

EVDI isn't exclusively for DisplayLink devices in theory. In practice, that's effectively what the case is until we have support for other hardware in place.

[displaylink-mlukaszek]

Well, to me this is exactly how open-source works, and what makes it possible for community to move quickly, rather than designing something for months upfront. We had some working code which we believed can be useful for something else too, and we had no problems with sharing it with the community - so we've done it.

I strongly believe it's easier to discuss the design having something real in front of you, and since we're not claming the API is frozen, or the design is set in stone, there's nothing stopping us from making changes, even drastic changes.

You are right that at the moment, to my knowledge, DisplayLink is the only user of evdi/libevdi in practice (for Ubuntu and Chrome OS drivers) - however, I am hoping this will change now when a first version of libevdi API documentation is up and running :)

We're still missing working code samples for a complete client app, but I expect this to change soon.

[phedders]

Mlukaszek - Quick questions 1) What other hardware do you see using the EVDI code? At the moment it would seem to be only display link hardware, so lets get a working displaylink userspace! 2) Why can't the displaylinkmanager code be open sourced? That seems to be the biggest piece of the puzzle for ordinary users (like me) and the biggest stumbling block. I can't find any documentation for it, any debug/logs or any reason why it isnt working for me with a DL-39xx.

Thanks

NB So lsof shows me that DisplayLinkManager is writing to a log file. Great. Here is what it logs:

UVLY+3xs9LIslFFJL9zz9ZX/E8tch0h1gXBEL4FgoejQ9yQ/0abH8BYtlJeU1ADcXJJn+z9cN98QSvQfj+aCJuFUAXtmdPaWdfrAr7JX8ZYO/5oDPVqKhESMZETWBZEqo5bzx5rExhcFigMqMrCuj8D6BKCbg/71WRqfPE2byr3piQCEMKajuBfXmYoYzX6hdDUGkgA8nUd6PrfUeZTmLRTkGrTcO4y2B5RLEiw54VdUG4ABQI/ttIbzK3i8oPA0k0qpsoYXyB8k/mN9AqBedRAnxMe7LpuysiM0fwtfi1TH8vCpOKFpV8hFm+U2VB8DsNXN1BYuVLAZw7gqJdabm3zE9i5Psd1Sc5A3ubSenbITQrJlQU1lMEQQZos7AupVYCFR27Q7TMFShKdc0RYE22E94s0PLZU2IB12I9BmF0k= F6ny/x7M/S/F1fu0oS2K41N6UjYcGCCUMQaRyMoa7wnoiqev+QpQwvpd33DhsU0fPIUlWVRawtF9A5JlPmVp7+bPSylgaWexPLcIifPWSn520iA4iVMxu+czNJKh5DWtKDnQYhBIiNPBhc7+dvZAEtnL5opqb41ztRxTKsAdEs/UXVgl42rp3/Ph8fA+6AHwdBIblI2t3IdSnFBUeM2D5UiDzrcCYYfJFuiim03H/yM= nL4TC2qWBc4VYcjAc441hY2YY2hqK5xW3An8KQ8qXhrLN/k8uhXczoFPyjMkqPHZx1p4uRm9NKUgIurTTHsKK8Fj590LeKB1KgR15OEcpnoarHIQiMXAlQ/VBunZzwyk1Olf91PMmrzT0v1RZOyPk7H4qudIeyWWCrTI+YaGV0xjmRs8NOJxT0yx8XmCDlICv8k/P3DAhZuodbd8eCuRtQ== nL4TC2qWBc4VYcjAc441hY2YY2hqK5xW3An8KQ8qXhrLN/k8uhXczoFPyjMkqPHZx1p4uRm9NKUgIurTTHsKK5Jqmr4zF6fg42HsUyj873p1wCiy0/n+F/iXaOTxDGost1oOHAKEDzcRJfT6tTYHQtY2X4U3BdgPjOZu2uco3anqAIj9NgwpEIkZPi+0f0XNSVg4cRw0oih17ZExcB3FJg== 4qXGV5Wi+TE9trBiFyMUDUe6Sbg74h04FhNMmHWfvTLFQ5d5Vs6kILoEnQvEf6N+jnZc8boBl6YK31RZ6VgXZG0XFD7CyFyZC2qWhAA8qH9RT2kp0pQqTcCWLluXwT6dHbuUlPsrkRIIwfnUCvObmjNeJSVaLTRFRxZrdTe1n2pDpa0S+U63C/OUmPvx3L3TrDimqfBQHT3Yh0ERu7+9Gw0RGW/gL0iNdjdWSeSriNq4byaSa1xVMaRwsCOta4ye6a0NG416wry5kntP/zMKPiMO+/NHQaOhsa1MgNRsTDiz+5pr32ywdkNF9Bo+9IREOmgmaU+NqHPARt3iUYqG/g== 1G2JyAkrPgv/ueMVOOIxM1+78WLuF7bWqRR0iOukxD8hQBxHYfCa5opGAAvRqFSC4Wi34Sc71mJr6Iym9VhnLZ26IZgCEgCq7Cg/rZ9e7WcO7dLqAjA+6r6kmPN/F9I6FlOXWsVMJHQXSgZwupVDVSM9UCvuXxhxGgI4bLCP7P4rnryV2bLeKvWuQo+tclUqjoXszvVmjcx676RRSc/JVQJK5jmu3MpNdVshqf8UsYE= UVLY+3xs9LIslFFJL9zz9ZX/E8tch0h1gXBEL4FgoejQ9yQ/0abH8BYtlJeU1ADcNKgiYb+5LUEaguvgxfT+7fHJ/Ja9EfdTnlYbgBqQlmzYQRmqQf2E0ljwYoDe44xWJI4+C/7b6ZldFPXLoxJAouULCgcT7N7M8FyZFgxA5t+DMsPdzjDP33dEoqUbWhor26DcG+GxHoCJ6yvxiel45tCsL9z8Cpk8Qf+nAPJobqpVQKhateke2sHvC98WD1qWrZMsYFHEZoY5525XRQ1nGQqXtOWHMGKZrpTIi+rS54niQvZCfI3FNbS2GZOVIFLt0+2+H2NiQ6QMm1ghqCR4ZZcjnRjvGIDXhgcre8vSrAqwh83WIPLpGWTxvuQC/25wp+y0is2uzLm2yU+QPys1nKQYY0pTZStb30VKF1LTxxM= Qf3pXNzWx9ziyuKN4IGgwdAb50r+S6FNYO4NOJaU67jO45kqoImIFdpDK4NP1PKZS83b7YmumFZUPaoFPzASOmqYoTB1rZADe5sq8ixieeSdHJpqKjRKeywzbwH9b03fskDjvBjr2IhhmFOp0ARapK5yZPAQEbgdj7iB8wqdm6/pGS9ugpXPucebQbHSCd1I kUcRD+e4Dk+z6zQBQ17w4tej2SRBAJdUDBMDA5aOD4dANErmul0/dtrTiJz9a7kKUSRnO0tNvBDvXAj9gvJfRba4LLjVH/ViOQQeloulsZZCZ9B11aRbupmokg4Tof6qchpJ5YOkDVpd57W6Jjr/TAdwDWAMuyv7rBeN/aQeNE2KX3Tmq1fS6cFO61QwhIhQeK6KNCQflYIkIUDSQt/eV9Ru2hMWXCVsqMAt+yTBBzb/s1KBhtkcurDjhhbIvS3REgFD/SWA2RyXkC3QOWjFVuy57WaSfnxaZHWf2ONTz5E= UVLY+3xs9LIslFFJL9zz9ZX/E8tch0h1gXBEL4FgoejQ9yQ/0abH8BYtlJeU1ADcwZ9p3GSY4anYkQ0/8tkEXWPq/IGzqVup7+iwIkyJOg+aDfAdOOXJo7sEVOkNtQfBq1PizR0cEL+yrQ9S2MTam0mUe6knrShLX3PiwoEflrfVDLwoBFeCSirHKhWnaZ2DGQhRD7neUNPydc8+UNKX7ykMp2JeFoFt+t1IjinVeOStpV0RQkgHA1pSH+sNafIzXPgQgG5NtrJhPu3+D5YwEefr4PKOC6VbwlZVXP5KUiYiRmnnCUepzlI9kU6q2bx5b/sdjcFeaSkPHDUQK8u+fDe5nKkbPqWzR8WF0A8cLPmvrqUr21FzsFKbM3LlLxGU90fdeFpDBNBBFcMWcpN5vPVNACU6xd+qiGO3032PYJI= Qf3pXNzWx9ziyuKN4IGgwdAb50r+S6FNYO4NOJaU67jO45kqoImIFdpDK4NP1PKZRc0WPe+n8fACq5LRSR6Y1hCnds7i548f/hnnanv0hQV807Q94KrLRylv46IadFFr3vWJt7F9RtGkTdr276UM3U8xQvCrt2GmUgLqsRk7Ptk5HiCKFQ6dsJE6YdjXI+aP kUcRD+e4Dk+z6zQBQ17w4tej2SRBAJdUDBMDA5aOD4dANErmul0/dtrTiJz9a7kKsuK8xZM6GO89ut93QGdqJBbVW5sglBCDNVkn+vmH89QLDpgpurfEsekKc+xtIybWT1z8tRYitreA3kUeZ9cY6HMikHBMJ4pljaJlgThNgdqkDlwGLlAks5m6vfO81mVXfSAKVQ3zUu/IYTKLdTa4inLbj9OWpKcS7lOmdYNNJQJmNDe4hGQQNHUBU+VhcQOlZKSuV4XsIQB272wnaGYC6F1BiinNhMllNMUan7ZjUt0= UVLY+3xs9LIslFFJL9zz9ZX/E8tch0h1gXBEL4FgoejQ9yQ/0abH8BYtlJeU1ADckDul6nS74M7BkEhJsm9RqfuZVHJKiT+bduj7qsLGurlQXmCJNo/d4x0C+2NuCFxs4H+SdjksfcuXOSaBAIi1obaJj9AXBqPOO4krDa0IzzrCvhdBNZYwtiAftARHMEsBiOUTBW1MZg/F0XQmSnuVJZ6WMoTiB2HWL6rEo5eyX4hZw2mO01WjbgnKhQKmBdbp75hnhHy9xGVZ5mPxk8gDeGWnFhZ0zmsRJiexIEQxACXkoO3xuyl+3Pv5G9EWHUuQ+QHATCjaYf1iMGo+MAOrgwqdeEqRNG8dJIAi1cgxjEgT16LOdZeZN/jEIE7EgoXTMKcRDA6jsLjQ9qLKqYJbkcVHSr/axvChr6BAFp5CL2g= F6ny/x7M/S/F1fu0oS2K41aR1n8URVQQ+ipS4NMLIkQoWhR5YEQMq2Tq5SP+RdIHo4CbdcvwB7J8kQnfFYNldGvUgZqUy7ma257EwqBzbWOWxO4cgd7VN8FTbruMRRO35poChUmJn4fkvYtsQa9bMKJDBuvqUR4vV8oFY66Tm512NhH6Ro8UPgfjCsd9oGgqxU/CmDgYMK07n0s5L2euXTVUBlMIWiHRM/y9bcD1VTg=

etc

What on earth is that all about?

[RobertCochran]

@phedders: I've heard that they're encrypting the logs for some reason. IDK why, because to me it doesn't seem justified.

I've been wondering also why only part of the driver is open-source. It seems like everyone invovled would greatly benefit with the DisplayLinkManager source code:

1. Users get a working open-source driver for their hardware
2. DisplayLink driver developers would be able to get the driver working on other platforms, improve support, performance, etc...
3. DisplayLink employees are no longer bogged down in doing all of the work on the DisplayLinkManager, which is important when the users-to-developers ratio is as high as it is!
4. 3rd party EVDI driver users have a good, actually-used reference driver to look at when they have problems using EVDI.

Obviously there's something important preventing DisplayLink from going through with it. Why else would only part of the driver be GPL?

[phedders]

@RobertCochran

Obviously there's something important preventing DisplayLink from going through with it. Why else would only part of the driver be GPL?

I think thats obvious. DisplayLink don't want to be too successful. They dont want those weird linux desktop users, and corporate servers, and embeded systems etc all using their chips because they would get far too rich or something like that. They prefer to be in a niche and dwindling desktop windows market.

Am I crazy or is it them.

Now to that other oddity - I've never heard of encrypted log files. Next supermarkets will be selling food with with added cyanide. Car manufacturers will be advertising cars with no wheels. Bikes will come supplied already locked with several chains and d-locks - but no keys.

It's been years since I came across such a backwards hardware manufacturer, pretending they "get it" - they've open sourced EVDI. Yey! Yet... its useless without the DLM. So no, they dont "get it".

[mlukaszek]

I hear what you're saying, but let me reiterate - this particular project does not include DLM, and will never be. I think we'll be publishing a FAQ article explaining the reasons for not opening the code of DLM together with the rest of the stack.

Meanwhile... as you may have already noticed, there's a new release for Ubuntu coming, which will use up to date evdi from v1.2.55 tag. Stay tuned. :neckbeard:

[phedders]

@displaylink-mlukaszek Thanks - could the FAQ also explain the encrypted logs - and how to disable them, since they are as much use as a jelly sword.

[Blind55]

I will also say that I am a rather disenchanted user of DisplayLink hardware under Linux. I will fully admit I did not know what I got myself into when purchasing a XPS 13 DevEd with the Dell dock - it was inconceivable for me that this wouldn't work, I guess. Using kernel 4.7.4, nothing will work. Before, things worked, but not very well. I suppose I can still use the dock as an ethernet dongle.

And I actually thought that the times of essential hardware not being supported well under Linux were about to be dead and gone....

[RobertCochran]

In all seriousness - what is keeping you from releasing the code to the DisplayLinkManager? What parts can you release to us, if at all?

We need an open-source userspace side before EVDI can be mainlined. It just doesn't make any sense to have a 'driver' that doesn't do anything without a proprietary userspace portion. No one would want to merge that. I wouldn't if I were the kernel hackers.

Plus, DisplayLink as a whole has been doing an abysmal job of supporting all of the Linux ecosystem. My displays still don't work on my Fedora setup, for example. That's forgetting the fact that users not on x86 (like those on Raspberry Pis, for example) are totally hosed - no userspace component period.

There just aren't enough maintainers on DisplayLink's side to fix the problems people are having. It's in everyone's interest -- DisplayLink and users alike -- to have an open-source userspace side. That way the community can take some responsibility and help with the driver, reducing DisplayLink's workload, and creating happier users, which is a win for everyone. If we had the source to the DisplayLinkManager, I'd have already fixed whatever my issue is and sent my patch upstream (months ago, now).

I really want to see progress on this. I want to be able to use the displays I bought for 400 USD 2 (nearly 3!) months ago.

[hogarthj]

Incidentally my DisplayLink USB to DVI adaptor with ID 17e9:028f now works out the box on Fedora 25 with kernel 4.8.3 using Xorg. It's using the kernel UDL driver and is a bit sluggish at times ... but my dead screen is now functional.

[RobertCochran]

The UDL driver? From what I've heard, the in-kernel drivers are for USB 2.0 DL devices. The driver and userspace portion we're talking about here covers USB 3.0. You must be using a USB 2.0 device, because my ASUS MB169B+ does not work with the udl driver.

(And for anyone that cares, my USB ID is 17e9:ff0b for my ASUS MB169B+)

[hogarthj]

apologies for raising your hope ... I was under the impression I was on a more recent device but after doing some double checking the chipset in this dongle is a DL-195 variety ...

the actual reason it wouldn't work previously, but did yesterday, is that I normally run wayland by default but it fell back to Xorg

[RobertCochran]

@DisplayLink-Admin @displaylink-mlukaszek:

Any word on my enquiry about what you guys can release?

[displaylink-mlukaszek]

@RobertCochran All I can say is we have published what we can at the moment. If anything changes, I'll be the first one to announce it here.

Meanwhile... a shameless plug :) a simple C++ wrapper for libevdi, and example apps (unrelated to DisplayLink) can be found in a little toy project I just pushed to my private GitHub: https://github.com/mlukaszek/evdipp

[RobertCochran]

Here we are, 2 months later. What's the scope, @displaylink-mlukaszek ?

[displaylink-mlukaszek]

Unchanged. We've added the KB entry here: http://support.displaylink.com/knowledgebase/articles/1104056-why-has-displaylink-not-released-source-code-for-t

[RobertCochran]

(Here I am, nearly two weeks later... I meant to respond to this eariler.)

That page doesn't answer the question. All it really says is a brief description of what DLM does, and that DLM code is shared between all supported OSes. So? What does that have to do with anything? Does supporting other OSes magically make something ineligible for being F/OSS?

Actually answer the question please. Even if the answer is "we like our secret sauce too much to share". It feels like the current answer was written to skirt around actually answering the question. Makes it seems shady and that DisplayLink has something to hide.

To anyone that frequents mesa-devel and/or anywhere else Dave Arlie frequents: whatever happened to the reverse engineer driver? No public progress in over 2 years... Can we get this started again since DisplayLink is dropping the ball here? I would totally throw money at this to be able to use the hardware I paid for (6 months ago now!!!)

[rhofour]

And now there's something else using EVDI: https://github.com/rhofour/evdi-vnc/tree/master

Is this enough to try and start getting this mainlined?

[carbinefreak]

How does the EVDI code base quality match up with the rest of the kernel? I'm a sideline coder with no clue on what this would take.

[daugustin]

If you run torvald's checkpatch.pl against a single file you get a lot of errors...

../checkpatch.pl --no-tree -f library/evdi_lib.c
[...]
total: 52 errors, 357 warnings, 467 lines checked

There is a rather lengthy codingstyle guide on kernel.org.

[RobertCochran]

@daugustin: in the grand scheme of things, failing to adhere to code style is unimportant, because that's not overly difficult to fix: run the source through indent or some other tool... barring that, you could do it manually, which wouldn't be too bad with a good editor.

But if @DisplayLink wants to get accepted, that's something they are going to have to do, you're right on that.

[displaylink-mlukaszek]

@rhofour Fantastic. Well done. @daugustin Not quite. The library code will show you errors, but kernel code is pretty much up to normal kernel standards - as checkpath is part of the Travis CI job (see https://github.com/DisplayLink/evdi/blob/devel/ci/run_style_check).

[seidler2547]

Trying to add a useful comment here: could it be that there are better chances of mainlining this if there was no requirement to use libevdi?

My reasoning behind that is two-fold: firstly, a kernel module that does nothing by itself until accessed by another library doesn't sound very useful. Secondly, removing the requirement for libevdi would make evdi easier to use.

I imagine something like the zram or the old dell_rbu module: you insert the module, then configure it using sysfs.

So for example:

modprobe evdi
echo add > /sys/devices/virtual/graphics/evdi/control
# now /sys/class/drm/card1 etc. appears
echo 2048000 > /sys/class/drm/card1/sku_area_limit
cat edid.bin > /sys/class/drm/card1/connect
# now /sys/class/drm/card1-VIRTUAL-1 appears
# buffer could be allocated by the kernel module or passed in otherwise?
# now the screen can be read/written using either
# /sys/class/drm/card1-VIRTUAL-1/buffer
# or /dev/dri/....

So basically map the libevdi functions to sysfs files. I think zram is a good example because it works almost exactly like that, virtual devices are created, configured at runtime using sysfs and then exposed as read/write block devices.

That's how I imagine it at least.

[kq01526]

It's also being requested on the forum and in other places, see:

http://displaylink.org/forum/showthread.php?t=65321

Maybe the forum has better visibility and is better for this request than GitHub?

[RobertCochran]

And with this prompting, I decided to try the drivers again after several months.

Still. Does. Not. Work.

I'm done now. I'm tired of trying to haggle for proper support for hardware I purchased months ago. Total garbage support from DisplayLink. I'm getting rid of my displays and swearing off DisplayLink products from now on. It's just not worth it anymore. I will be sure to advise against any purchases that contain DisplayLink hardware as a direct result of this utter lack of support.

[kq01526]

@displaylink-mlukaszek @DisplayLink-Admin

Are you watching this thread:

http://displaylink.org/forum/showthread.php?t=65321

?

[daxtens]

Hi,

I'm interested in helping with this - I was thinking the simplest way to go would be to write a userland application that uses libevdi to create a software monitor (a bit like Xnest or Xephyr). That would have value in itself as a good way to test multi-monitor support without needing lots of hardware. From that we could proceed to upstreaming the evdi driver. I agree it will probably be necessary to do some decoupling from libevdi along the way, but one step at a time.

Does that sound like a workable strategy? DisplayLink folks, would you be happy with that approach?

Regards, Daniel

[RobertCochran]

Except evdi is only acting like glue and isn't actually driving hardware.

I am 100% sure this will be rejected if the 'driver' does not actually drive hardware.

[displaylink-mlukaszek]

@daxtens that's essentially what one of the examples for evdipp, monitorsim (linked earlier) does - add a "monitor" in a window and show its contents. To Robert's point, there's nothing stopping anyone from writing a userspace app driving actual hardware (one possibility is to drive DL-1x5 devices using libdlo DisplayLink opensourced years ago), but I can think of examples that would be useful without any hardware - I already mentioned a gstreamer source plugin, so you can create various rendering pipelines getting screen data through evdi. Someone once said that evdi is something like fuse is for filesystems, but for drm - I think this analogy works well.

[daxtens]

@displaylink-mlukaszek Oh cool, I missed the link to monitorsim, I will check that out. I am really keen on getting this into mainline so I can go back to having secureboot; I think the combination the of those two factors should be more than enough, but if not I can try to find an old cheap DL-1x5 device.

@RobertCochran What are you basing this on? I can't find any history of you contributing to the linux kernel, and a quick google doesn't turn up any posts from you about device drivers. I suspect you are entirely wrong. More to the point, I'm happy to give this a shot and find out :)

[RobertCochran]

@displaylink-mlukaszek There is something stopping us - we don't have a reference driver nor specs to drive the USB 3.0 DisplayLink devices. Literally the single application for evdi that myself (and probably others) are interested in evdi for - driving my DisplayLink devices - has not been solved in an adequate fashion. No, DisplayLinkManager is not adequate. It does not work for me; it never has worked for me. I tore through evdi once in hopes of fixing it, but the problem wasn't in evdi. DisplayLinkManager is probably still not sending the proper ioctl, for whatever reason, on my machine. And had it been F/OSS to begin with, I would have fixed it back in August when I first bought my display equipment and I'd have been a happy customer. Instead, I could do nothing about it, and sat twiddling my thumbs trying to get DisplayLink in general to support me while watching my $400 worth of equipment sit gathering dust because I couldn't use it. I fundamentally agree that evdi could be used to power cool things in the future, but I care exactly nil about those future things until my hardware works.

@daxtens You're right, I don't have a history in either space. I've seen how some maintainers operate, though. I'm basing my gut feeling on this message from Dave Arlie, a DRM subsystem maintainer, about AMD trying to push code that was more HAL than driver. And evdi is 100% HAL. Ignoring that - even if you managed to get evdi mainlined, see above: the hardware that this HAL was made in mind for won't suddenly start working, which has been the core to my dissent all along.

[daxtens]

I've forward-ported the driver onto linux-next (there are upcoming changes to the DRM API). I've put my work up at the evdi branch at https://github.com/daxtens/linux. I've verified that it still works with my dock.

I want this process to also be helpful for you guys (@DisplayLink-Admin, @displaylink-mlukaszek), so I will clean up those changes and make a pull-request for this repo as well. I'd like you all to be on board so I want to make sure you're getting value out of this process.

After that, the next steps will be:

• clean up the in-tree source (remove version-specific macros, etc)
• make sure the driver is using the most current APIs (and backport those changes onto this project)
• ensure the module provides an interface that makes sense, make any necessary tweaks
• submit an RFC to the kernel community

I am reasonably optimistic about our chances:

• this doesn't complicate any other driver (unlike the AMD HAL @RobertCochran mentioned)
• it allows displaylink users to secureboot - this is my primary motivation
• there are uses (or at least ways to test) without displaylink hardware.

@RobertCochran - I would love to get a FOSS (or at least less broken) DL driver; I have a Lenovo USB3 dock and I'm fairly disappointed with how it works under Linux. However, given that the EULA for the DisplayLinkManager prohibits reverse engineering the software, this process will take some time, and I'd like to be able to secure boot in the mean time.

[hifi]

I think I found the reason why DisplayLinkManager can't be opened, the chips are advertised as "Compatible with HDCP 2.0 encryption".

I'm guessing having open source support for the latest generation chips would open up raw access to HDCP content before encryption happens. This could be a design flaw in the chips how it's implemented and they try to keep quiet about it.

USB-C will most likely kill DisplayLink over USB so we can all hope this transition will be fast and we can soon forget this hardware ever existed.

[daxtens]

Hi,

I eventually got an adaptor that uses USB-C and doesn't need this driver. As such, I won't be able to help any further - sorry.

Regards, Daniel

[RobertCochran]

Yeah, I'd given up quite some time ago. One of my panels is busted (and ASUS wouldn't warranty it) and I gave away the other one. So I have no real reason to care anymore.

[kq01526]

@displaylink-mlukaszek @DisplayLink-Admin

Any update?

[kq01526]

@displaylink-mlukaszek @DisplayLink-Admin

Any update for 2018?

[linshenghuan123]

how can I down displaymanage code. not evdi . I want insmod evdi.ko and step by step install drive.

[linshenghuan123]

run on arm64 aarch64-linux-gnu-gcc debain 9

[rbalint]

I was thinking buying one but having no open source driver/utilities makes it a no-go.

[savoiringfaire]

I'm a little late here, but I think a lot of posts have been missing the point a bit (as I understand it anyway!). As far as I can tell, EVDI is a library to allow programmers to create 'virtual displays' in Linux Userspace.

The problem that this thread started with is that the only current user (which isn't to say the only useful purpose) of this library is the closed-source displaylink drivers. Obviously, this isn't going to do it any favors getting it mainlined, so @displaylink-mlukaszek was hoping someone would write a useful client for the library which has community support (which in turn, hopefully, would mean that some of that support back-propagates into this project).

The only relevance that the closed-source displaylink drivers (or dell docks) have to the discussion as I see it would be for documentation purposes on how to use the EVDI library. Not that a lot of the comments here aren't valid, they just aren't relevant for this particular Github issue AFAICT!

[MrSorcus]

Up. There is any progress on this?