From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Baumann Subject: Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness level for sysfs control. Date: Tue, 26 Mar 2013 17:55:53 +0100 Message-ID: <5151D319.5040104@web.de> References: <1364298525-4337-1-git-send-email-dannybaumann@web.de> <1364298525-4337-2-git-send-email-dannybaumann@web.de> <20130326151313.GU9021@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130326151313.GU9021@phenom.ffwll.local> Sender: linux-kernel-owner@vger.kernel.org To: David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Hi, > Thus far our assumption always was that the acpi backlight works better > than the intel native backlight. So everything only uses the intel > backlight if there's no other backlight driver by default. > > So if I should merge this as a general solution for Windows 8 machines not > working properly, we first need to figure out what windows does on these > machines and either disable the acpi backlight or adapt it. I fully agree to that. Making acpi_video control usable is preferable over using intel_backlight. As I lack the detail knowledge about the ACPI video stuff, I'd be great of one (or some) of you guys could look at the mentioned bug report ([1]) and comment on what the problem might be. I have added the basic needed information already and would be happy to provide any needed debugging info. > Adding more kernel options is not a viable solution for the backlight mess > imo. Actually I'm fine with hardcoding the percentage as well ;) I just figured it might make sense to make it controllable for special-case uses, while still making intel_backlight usable for the 'normal' use case. Regards, Danny [1] https://bugzilla.kernel.org/show_bug.cgi?id=55071