evdi
evdi copied to clipboard
DisplayLink
Stage & Mainline the driver
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.
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.
@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.
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.
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.
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.
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.
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.
@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.
@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.
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.
Mlukaszek - Quick questions
- 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!
- 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?
@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:
- Users get a working open-source driver for their hardware
- DisplayLink driver developers would be able to get the driver working on other platforms, improve support, performance, etc...
- 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! - 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?
@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".
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:
@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.
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....
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.
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.
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+)
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
@DisplayLink-Admin @displaylink-mlukaszek:
Any word on my enquiry about what you guys can release?
@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
Here we are, 2 months later. What's the scope, @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
(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!!!)
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?
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.
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.
@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.
@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).