Stage & Mainline the driver #25
Comments
|
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. |
|
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, |
|
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 I don't particularly feel like going into this project spending more time trying |
|
As things stand now, I've been completely unsatisfied with the current driver I even tried seeing if I could fix my problem myself. After tearing through the I'm pretty frustrated by the whole ordeal. I dropped US$400 for my 2 monitors So seriously. Please. Full documentation for the DL series chipset protocol, so that we can write our |
|
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:
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:
|
|
@evelikov, thank you. I had the same line of thought, but couldn't figure out a EVDI isn't exclusively for DisplayLink devices in theory. In practice, that's |
|
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
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= 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
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. |
|
@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 We need an open-source userspace side before EVDI can be mainlined. It just Plus, DisplayLink as a whole has been doing an abysmal job of supporting all of There just aren't enough maintainers on DisplayLink's side to fix the problems I really want to see progress on this. I want to be able to use the displays I |
|
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 (And for anyone that cares, my USB ID is |
|
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 Actually answer the question please. Even if the answer is "we like our secret To anyone that frequents mesa-devel and/or anywhere else Dave Arlie frequents: |
|
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. |
|
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. |
|
@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. |
|
@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 :) |
|
@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 @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 |
|
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:
I am reasonably optimistic about our chances:
@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. |
|
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. |
|
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, |
|
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. |
|
@displaylink-mlukaszek @DisplayLink-Admin Any update? |
|
@displaylink-mlukaszek @DisplayLink-Admin Any update for 2018? |
|
how can I down displaymanage code. |
|
run on arm64 aarch64-linux-gnu-gcc debain 9 |
|
I was thinking buying one but having no open source driver/utilities makes it a no-go. |
|
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! |
|
Up. There is any progress on this? |
|
Wow, what a disaster. No open drivers for a dongle advertised as Linux compatible (without the caveat of binary only drivers mentioned once!)? Mulitple of these are going straight back to Amazon at sellers expense as "Not As Described". Hopefully enough of that and DisplayLink will either stop selling (allowing a competitor to make a proper product and driver) or bother to open and mainline their driver stack. |
|
I understands its abit offtopic (@savoiringfaire) as you said but I found this issue via google. It saddens me to read all these comments. As I just bought a dock and two monitors; I just had a full morning of frustration, finding out this whole mess is heartbreaking. |
|
Could you guys please make FOSS driver happening? Why would you need the community to pick up? At least the kernel driver might be your job. |
|
no, it has been several years. buy better hardware and forget about EVDI. |
Any recommends? |
|
A discussion, that went out of time. DisplayLink was nice, but that's the past. Today most notebook comes with Alt-DP or some intel driven notebooks supports for thunderbold. For today's notebooks .. there is no need for displaylink anymore, there is no reason to collect and serialize parts of the video ram and send it over USB to another VRAM, that is connected to a display. From my point of view, Alt-DP or DP is a the bettersolution to rerrange and render data to one ore more displays. You can use this technique with a MST Dockingstation or it in future by daisy-chaining monitors with a DP over USB cable. Well i did not recognized Alt-DP when i purchased an expensive DisplayLink docking station, that was not able to work with Linux and my AMD CPU. I spent 370€ (~300$) for nothing and i was sadly surprised that DisplayLink was still praying for their non existing linux support ... what a bummer. Half a year ago i dropped the DisplayLink docking station (my investment ruin), because the support for Windows was also shitty. I heard of Alt-DP / MST and i purchased a much cheaper MST Dock with better results. |
What Alternative do I have for MacBooks except for DisplayLink? |
|
I do not know Apple, but both MacBooks should come at least with a USB-C DP port or Thunderbold-4 ... so why chose an expernsive and inefficient solution? Check out the specs of the notebook devices. DisplayLink is the solution for older notbooks. |
Since you cannot connect more then one display. I could use two docks but my boss would decline this even if 2x 100€ docks is cheaper then 1x400€ Dock |
|
Thats nonsens, with ALT-DP you can split the monitor signal to multiple devices. On my Lenovo notebook i was able to run 3 4K display over one Alt-USP connector. Look at this cheap solution: |
|
FWIW, #361 would never occur if the kernel code was upstream. (I am not touching on whether the current code is actually acceptable to upstream, for reasons all apparently discussed above already) |
and others
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.
The text was updated successfully, but these errors were encountered: