displaylink-devel Mailing List for displaylink
Brought to you by:
echtler
Menu
▾
▴
displaylink-devel — Displaylink driver development
You can subscribe to this list here.
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(19) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: Sven K. <sv...@ki...> - 2009-06-25 11:46:29
|
I bought the first available DL-195-based USB adapter http://shop.lenovo.com/SEUILibrary/controller/e/web/LenovoPortal/en_US/catalog.workflow:item.detail?GroupID=38&Code=45K5296¤t-category-id=F518DEACD67248538629B17343AFFB25 and grabbed the modeline for my Samsung SyncMaster 244T @ 1920x1200x60: 05CA2115426C15F466C536FFFF6C150780A335FFFFFFCA04B004025078 dldemo (and therefore SlugTerm DL) work nice with it :-) Interesting: the "05" at the beginning. Has perhaps something to do with the new DL 2+ Compression? The Windows XP driver was in 24 bit mode. The encryption key has changed, too. This and the EDID and logs can be found at http://sven.killig.de/DisplayLink/DL195 |
|
From: Florian E. <fl...@bu...> - 2009-05-17 08:05:58
|
I have to admit that DisplayLink's behaviour until now didn't really raise my hopes for real openness, but let's see. > - More flexible mode setting, to replace the current fixed tables I can partly understand why they encrypted/obfuscated the mode tables: so that people don't play around with the parameters and destroy their monitor in the process. However, I think that's not really a smart solution in any case - just let everybody decide on their own. > - Support for a compression method that didn<92>t make it originally. > Note: this addition won<92>t affect the libdlo.h API. Hmmm. Maybe I'm really too paranoid by now, but note that he said "a" compression method. They have different ones, particularly also a sort of run-level encoding [1]. So I wouldn't be surprised at all if they put in RLE in their next release and loudly proclaim that it now also supports compression. Thinking about it, I suppose that this compression may even be quite suitable for desktop applications which tend to have large flat areas. Maybe you should consider this for your driver, Roberto. Final question: would you like to host your driver at the Sourceforge site? If so, tell me your sf.net account and I'll add you to the project. [1] http://floe.butterbrot.org/displaylink/doku.php?id=alternate Yours, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_." |
|
From: Roberto De I. <ro...@un...> - 2009-05-17 05:46:23
|
-- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Roberto De I. <ro...@un...> - 2009-05-16 06:11:47
|
> > > Roberto De Ioris schrieb: > > Sadly the library is 99% useless, without compression no one can > write a usable driver. > > Are you sure? I'm quite amazed of the speed in 16 bit mode. click on the > image on the site above to see what I mean. For "usable driver", i mean something that can be used to extend desktop, play videos at good frame rate and a lot more things. I am writing a linux framebuffer driver, in a couple of day it should be usable and i will post it. I would prefere (as you) a user-space approach, but i think (for now) the priority is use the displaylink devices to extend desktops so a (problably) slow framebuffer driver is better than nothing. Roberto |
|
From: Sven K. <sv...@ki...> - 2009-05-16 02:33:09
|
stupid Outlook! dis...@li... schrieb: > Thanks to Marcus, we already haven an OpenBSD console driver, BTW! wow! I made something similar, but in user space, since I didn't have the heart to do it in kernel land: http://sven.killig.de/openwrt/slugterm_dl.html > Now the > only big thing still missing is the compression. I'd like to ask you a > favor: could those of you who have already tried sniffing their own DL > devices send me a decrypted version of the 4,5 kB binary blob transmitted > by the Windows driver at startup? I'd like to see whether this is always > identical.. Mine's available here: http://sven.killig.de/DisplayLink Roberto De Ioris schrieb: > Sadly the library is 99% useless, without compression no one can write a usable driver. Are you sure? I'm quite amazed of the speed in 16 bit mode. click on the image on the site above to see what I mean. |
|
From: Florian E. <fl...@bu...> - 2009-05-15 13:59:30
|
> Sigh, pretty disappointing. LGPL licensed first and then it doesn't > contain the compression stuff. What do the think how people can > write an usable X.Org driver with this? I gonna ask them. All right, this is getting a bit ridiculous. Looking in dlo_usb.c, they labeled the "set encryption" request as "select channel", and the "null-key" for disabling encryption is called STD_CHANNEL. Okay, maybe just terminology. However, in dlo_data.h, there's suddenly always an DLO_MODE_ENABLE_* sequence (never seen that before), and the DLO_MODE_DATA stuff looks totally random. Hey, look, in mode_select(), it's always sending the ENABLE sequence to the "select channel" command, then the binary blob and then DLO_MODE_POSTAMBLE. Hmm, this POSTAMBLE looks just like the STD_CHANNEL default key! Oh, what a surprise, the register sets for the modes are _still_ encrypted - never mind that we can decrypt this since Christmas last year. Displaylink, I really don't get this. I'll have a closer look at the way the stride registers are implemented; this is one of the smaller parts which I still would like to figure out, but in general, this library is absolutely useless to the wider opensource community. It's obviously designed for some embedded shops which want to use it for non-realtime stuff like LCD signs etc., but it's just ridiculous to still try and obfuscate parts of an opensource library. Florian -- 0666 - Filemode of the Beast |
|
From: Marcus G. <mgl...@op...> - 2009-05-15 12:37:28
|
On Fri, May 15, 2009 at 01:00:40PM +0200, Florian Echtler wrote: > > > Nice. Looks like this is something one could work on. But yes, it > > > does not cover the compression but at least provides a good basis > > > for the initialization stuff for different screen modes. > > Sadly the library is 99% useless, without compression no one can write a > > usable driver. > So they basically didn't release much beyond the stuff which Chris and I > already found out.. not very open. > > > I will continue to reverse engineer the windows driver. > I could send you a IDAPro project with some of the method names already > filled in. Chris maybe has one, too.. Sigh, pretty disappointing. LGPL licensed first and then it doesn't contain the compression stuff. What do the think how people can write an usable X.Org driver with this? I gonna ask them. |
|
From: Florian E. <fl...@bu...> - 2009-05-15 11:03:24
|
> > Nice. Looks like this is something one could work on. But yes, it > > does not cover the compression but at least provides a good basis > > for the initialization stuff for different screen modes. > Sadly the library is 99% useless, without compression no one can write a > usable driver. So they basically didn't release much beyond the stuff which Chris and I already found out.. not very open. > I will continue to reverse engineer the windows driver. I could send you a IDAPro project with some of the method names already filled in. Chris maybe has one, too.. Yours, Florian -- 0666 - Filemode of the Beast |
|
From: Chris H. <ch...@pl...> - 2009-05-15 07:52:04
|
Roberto De Ioris schrieb: > The library is online: > > http://www.freedesktop.org/wiki/Software/libdlo > Nice. Looks like this is something one could work on. But yes, it does not cover the compression but at least provides a good basis for the initialization stuff for different screen modes. But this is a joke, right? /** Constant used for deciding if a host is big- or little endian. */ const uint32_t endian = 1; /** Return non-zero if the host is big endian or zero if the host is little endian. */ #define IS_BIGENDIAN() ((*(char*)&endian) == '\0') /** Convert a 32 bit little endian value into a host byte-order value. * * @param val Little-endian 32 bit value to convert. * * @return Value in host byte order. */ #define LETOHL(val) (IS_BIGENDIAN() ? swap_endian_l(val) : val) Runtime access to this "endian" constant on every LETOHL macro? Sigh. Have a nice day -- gotta get the usbvideo.class working before I have time to spend on the DisplayLink stuff... Chrisly |
|
From: Roberto De I. <ro...@un...> - 2009-05-15 07:29:22
|
On Fri, 2009-05-15 at 09:25 +0200, Chris Hodges wrote: > Roberto De Ioris schrieb: > > The library is online: > > > > http://www.freedesktop.org/wiki/Software/libdlo > > > > Nice. Looks like this is something one could work on. But yes, it > does not cover the compression but at least provides a good basis > for the initialization stuff for different screen modes. > > But this is a joke, right? > > > /** Constant used for deciding if a host is big- or little endian. > */ > const uint32_t endian = 1; > > /** Return non-zero if the host is big endian or zero if the host is > little endian. > */ > #define IS_BIGENDIAN() ((*(char*)&endian) == '\0') > > /** Convert a 32 bit little endian value into a host byte-order value. > * > * @param val Little-endian 32 bit value to convert. > * > * @return Value in host byte order. > */ > #define LETOHL(val) (IS_BIGENDIAN() ? swap_endian_l(val) : val) > > Runtime access to this "endian" constant on every LETOHL macro? > > Sigh. > > Have a nice day -- gotta get the usbvideo.class working before I have > time to spend on the DisplayLink stuff... > > Chrisly Sadly the library is 99% useless, without compression no one can write a usable driver. I will continue to reverse engineer the windows driver. -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Roberto De I. <ro...@un...> - 2009-05-15 07:04:58
|
On Thu, 2009-05-14 at 17:29 +0200, Florian Echtler wrote: > > On their site they claim "adaptive compression" that assume a sort of > > dynamic huffman table (or similar). > > From your spec the (ipotetical) huffman table is sent only at the > > begininng so there is no big space for optimization or reimplementation. > I suppose you could update it at runtime. However, I've never seen that > happen with the Windows driver, and the question is also whether the > additional 4 or 5 kB of data are worth the compression gain. > > > But if they do not lie, we will find surprise in the code (something not > > noted in your reverse engineering/usb dump) that i hope we could > > optimize. > I'm very curious, too :-) > > > For now, i am oriented in rewriting an xorg-license compatible library. > > A working xorg video driver is needed. It must be the priority. > Yes, I feel the same. On xorg-devel, it has been suggested to use the > shadowfb layer to reduce the necessary bandwidth. I think that this might > be the most suitable approach; the avivo driver has been mentioned as an > example. > > I guess the best way to start would be a very rudimentary kernel driver > which does the most basic setup steps (set or disable encryption key, e.g.) > and provides something like /dev/displaylink0 with ioctl(), write() and mmap(). > On top of that, an X driver can the focus on sending command sequences to > the device. > > Florian The library is online: http://www.freedesktop.org/wiki/Software/libdlo -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Florian E. <fl...@bu...> - 2009-05-14 15:29:47
|
> On their site they claim "adaptive compression" that assume a sort of > dynamic huffman table (or similar). > From your spec the (ipotetical) huffman table is sent only at the > begininng so there is no big space for optimization or reimplementation. I suppose you could update it at runtime. However, I've never seen that happen with the Windows driver, and the question is also whether the additional 4 or 5 kB of data are worth the compression gain. > But if they do not lie, we will find surprise in the code (something not > noted in your reverse engineering/usb dump) that i hope we could > optimize. I'm very curious, too :-) > For now, i am oriented in rewriting an xorg-license compatible library. > A working xorg video driver is needed. It must be the priority. Yes, I feel the same. On xorg-devel, it has been suggested to use the shadowfb layer to reduce the necessary bandwidth. I think that this might be the most suitable approach; the avivo driver has been mentioned as an example. I guess the best way to start would be a very rudimentary kernel driver which does the most basic setup steps (set or disable encryption key, e.g.) and provides something like /dev/displaylink0 with ioctl(), write() and mmap(). On top of that, an X driver can the focus on sending command sequences to the device. Florian -- 0666 - Filemode of the Beast |
|
From: Roberto De I. <ro...@un...> - 2009-05-14 13:26:45
|
On Thu, 2009-05-14 at 14:22 +0200, Florian Echtler wrote: > >> Yes, it will be LGPL. That's what DisplayLink already mentioned to me. > >> However, a LGPL licensed library should not, and will not be imported > >> to X.Org. I was just in discussion with one of the X.Org chair members > >> about this topic, and to make sure that freedesktop.org != X.Org. > > Probably the second way is more suitable, but i prefer to look at the > > code and then discussing about it. > > For example if the compression scheme is not too complicated, we can > > think on implementing framebuffer kernel module and let the xorg's fbdev > > do the hard work. > The stuff I wrote is public domain, so this could serve as the basis of a > driver with any kind of license. Just for curiosity, I'd like to > re-implement the compression anyway. Moreover, I'm wondering whether they > will also release specs or rather just the library? In the second case, > I'll also update my wiki with the missing parts so that there's at least > an unofficial spec. > > Florian On their site they claim "adaptive compression" that assume a sort of dynamic huffman table (or similar). >From your spec the (ipotetical) huffman table is sent only at the begininng so there is no big space for optimization or reimplementation. But if they do not lie, we will find surprise in the code (something not noted in your reverse engineering/usb dump) that i hope we could optimize. For now, i am oriented in rewriting an xorg-license compatible library. A working xorg video driver is needed. It must be the priority. -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Florian E. <fl...@bu...> - 2009-05-14 12:49:38
|
>> Yes, it will be LGPL. That's what DisplayLink already mentioned to me. >> However, a LGPL licensed library should not, and will not be imported >> to X.Org. I was just in discussion with one of the X.Org chair members >> about this topic, and to make sure that freedesktop.org != X.Org. > Probably the second way is more suitable, but i prefer to look at the > code and then discussing about it. > For example if the compression scheme is not too complicated, we can > think on implementing framebuffer kernel module and let the xorg's fbdev > do the hard work. The stuff I wrote is public domain, so this could serve as the basis of a driver with any kind of license. Just for curiosity, I'd like to re-implement the compression anyway. Moreover, I'm wondering whether they will also release specs or rather just the library? In the second case, I'll also update my wiki with the missing parts so that there's at least an unofficial spec. Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_." |
|
From: Marcus G. <mgl...@op...> - 2009-05-14 12:37:33
|
On Thu, May 14, 2009 at 02:22:23PM +0200, Florian Echtler wrote: >>> Yes, it will be LGPL. That's what DisplayLink already mentioned to me. >>> However, a LGPL licensed library should not, and will not be imported >>> to X.Org. I was just in discussion with one of the X.Org chair members >>> about this topic, and to make sure that freedesktop.org != X.Org. >> Probably the second way is more suitable, but i prefer to look at the >> code and then discussing about it. >> For example if the compression scheme is not too complicated, we can >> think on implementing framebuffer kernel module and let the xorg's fbdev >> do the hard work. > The stuff I wrote is public domain, so this could serve as the basis of a > driver with any kind of license. Just for curiosity, I'd like to > re-implement the compression anyway. Moreover, I'm wondering whether they > will also release specs or rather just the library? In the second case, > I'll also update my wiki with the missing parts so that there's at least > an unofficial spec. In the last communication with them, they explicitly stated that they don't will release specs. But who knows, hope dies last :-) |
|
From: Roberto De I. <ro...@un...> - 2009-05-14 11:46:58
|
On Thu, 2009-05-14 at 13:13 +0200, Marcus Glocker wrote: > On Thu, May 14, 2009 at 09:22:07AM +0200, Roberto De Ioris wrote: > > > On Thu, 2009-05-14 at 08:59 +0200, Roberto De Ioris wrote: > > > On Wed, 2009-05-13 at 20:34 +0200, Florian Echtler wrote: > > > > Hello everyone, > > > > > > > > Marcus Glocker told me yesterday that DisplayLink will, after all, release > > > > source code themselves. This is supposed to happen this Friday, on the site > > > > http://displaylink.org/. They won't release a complete driver, but rather > > > > a library with functions, just like what I was thinking about. So let's > > > > hope that this will actually happen :-) > > > > > > > > Yours, Florian > > > > > > Glad to hear this, i hope the code will be under some sort of free > > > license. > > > > > > I agree on the shared library way, i am writing an example "projector" > > > app that use the Xdamage extension to redirect a window (uncompressed) > > > on a displaylink device using a shared library (based on your great > > > work) > > > > > > Having (finally) a good compressor we can start thinking on implementing > > > a base xorg driver. > > > > > > > Ok, it will be lgpl: > > > > http://www.freedesktop.org/wiki/Software/libdlo > > Yes, it will be LGPL. That's what DisplayLink already mentioned to me. > However, a LGPL licensed library should not, and will not be imported > to X.Org. I was just in discussion with one of the X.Org chair members > about this topic, and to make sure that freedesktop.org != X.Org. > > So, I see two main ways yet how an X.Org driver can be implemented; > We ask DisplayLink to change their license (which will not happen > I guess), or we write a new driver under a reasonable license using > their OpenSource library as documentation. Probably the second way is more suitable, but i prefer to look at the code and then discussing about it. For example if the compression scheme is not too complicated, we can think on implementing framebuffer kernel module and let the xorg's fbdev do the hard work. -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Marcus G. <mgl...@op...> - 2009-05-14 11:37:32
|
On Thu, May 14, 2009 at 09:22:07AM +0200, Roberto De Ioris wrote: > On Thu, 2009-05-14 at 08:59 +0200, Roberto De Ioris wrote: > > On Wed, 2009-05-13 at 20:34 +0200, Florian Echtler wrote: > > > Hello everyone, > > > > > > Marcus Glocker told me yesterday that DisplayLink will, after all, release > > > source code themselves. This is supposed to happen this Friday, on the site > > > http://displaylink.org/. They won't release a complete driver, but rather > > > a library with functions, just like what I was thinking about. So let's > > > hope that this will actually happen :-) > > > > > > Yours, Florian > > > > Glad to hear this, i hope the code will be under some sort of free > > license. > > > > I agree on the shared library way, i am writing an example "projector" > > app that use the Xdamage extension to redirect a window (uncompressed) > > on a displaylink device using a shared library (based on your great > > work) > > > > Having (finally) a good compressor we can start thinking on implementing > > a base xorg driver. > > > > Ok, it will be lgpl: > > http://www.freedesktop.org/wiki/Software/libdlo Yes, it will be LGPL. That's what DisplayLink already mentioned to me. However, a LGPL licensed library should not, and will not be imported to X.Org. I was just in discussion with one of the X.Org chair members about this topic, and to make sure that freedesktop.org != X.Org. So, I see two main ways yet how an X.Org driver can be implemented; We ask DisplayLink to change their license (which will not happen I guess), or we write a new driver under a reasonable license using their OpenSource library as documentation. Regards, Marcus |
|
From: Roberto De I. <ro...@un...> - 2009-05-14 07:22:20
|
On Thu, 2009-05-14 at 08:59 +0200, Roberto De Ioris wrote: > On Wed, 2009-05-13 at 20:34 +0200, Florian Echtler wrote: > > Hello everyone, > > > > Marcus Glocker told me yesterday that DisplayLink will, after all, release > > source code themselves. This is supposed to happen this Friday, on the site > > http://displaylink.org/. They won't release a complete driver, but rather > > a library with functions, just like what I was thinking about. So let's > > hope that this will actually happen :-) > > > > Yours, Florian > > Glad to hear this, i hope the code will be under some sort of free > license. > > I agree on the shared library way, i am writing an example "projector" > app that use the Xdamage extension to redirect a window (uncompressed) > on a displaylink device using a shared library (based on your great > work) > > Having (finally) a good compressor we can start thinking on implementing > a base xorg driver. > Ok, it will be lgpl: http://www.freedesktop.org/wiki/Software/libdlo -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Roberto De I. <ro...@un...> - 2009-05-14 07:16:05
|
On Wed, 2009-05-13 at 20:34 +0200, Florian Echtler wrote: > Hello everyone, > > Marcus Glocker told me yesterday that DisplayLink will, after all, release > source code themselves. This is supposed to happen this Friday, on the site > http://displaylink.org/. They won't release a complete driver, but rather > a library with functions, just like what I was thinking about. So let's > hope that this will actually happen :-) > > Yours, Florian Glad to hear this, i hope the code will be under some sort of free license. I agree on the shared library way, i am writing an example "projector" app that use the Xdamage extension to redirect a window (uncompressed) on a displaylink device using a shared library (based on your great work) Having (finally) a good compressor we can start thinking on implementing a base xorg driver. -- Roberto De Ioris http://unbit.it JID: ro...@ja... |
|
From: Florian E. <fl...@bu...> - 2009-05-13 18:32:19
|
Hello everyone, Marcus Glocker told me yesterday that DisplayLink will, after all, release source code themselves. This is supposed to happen this Friday, on the site http://displaylink.org/. They won't release a complete driver, but rather a library with functions, just like what I was thinking about. So let's hope that this will actually happen :-) Yours, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_." |
