From patchwork Wed Jun 22 17:15:38 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Katsak, William Alexander (Bill)" X-Patchwork-Id: 906462 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p5MHPJ7k022120 for ; Wed, 22 Jun 2011 17:25:19 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755096Ab1FVRZS (ORCPT ); Wed, 22 Jun 2011 13:25:18 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]:43135 "EHLO ihemail2.lucent.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754214Ab1FVRZS (ORCPT ); Wed, 22 Jun 2011 13:25:18 -0400 X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Wed, 22 Jun 2011 17:25:19 +0000 (UTC) X-Greylist: delayed 576 seconds by postgrey-1.27 at vger.kernel.org; Wed, 22 Jun 2011 13:25:18 EDT Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5MHFfeJ003463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 22 Jun 2011 12:15:41 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5MHFcub002916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 22 Jun 2011 12:15:40 -0500 Received: from USNAVSXCHMBSD1.ndc.alcatel-lucent.com ([135.3.39.153]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 22 Jun 2011 12:15:39 -0500 From: "Katsak, William Alexander (Bill)" To: "linux-fbdev@vger.kernel.org" Date: Wed, 22 Jun 2011 12:15:38 -0500 Subject: [PATCH] udlfb - Fix for problem with monitor resolution detection / framebuffer size allocation Thread-Topic: [PATCH] udlfb - Fix for problem with monitor resolution detection / framebuffer size allocation Thread-Index: AQHMMP1ojgGm9HcPmEyJkLR4b66wXQ== Message-ID: <76676AFCFD6F05458E27320F9BB714A825120FC640@USNAVSXCHMBSD1.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Sender: linux-fbdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fbdev@vger.kernel.org Hello, This is my first contribution on this list, so please let me know if I am off with any procedures or anything. This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuffer resolution. The problem occured with a Plugable UGA-2K-A connected to a Samsung EX2220X display. In this situation, the driver always allocates a 1600x1200 framebuffer, even after it indicates in its output that 1920x1080 is a valid mode. If my interpretation of the code is correct, the problem was in the block that selects the best mode. The existing code unset the FB_MISC_1ST_DETAIL flag if ANY of the modes is determined to be invalid (on my adapter, 1680x1680 is invalid). This in turn causes the fb_find_best_display() function to disregard the first mode (1920x1080). The comment for the line that unsets the flag implies that this should happen if we have removed the top/best mode...however, this else block is not qualified, and happens if we remove any mode. I simply put in a condition so that we only unset this flag if the first mode is invalid. Thanks in advance for your feedback. Bill Katsak Bell Laboratories Alcatel-Lucent, Inc. william.katsak@alcatel-lucent.com From c3327c41877637e80f9f06a8ce3bdcfe8b4e6fa4 Mon Sep 17 00:00:00 2001 From: William Katsak Date: Wed, 22 Jun 2011 12:48:11 -0400 Subject: [PATCH] This patch fixes a problem where a DisplayLink device autoselects a suboptimal framebuffer resolution. The situation in which the problem occurred was with a Plugable UGA-2K-A connected to a Samsung EX2220X display. The driver indicates that 1920x1080 is a valid mode (the first mode available, in fact), but proceeds to set the framebuffer size to 1600x1200. The patch corrects what seems to be a logic error, regarding unsetting the FB_MISC_1ST_DETAIL flag, if the first (top/best) mode is invalid. The existing code unset the flag if ANY mode was invalid. --- drivers/video/udlfb.c | 8 ++++++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/video/udlfb.c b/drivers/video/udlfb.c index 52b0f3e..816a4fd 100644 --- a/drivers/video/udlfb.c +++ b/drivers/video/udlfb.c @@ -1233,8 +1233,12 @@ static int dlfb_setup_modes(struct dlfb_data *dev, if (dlfb_is_valid_mode(&info->monspecs.modedb[i], info)) fb_add_videomode(&info->monspecs.modedb[i], &info->modelist); - else /* if we've removed top/best mode */ - info->monspecs.misc &= ~FB_MISC_1ST_DETAIL; + else { + if (i == 0) + /* if we've removed top/best mode */ + info->monspecs.misc + &= ~FB_MISC_1ST_DETAIL; + } } default_vmode = fb_find_best_display(&info->monspecs, -- 1.7.3.4