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 <div class="gmail_quote">On Thu, Jul 9, 2009 at 10:34 AM, Bernie Thompson <<a href="mailto:bernie@berniethompson.com">bernie@berniethompson.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> 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 <a href="http://cgit.freedesktop.org/libdlo/tree/src/dlo_usb.c" target="_blank">http://cgit.freedesktop.org/libdlo/tree/src/dlo_usb.c</a> 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 <a href="http://lxr.linux.no/linux+v2.6.30/drivers/usb/core/usb.h#L31" target="_blank">http://lxr.linux.no/linux+v2.6.30/drivers/usb/core/usb.h#L31</a>) 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: <a href="http://www.google.co.uk/search?q=linux+kernel+usb+hid+blacklist" target="_blank">http://www.google.co.uk/search?q=linux+kernel+usb+hid+blacklist</a> 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 </blockquote></div>