From patchwork Mon Aug 24 14:44:12 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 43618 Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n7OEino8014220 for ; Mon, 24 Aug 2009 14:44:49 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752659AbZHXOoN (ORCPT ); Mon, 24 Aug 2009 10:44:13 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752663AbZHXOoN (ORCPT ); Mon, 24 Aug 2009 10:44:13 -0400 Received: from adelie.canonical.com ([91.189.90.139]:40249 "EHLO adelie.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752659AbZHXOoM (ORCPT ); Mon, 24 Aug 2009 10:44:12 -0400 Received: from hutte.canonical.com ([91.189.90.181]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1MfamK-0002Ru-FG; Mon, 24 Aug 2009 15:44:12 +0100 Received: from p5b2e7f92.dip.t-dialin.net ([91.46.127.146] helo=[192.168.2.105]) by hutte.canonical.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1MfamK-0006Mh-Au; Mon, 24 Aug 2009 15:44:12 +0100 Message-ID: <4A92A73C.7010003@canonical.com> Date: Mon, 24 Aug 2009 16:44:12 +0200 From: Stefan Bader User-Agent: Thunderbird 2.0.0.17 (X11/20080914) MIME-Version: 1.0 To: Zhang Rui CC: "linux-acpi@vger.kernel.org" , Matthew Garrett Subject: Re: Less strict requirements for video device detection (v3) References: <4A8D140F.1090909@canonical.com> <1250817458.17853.141.camel@rzhang-dt> <4A8E7022.8000707@canonical.com> <1251076781.3483.13.camel@rzhang-dt> In-Reply-To: <1251076781.3483.13.camel@rzhang-dt> Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Zhang Rui wrote: > On Fri, 2009-08-21 at 18:00 +0800, Stefan Bader wrote: >> Zhang Rui wrote: >>> On Thu, 2009-08-20 at 17:14 +0800, Stefan Bader wrote: >>>> Hardware: Acer 6920G (from a bug report) >>>> >>>> Another case of a broken BIOS. In this case there are several definitions for >>>> video bus devices but only one has _DOS and _DOD defined. All other definitions >>>> only have _DOD. >>> I have seen such kind of BIOS too. >>> >>>> In the past (2.6.27) _ADR was not evaluated to make sure of using a present >>>> video device, but with that bug brightness could be changed. >>>> >>>> Now the video bus having _DOS and _DOD is detected as not being present. The >>>> other definitions are not considered because they are lacking the _DOS method. >>>> Using the attached patch, would cause the detection code to consider the other >>>> definitions and has been tested to enable backlight control. >>>> >>>> Would this be an acceptable approach? >>> I think so. I generated a similar patch before, but didn't sent it out >>> for some reason. >>> My suggestion is that we should also print out a warning message if _DOS >>> is missed, what do you think? >> Some indication about the problem can't hurt. Probably not in >> acpi_is_video_device as that would trigger for even unused devices. >> So I added a warning to acpi_video_bus_check for the case when _DOS is missing. > > how about using printk(KERN_WARNING FW_BUG "blabla")? I am not biased on that. -Stefan > thanks, > rui > >> The case of _DOS being present but _DOD not might also be worth a warning but >> (though the check in acpi_is_video_device prevented this) would have been >> accepted by the current code. >> -Stefan >> >>> thanks, >>> rui >>> >>>> From the ACPI spec it rather sounds like >>>> _DOD and _DOS must be present for a device for display switching and _DOS would >>>> indicate possible backlight control as well. So the question might not be so >>>> much is it the right thing than is it safe enough to allow more compatibility >>>> with broken implementations without causing other problems... >>>> >>>> -Stefan >>>> >> > Acked-by: Zhang Rui From 6b483015524f67dee3ae2f08f3c0cef27c9d84c6 Mon Sep 17 00:00:00 2001 From: Stefan Bader Date: Fri, 21 Aug 2009 11:03:05 +0200 Subject: [PATCH] acpi: video: Loosen strictness of video bus detection code BugLink: http://bugs.launchpad.net/bugs/333386 Currently a video bus device must (beside other criteria) define _DOD and _DOS methods to be considered a video device. Some broken BIOSes prevented working backlight control by only defining both for one (non-existing bus) and only _DOD for the rest. With this patch in place the other bus definitions were considered too and backlight control started to work again. Signed-off-by: Stefan Bader --- drivers/acpi/video.c | 7 ++++++- drivers/acpi/video_detect.c | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c index 8851315..acd4636 100644 --- a/drivers/acpi/video.c +++ b/drivers/acpi/video.c @@ -1083,7 +1083,12 @@ static int acpi_video_bus_check(struct acpi_video_bus *video) */ /* Does this device support video switching? */ - if (video->cap._DOS) { + if (video->cap._DOS || video->cap._DOD) { + if (!video->cap._DOS) { + printk(KERN_WARNING FW_BUG + "ACPI(%s) defines _DOD but not _DOS\n", + acpi_device_bid(video->device)); + } video->flags.multihead = 1; status = 0; } diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 7cd2b63..bee5e34 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -82,7 +82,7 @@ long acpi_is_video_device(struct acpi_device *device) return 0; /* Does this device able to support video switching ? */ - if (ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOD", &h_dummy)) && + if (ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOD", &h_dummy)) || ACPI_SUCCESS(acpi_get_handle(device->handle, "_DOS", &h_dummy))) video_caps |= ACPI_VIDEO_OUTPUT_SWITCHING; -- 1.5.4.3