Why won't UGA-2K-A drive my 1920x1200 at full resolution?


I have a 1920x1200 native resolution LCD (based on AU B170UW01 panel) that works at native 1920x1200 res when connected directly by DVI or VGA. However, when connected through the UGA-2K-A it offers only two modes, 1680x1050 and 1280x1024. Is there any way to force the native 1920x1200 mode? I suspect this may be a bug in the displaylinks driver’s EDID negotiation. I am running the latest beta driver 5.6. Please advise. Thanks.


Hi Bill,

Thanks for posting! Yes, you’re right - DisplayLink’s drivers rely completely on the EDID from the monitor to describe what the monitor is capable of, and unfortunately there are no overrides (on the good side, this has the benefit that DisplayLink devices won’t ever try to set a mode higher than the monitor supports, even if a user tried to).

Do you suspect the LCD is reporting a lower max mode than 1920x1200, and if so is there a way you could flash the monitor firmware to report its true max/native resolution?

Sorry we don’t have an easier answer in this kind of case,


Bernie, thanks for the quick reply. I’ve attached the moninfo report. Afaik it is correctly reporting 1920x1200, but perhaps you may see something fishy. One possible problem is that this monitor originally had a 1600x1200 panel in it when first connected to DL-195 (we use a few different DL-195 models besides the plugable, and I don’t recall which one we had first). So perhaps the DL drivers have some stale data cached in the registry or elsewhere due to the panel switch and/or use of multiple DL-195 products? Is it safe to do a complete uninstall and fresh reinstall of the DL drivers? Will that clear the registry etc? Any advice appreciates since I’m at my wits end.


Hi Bill,

Great info - there may be confusion if the monitor previously had a different panel (1600x1200). The monitor firmware must have been updated at the same time the panel was swapped out, is that right?

There are two places where EDID can be logged or cached (DisplayLink logs it, and then Windows 7 also caches in the registry).

If you can run the DisplayLink support tool (instructions here http://plugable.com/support/displayli… ) we should be able to see what’s going on, and suggest if there’s a quick solution.

Can you email the .zip file output from that tool to support@plugable.com?



Update: I installed the DisplayLink 5.6 driver on a laptop that never had it installed before and it behaves the same way as described above. This rules out any caching issues. Do you see anything in the above moninfo report that would cause the DL driver to limit this 1920x1200 panel 1680x1050?


Hi Bill - One thing I realized from the moninfo, is that this is on XP - so yes XP itself doesn’t deal with EDID (on Win7 the OS takes a more active role). But otherwise, DisplayLink’s EDID parsing should be the same.

If you can send that dump of the log files above, we might be able to see any errors that DisplayLink is logging in parsing the EDID.

But unfortunately, either way, I’m not sure we’re going to have an alternative for the short term (for the long term, if there’s a clear error, we can get DisplayLink to look into it).

Since the panel was replaced on this LCD monitor - can you say if this is a custom EDID or what source did it come from?



Bernie, I’ve emailed the DL dump from the support tool. The monitor is custom built using a laptop panel and a universal LVDS controller by Rova (based on a very common Realtek controller). It works fine when connected directly to a VGA or DVI port, so I’m inclined to believe the problem is with the displaylink driver. In any case it appears the DL dump includes the a full EDID dump so perhaps that will provide further clues.


PS the EDID is what was supplied in the firmware by the controller manufacturer for this panel.


Hi Bill,

A non-standard EDID appears to be the cause - it may be technically correct, but it’s doing something different from other normal off-the-shelf monitors (no clear errors from the logs, but perhaps seems to be reporting more modes than a normal monitor does, which causes the DL drivers to perhaps not parse the last few).

Not surprising that something unusual is happening, given the custom panel and the firmware provided by the controller maker.

The logs you emailed show you’re currently running with a Kensingon DIsplayLink-based adapter, not a Plugable one. If they’re both DL-195 chips, the behavior is the same (and buying a UGA-2K-A wouldn’t make a difference). But if you do actually have a UGA-2K-A, just let us know by emailing your Amazon order number. We’ll do what we can do help.

Best wishes,


Bernie: Apologies, I should have mentioned that we’ve been tested a handful of DL-195 products, including a plugable. They all behave the same as reported above. I can’t run the dump with the plugable since it’s currently being used by a coworker who is travelling. Can you give me any insight as to how to workaround the issue, or, perhaps something I can report to the controller manufacturer if you think that it is their bug. How would the EDID need to be modified to work around the problem? If we can get this to work we will happily buy all our future DL-195’s from plugable (as well as upcoming USB3 versions) in thanks for your superb support (probably qty 50+ over the next year).


By the way, the DL software only offers the two modes 1680x1050 and 1280x1024 for this monitor. Does that seem consistent with EDID parsing overflow? I would think that the DL driver can parse more than two modes, so if there were many then wouldn’t it offer more than the above two modes?


Those modes are a subset of what moninfo reports in the above attached file. Does “two copies” refer to the 16 and 24bit versions, or does it mean that the above list is duplicated? Any idea why DL is not using the 1920x1200 Detailed timing #1? Thanks.


Bernie: After further research I am fairly certain that this is a bug in the DisplayLink EDID parsing software. This and similar units work fine using Nvida drivers and Intel GMA drivers. Only the DisplayLink driver fails in the mentioned way. Have you communicated this problem to DIsplayLink? If not I’d be grateful if you could please tell me the best way to do so. Thanks.


Hi Bill,

Especially if not currently running on a Plugable adapter, you’ll want to contact DisplayLink. Your best shot of getting a response for a custom situation like this is through their forum: http://displaylink.org/forum/forumdis…

You’ll want to post the nature of what you’re doing (the custom LCD panel, controller, and firmware) and the EDID block itself.

EDID problems can be tricky and time consuming to figure out what’s wrong. I don’t see what’s wrong with yours. Also did a quick check and it parses under Linux. But there’s clearly something different from most monitors, just on the basis that DisplayLink’s drivers are running today on hundreds of thousands of monitors, with few EDID troubles on current drivers. It’s likely to be something simple that can be corrected in the EDID, but it’s not obvious what it is at this point.

On the nVidia & Intel drivers - they could be reading the 1920 mode on the EDID, or they can fail the parsing, but may still offer higher res modes. For better or worse, DisplayLink takes a different policy of not offering modes beyond what it knows from the EDID.

Sorry - wish we had an easy answer to get your custom LCD panel going. If I see anything that could lead to a solution, I’ll certainly let you know.

Best wishes,