On Thu, Jun 28, 2012 at 9:36 PM, Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote: > On Thu, Jun 28, 2012 at 02:30:17PM -0500, Seth Forshee wrote: > >> I actually don't think Corentin's solution is a bad one. It does suffer >> from a couple of shortcomings though. First, it only works for broken >> ACPI backlights, and some platforms have other backlight interfaces that >> are broken (e.g. the i915 backlight on the MacBook Pro 8,2). Second, >> marking backlights as broken in the kernel necessitates ever-expanding >> dmi blacklists in some of the platform drivers, unless we can get >> vendors to stop providing broken backlight interfaces. > > Userspace should already be prioritising platform interfaces over raw > interfaces, so if gmux works on the Mac then there's no problem. Hehe, sometime the platform interface doesn't work and the raw does. That's the case on various samsung-laptop since we have absolutely no documentation about SABI and no known way to probe if the implementation is working or not. But anyway, for samsung-laptop it's disabled by default in favor of acpi_video (which is also broken most of the time on samsung laptops). > DMI > lists should, broadly speaking, be unnecessary - they're mostly a > symptom of us not understanding how the hardware is expected to work. > >> I'm all for fixing integration bugs in the ACPI backlight >> implementations if we can, but some vendor implementations are just >> flat-out broken, and it isn't always possible to get vendor cooperation. >> In the case of Toshiba I've tried reaching out to them to work on ACPI >> integration issues, but they flat out refused. > > We already know that our implementation of the IGD opregion is broken, > but Intel won't hand over newer versions of the spec. If you see > problems with the acpi backlight interface on Intel graphics then that > should be the default assumption. > > -- > Matthew Garrett | mjg59@xxxxxxxxxxxxx -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html