On Monday, July 29, 2013 11:53:59 PM * SAMÍ * wrote: > 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 Well, you're better off with acpi_video_backlight_quirks() as is, then. :-) I'm afraid we can't help you by revering anything more at this point. Please file a bug in the kernel BZ to further track the issues you're seeing. Thanks, Rafael > 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" <rjw@xxxxxxx> wrote: > >>>>> On Thursday, July 25, 2013 11:09:27 AM Jani Nikula wrote: > >>>>>> On Thu, 25 Jul 2013, "Rafael J. Wysocki" <rjw@xxxxxxx> 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 <rafael.j.wysocki@xxxxxxxxx> > >>>>>> 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 > >>> > >>> > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
