[Libdlo] [ANNOUNCE] displaylink-mod-0.3(alpha) (was udlfb)

jasonlife jasonlife at gmail.com
Thu Jul 9 15:22:29 PDT 2009


I got my samsung monitor works by setting
/sys/bus/usb/devices/.../bConfigurationValue to "1".  I believe the monitor
will work automatically if I add a udev rule to update the file.

I tried to test usb_set_configuration() in the displaylink-main.c during the
displaylink_probe(), but I got compile error.  Instead I used
usb_driver_set_configuration() to set new Configuration, and got another
problem.

After modprobe the new displaylink module, I could see the monitor
flickering and saw green color on samsung monitor. But system was extremely
slow.  I noticed "events/0" process using a lot of cpu time from the "top"
commnad.

JAK

On Thu, Jul 9, 2009 at 10:34 AM, Bernie Thompson
<bernie at berniethompson.com>wrote:

> A bit more background on the "whys", so the Linux solution can be
> understood:
>
> It's not uncommon for USB devices play some games with USB class
> codes, in order to improve the Windows XP install experience.  Many
> DisplayLink devices do this.  Unfortunately, it creates a hassle for
> Linux.  But there are solutions, we just need to get them in place.
> Here's the background:
>
> On Windows XP, the Found New Hardware Wizard pops up when any device
> without drivers arrives.  Unfortunately, it's a UI that users
> typically get lost in (without ultimately finding appropriate
> drivers).  Vista and now particularly Win7 do a much better job, but
> XP is still an important case.
>
> To make the device install experience on XP better, companies take
> pains to avoid FNHW: stickers over the USB connector saying "install
> driver disk first", etc.  They may also have the device report a USB
> class code that is matched by an in-box driver that's otherwise
> benign, so FNHW is never shown. HID matches that bill.  Windows pnp
> logic is always to use the most specific driver match - so it will
> silently match HID initially, but once drivers are installed (e.g.
> from disk, or from internet) that match more specifically on VID/PID,
> Windows will automatically prefer those drivers over those that only
> match on the class code.
>
> The second common scenario is the device may actually appear first as
> a USB CDROM with Windows drivers on it, and only once the proper
> configuration is set, it turns into the "real" device. On DisplayLink
> devices - the core graphics function is always on configuration #1
> (even if the default configuration is something else like 2, to hide
> the device without in-OS drivers).
>
> You can see how libdlo handles this (not smart or graceful, but does
> make libdlo work 100% of the time) at
> http://cgit.freedesktop.org/libdlo/tree/src/dlo_usb.c around line 319.
>
> For the kernel framebuffer driver, my understanding is the proper
> solution would be to:
>
> 1) Actively set configuration 1 in the displaylink kernel framebuffer
> driver (call function
> http://lxr.linux.no/linux+v2.6.30/drivers/usb/core/usb.h#L31)
> 2) Because Linux doesn't have the same assumption as Windows for
> matching best driver based on specificity of IDs, it may
> (non-deterministicly?) load a HID or MSC driver instead of the real
> DisplayLink framebuffer driver.  To avoid this problem completely, we
> have to add displaylink devices to the proper blacklists, e.g. as
> these examples of adding other devices to the HID blacklist:
> http://www.google.co.uk/search?q=linux+kernel+usb+hid+blacklist
>
> If someone wanted to get wild and crazy, they could also take a look
> at a more comprehensive solution for #2 -- better aligning Linux's
> plug and play assumptions about driver matching based on specificity
> of class/vid/pid/rev, etc. with Windows' assumptions.
>
> Greg or others, please correct me if I got anything wrong here.
>
> One thing I don't have a clear picture of yet: There may exist
> composite devices that have a DisplayLink function plus other things
> (like some extra HID buttons, etc.) within the same configuration #1.
> I don't understand yet how Linux handles composite devices, but
> hopefully we can cleanly block the (fake) HID devices, while not block
> the real ones. But if not, this isn't a common case nor absolutely
> critical functionality.
>
> Unfortunately a hassle for Linux, but hopefully one where we can get
> to a deterministic (if not pretty) solution.
>
> Thanks,
> Bernie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/libdlo/attachments/20090709/f2ba970c/attachment.htm 


More information about the Libdlo mailing list