lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 9 Sep 2013 17:21:18 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Daniel Vetter <daniel@...ll.ch>, Aaron Lu <aaron.lu@...el.com>,
	ACPI Devel Mailing List <linux-acpi@...r.kernel.org>,
	Matthew Garrett <matthew.garrett@...ula.com>,
	Seth Forshee <seth.forshee@...onical.com>,
	"Lee, Chun-Yi" <joeyli.kernel@...il.com>,
	Daniel Vetter <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>,
	Igor Gnatenko <i.gnatenko.brain@...il.com>,
	Yves-Alexis Perez <corsac@...ian.org>,
	Felipe Contreras <felipe.contreras@...il.com>,
	Lee Chun-Yi <jlee@...ell.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>
Subject: Re: [PATCH 2/2] ACPI / video / i915: Remove ACPI backlight if
 firmware expects Windows 8

On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
> Hi,
> 
> On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
> > Hi Aaaron,
> > 
> > Have we grown any clue meanwhile about which Intel boxes need this and for
> > which we still need to keep the acpi backlight around?
> 
> First of all, there is a bunch of boxes where ACPI backlight works incorrectly
> because of the Win8 compatibility issue.  [In short, if we say we are compatible
> with Win8, the backlight AML goes into a special code path that is broken on
> those machines. Presumably Win8 uses native backlight control on them and that
> AML code path is never executed there.]  The collection of machines with this
> problem appears to be kind of random (various models from various vendors), but
> I *think* they are machines that originally shipped with Win7 with a Win8
> "upgrade" option (which in practice requires the BIOS to be updated anyway).
> 
> Because of that, last time we tried to switch all of the systems using i915
> and telling the BIOS that they are compatible with Win8 over to native backlight
> control, but that didn't work for two reasons.  The first reason is that some
> user space doesn't know how to use intel_backlight and needs to be taught about
> that (so some systems are just not ready for that switch).  The second and more
> fundamental reason is that the native backlight control simply doesn't work on
> some machines and we don't seem to have any idea why and how to debug this
> particular problem (mostly because we don't have enough information and we
> don't know what to ask for).
> 
> > I've grown _very_ reluctant to just adding tons of quirks to our driver for
> > the backlight.
> >
> > Almost all the quirks we have added recently (or that have been proposed
> > to be added) are for the backlight. Imo that indicates we get something
> > fundamentally wrong ...
> 
> This thing isn't really a quirk.  It rather is an option for the users of
> the systems where ACPI backlight doesn't work to switch over to the native
> backlight control using a command line switch.  This way they can at least
> *see* if the native backlight control works for them and (hopefully) report
> problems if that's not the case.  This gives us a chance to get more
> information about what the problem is and possibly to make some progress
> without making changes for everyone, reverting those changes when they don't
> work etc.
> 
> An alternative for them is to pass acpi_osi="!Windows 2012" which will probably
> make the ACPI backlight work for them again, but this rather is a step back,
> because we can't possibly learn anything new from that.

If Win8 is as broken as we are I'm ok with the module option. It just
sounded to me like right now we don't know of a way to make all machines
somewhat happy, combined with the other pile of random backlight issues
the assumption that we do something (maybe something a bit racy) that
windows doesn't do isn't too far-fetched. So I'm not wary of the machines
where the aml is busted for acpi_os=win8, but for the others where this
broke stuff.

Or do I miss something here?

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ