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

[Bernie Thompson]

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