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