[Libdlo] what displaylink device should i buy and what steps are still needed?

[Bernie Thompson]

Hi Jelle,

Thanks for posting such clear text logs - makes it easy to see what's going on!

On Thu, Jul 1, 2010 at 4:21 AM, Jelle de Jong <jelledejong at powercraft.nl> wrote:
> The information made me try to use the latest git version of udlfb. The code
> seem to be untouched for more then 7 months. Is this the correct
> code/project?

Check the git log again in your udlfb directory.  :) Based on the
output log you attached, you appear to be running code with the latest
udlfb changes (including changes from the last few days).

> I also switched form using VGA to DVI so the cable or signalling should not
> become a problem.
> However now the kernel udlfb driver crashes.... when the device is attached.
> I attached my debug logs in this mail.
>
> Could somebody have a look at them?

Yep, the EDID being returned is null or not parsable by the kernel's
edid library (fb_edid_to_monspecs).  But you can tell this codepath
hasn't been well tested, because it triggers some fixable bugs.  So
thanks again for reporting back with this.

1)  if no EDID is returned, udlfb tries to fall back to 800x600.  It
does this by enumerating all the VESA modes (which you can see in your
logs), and then tries to find the mode closest to 800x600 with
fb_find_nearest_mode().  That was all happening correctly, but it
simply never reset return code to success when the fall back was
found!

2) As the driver was tearing down after getting the failing return
code, it hit a bug in the error path (regression introduced just a few
days ago), where the refcounts are off.  That caused the crash instead
of a normal exit.  Getting the refcounts right is one of the reasons
recent udlfb changes haven't been submitted for 2.6.36 yet -- they
need more testing and bug fix time yet.

3)  The kernel function fb_find_nearest_mode() was not returning the
refresh rate we asked for.  Not critical, but there's a bug in the
library function (in /drivers/video/modedb.c) in all recent Linux
kernels.

Fixes for problems #1 and #2 have just been checked in, see
http://git.plugable.com/gitphp/index.php?p=udlfb&a=summary

Do a git pull and then confirm in the git log that you have these
checkins from today.

The fix for #3 requires a kernel rebuild (but, again, not critical -
in the absence of the fix, we get the highest refresh rate, rather
than the one we asked for, which didn't make a difference on my
monitor, but may on some)

--- drivers/video/modedb.c.ori  2010-07-01 11:02:52.000000000 -0700
+++ drivers/video/modedb.c      2010-07-01 11:03:00.000000000 -0700
@@ -854,6 +854,7 @@ const struct fb_videomode *fb_find_neare
                       abs(cmode->yres - mode->yres);
               if (diff > d) {
                       diff = d;
+                       diff_refresh = abs(cmode->refresh - mode->refresh);
                       best = cmode;
               } else if (diff == d) {
                       d = abs(cmode->refresh - mode->refresh);

Now, when i tested no EDID (by plugging in adapter without DVI cable
attached, then later attaching) on my monitors (which are all
widescreen), they wouldn't sync to the 800x600 mode.  So there may
still be problems with the (possibly lack of) timings we get back from
the kernel VESA mode functions.

Another alternative (and this would help Christoph also, who had to
hardcode an EDID), is adding the feature to let a default EDID be
written from user mode, in those cases where reading the real EDID
fails for whatever reason.  It's not a lot of code, but haven't
implemented this yet (patches are welcome :) )

Back to what you're trying to do - you're not going to have a good
experience if the monitor's capabilities are unknown.  So, these fixes
aside, it's worth trying to figure out what's different about your
monitor or something in your setup, that's causing the lack of EDID.
If it there appears to be anything udlfb can do, please post or email.

Best wishes,
Bernie
http://plugable.com/