Message-ID: <6834259.1uPUZ8EFRd@vostro.rjw.lan>
Date:	Sat, 15 Jun 2013 22:27:06 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Daniel Vetter <daniel@...ll.ch>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Aaron Lu <aaron.lu@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Seth Forshee <seth.forshee@...onical.com>,
	"Lee, Chun-Yi" <joeyli.kernel@...il.com>,
	"daniel.vetter@...ll.ch" <daniel.vetter@...ll.ch>,
	"intel-gfx@...ts.freedesktop.org" <intel-gfx@...ts.freedesktop.org>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Len Brown <lenb@...nel.org>, Zhang Rui <rui.zhang@...el.com>,
	Aaron Lu <aaron.lwe@...il.com>,
	Alex Deucher <alexdeucher@...il.com>
Subject: Re: [PATCH 3/3] i915: Don't provide ACPI backlight interface if firmware expects Windows 8

On Saturday, June 15, 2013 08:29:42 PM Daniel Vetter wrote:
> Hi all,
> 
> So to me it looks like the discussion is going in circles a bit, hence let
> me drop my maintainer-opinion here:
> 
> 1. Matthew's patch series here looks reasonable, and if it fixes a bunch
> of systems (which it seems to) it has my Ack and imo should go in. If acpi
> maintainers can smash their Ack onto the acpi parts I'd very much like to
> merge this into drm-intel-next, that should give us the most coverage for
> intel systems.
> 
> Len, Rafael, are you ok with the acpi part of this and merging it through
> drm-intel-next?

It has to go through the ACPI tree because of the ACPICA patch that needs to
be synchronized with the ACPICA upstream.  Sorry.

That said, I'm going to take this patchset.

> 2. Imo the current amount of quirking we expose to users (we have kernel
> options to disable the acpi interface, blacklist platform modules, all
> backlights can be tested through sysfs and on top of that xf86-video-intel
> has an xorg.conf to select the backlight used by the driver). I haven't
> spotted a compelling reason in this thread to add another one, what we
> have seems to be good enough to debug backligh issues.
> 
> 3. Also, adding yet another backlight quirk mechanism isn't gonna
> magically fix broken systems.
> 
> We _really_ should strive to make this just work and not offer the angry
> user another roll of duct-tape for free.
> 
> 4. The currently established priority selection for backlights of platform
> > firmware > raw seems to be good enough. Note that the explicit list in
> xf86-vidoe-intel is only used as a fallback for really old kernels which
> do not expose this information. We could probably rip it out.
> 
> 5. We've recently looked at opregion again and couldn't spot a hint.
> Unfortnately it looks like both noodling better information out of Intel
> and trying to publish an updated opregion spec seem to be losing games :(
> We'll keep on trying though.
> 
> Aside at the end: If the gnome tool indeed has its own backlight code and
> doesn't just use that as a fallback if the xrandr backligh property isn't
> available, then that's just a serious bug in gnome and should be fixed
> asap. But imo that's not something we should try to (nor do I see any way
> how to) work around in the kernel.

Agreed.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists