Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755977Ab3G2VyJ (ORCPT ); Mon, 29 Jul 2013 17:54:09 -0400 Received: from blu0-omc1-s2.blu0.hotmail.com ([65.55.116.13]:62609 "EHLO blu0-omc1-s2.blu0.hotmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754600Ab3G2VyH convert rfc822-to-8bit (ORCPT ); Mon, 29 Jul 2013 17:54:07 -0400 X-EIP: [MqC4yQTW7WacKrs5aqfpLFadBMbLo6GO] X-Originating-Email: [miaousami@hotmail.com] Message-ID: Date: Mon, 29 Jul 2013 23:53:59 +0200 From: =?UTF-8?B?KiBTQU3DjSAq?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Rafael J. Wysocki" CC: Jani Nikula , Linus Torvalds , Aaron Lu , Matthew Garrett , intel-gfx , LKML , ACPI Devel Maling List , Igor Gnatenko Subject: Re: [Intel-gfx] Linux 3.11-rc2 [backlight] [ASUS N56VZ] References: <5730704.o2aLKRMvVz@vostro.rjw.lan> <1472278.oeeviaMfXH@vostro.rjw.lan> In-Reply-To: <1472278.oeeviaMfXH@vostro.rjw.lan> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT X-OriginalArrivalTime: 29 Jul 2013 21:54:03.0129 (UTC) FILETIME=[23AC7E90:01CE8CA6] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5255 Lines: 116 When I make acpi_video_backlight_quirks() return false: - the Fn+x keys are not working anymore (remember that they didn't work in 3.10 nor 3.9) - At least the backlight remains on at boot. - Gnome brightness settings do not work anymore. Neither do xbacklight. - Writing to /sys/class/backlight/intel_backlight/brightness works Regards, Sam On 07/29/2013 10:03 PM, Rafael J. Wysocki wrote: > On Monday, July 29, 2013 09:36:31 PM * SAMÍ * wrote: >> Hi Rafael, >> >> >> did you commit a full revert? > Yes, but I left acpi_video_backlight_quirks() (in drivers/acpi/video_detect.c) > that is used to decide what to do with _DOS. > > Can you please check if making that function always return 'false' makes any > difference? > > Rafael > > >> Because I am experiencing quite weird things in rc3. >> Do we have a bug opened to discuss about it? >> >> Here is what I can observe: >> 1) During boot, probably when loading the driver, backlight gets off (or >> to a level low enough to make me feel it is off) >> 2) When I am playing with my Fn+x keys, I am getting a completely full / >> completely low brightness with no intermediate steps >> 3) When I am playing with my Fn+x keys while gnome brightness settings >> panel is open, I am recovering intermediate steps but the Fn+x keys >> behavior is inverted (the key supposed to lower the brightness make it >> increase and vice-versa. Note that the gnome brightness indicator also >> gets inverted). >> 4) Playing with the mouse on gnome brightness settings is working, >> except that on the minimum level, backlight gets off >> 5) Writing to /sys/class/backlight/intel_backlight/brightness works >> >> >> Regards >> >> On 07/25/2013 02:57 PM, Rafael J. Wysocki wrote: >>> On Thursday, July 25, 2013 03:34:10 PM Jani Nikula wrote: >>>> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote: >>>>> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote: >>>>>> On Thu, 25 Jul 2013, "Rafael J. Wysocki" wrote: >>>>>>> Well, I wonder what about the appended (untested) patch? >>>>>> Rafael, before going there, I've been trying to wrap my (poor, rusty >>>>>> after vacation) head around >>>>>> >>>>>> commit 8c5bd7adb2ce47e6aa39d17b2375f69b0c0aa255 >>>>>> Author: Rafael J. Wysocki >>>>>> Date: Thu Jul 18 02:08:06 2013 +0200 >>>>>> >>>>>> ACPI / video / i915: No ACPI backlight if firmware expects Windows 8 >>>>>> >>>>>> and I can't see how it could work. >>>>> Well, if it didn't work, people wouldn't see either improvement or breakage >>>>> from it, but they do see that, so it evidently works. :-) >>>> I didn't claim it didn't work, just that *I* didn't see how it could. ;) >>>> >>>>>> First, the ACPI_VIDEO_SKIP_BACKLIGHT flag seems to be checked before >>>>>> it's actually set anywhere. >>>>> Are you sure about that? >>>>> >>>>> acpi_video_bus_add() is the .add() callback routine for acpi_video_bus which >>>>> in fact is an ACPI driver (the naming sucks, but I didn't invent it). This >>>>> means that acpi_video_bus_add() can only be called *after* acpi_video_bus >>>>> has been registered with the ACPI subsystem (and the driver core). That >>>>> is done by acpi_bus_register_driver() and, guess what?, this happens in >>>>> __acpi_video_register(). So clearly, acpi_video_bus_add() *cannot* run before >>>>> __acpi_video_register(). >>>> Right. I totally missed the call within the ternary operator. Thanks for >>>> the explanation, and apologies for the noise. >>>> >>>>>> Second, with i915 that has opregion support, __acpi_video_register() >>>>>> should only ever get called once. Which means the acpi_walk_namespace() >>>>>> with video_unregister_backlight() should never get called in register. >>>>>> >>>>>> Please enlighten me. >>>>> Actually, that's correct, so we don't need the whole >>>>> video_unregister_backlight() thing, calling acpi_video_backlight_quirks() would >>>>> be sufficient. >>>>> >>>>> Ah, one more reason to do a full revert. I'm thinking, though, that I'll leave >>>>> acpi_video_backlight_quirks() as is so that it can be used by >>>>> acpi_video_bus_(start)|(stop)_devices(), because that doesn't seem to cause >>>>> problems to happen. >>>> I observe that for the regular non-quirk acpi_video_register() call, >>>> acpi_video_backlight_quirks() won't be called during register, but it >>>> will get called later. This might have subtle effects later on, don't >>>> you think? >>> Yes, it might, but after dropping ACPI_VIDEO_SKIP_BACKLIGHT it should be OK. >>> >>>> As to the original problem, and your patch in this thread, what do you >>>> think about having another value in acpi_backlight kernel parameter for >>>> it? Having an i915 module parameter to tell acpi to use or not use >>>> quirks seems odd, since the i915 is not really taking over >>>> anything. It's just passing the info on to acpi. >>> I agree, I'm going to send a full revert in a while and we'll think what to >>> do about all that later. >>> >>> Thanks, >>> Rafael >>> >>> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/