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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
