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

Greg KH greg at kroah.com
Thu Jul 9 16:19:13 PDT 2009


On Thu, Jul 09, 2009 at 09:34:41AM -0700, Bernie Thompson wrote:
> 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)

Yes, that is needed.

> 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

Yes, we need to do that.

Should I just blacklist all devices with the vendor id of displaylink?
Or do you want to provide a subset of devices that we should 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.

This has been discussed for 10 years now, turns out that the combination
of blacklists and other tweaks works good enough.  But don't let that
stop anyone who wants to implement it, but be aware that there are some
non-trivial issues involved :)

> 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.

Linux binds devices to USB interfaces.  If a different interface
specifies that it is a HID device, and we don't have it in a blacklist
table, then the HID driver will bind to it.

This should not be happening within the same configuration, or I don't
see how your Windows driver would work properly, right?

thanks,

greg k-h


More information about the Libdlo mailing list