On Thursday, May 01, 2014 12:38:28 PM Hans de Goede wrote: > Hi, > > On 04/30/2014 09:52 PM, Rafael J. Wysocki wrote: > > On Wednesday, April 30, 2014 03:37:21 PM Hans de Goede wrote: > >> This fixes the backlight control not working. > >> > >> Cc: [email protected] > >> Reported-and-tested-by: Vincent Gerris <[email protected]> > >> Signed-off-by: Hans de Goede <[email protected]> > > > > Sorry, this conflicts with commit 170269a9d3c0 (ACPI / video: Default to > > using > > native backlight control on Windows 8 systems) in linux-next, so I'm not > > going > > to apply it. > > I strongly disagree, rejecting bug-fixes which conflict with more rigorous > (and dangerous) fixes -next, purely because the conflict with something -next > is not a good reason. TBH I find it a complete non reason to reject these > fixes. > > > If you wanted to have this stuff in 3.15, there was a plenty of time to > > submit > > it earlier. > > Heh, that assumes I was aware of this particular model needing this quirk > earlier, > while I actually got the first report of it not working from Vincent on April > 26th, > and got confirmation that the quirk fixes it on April 29th. I would say that > 1 day > turn around time between getting the confirmation and sending the patch is > not bad > at all. > > I really believe it is important to get the quirk for this model (and others) > into > 3.15, here us my decision tree leading to this: > > -Do we want to fix these brightness issues -> Yes > -Do we expect our users to wait for 6 months for an upstream fix + many more > months > for the fixed kernel to hit distros -> No > -So we want to backport these fixes to stable -> Yes > -Is the proposed fix for 3.16 acceptable for stable -> No (too high change of > regressions)
OK, this is a good argument. > Conclusion: we want quirks for models known to need quirks added to 3.15 and > backported to the various stable series. > > I actually want to go as far as to claim that once 3.15 is released we will > want > to add quirks to 3.15.x, breaking the every fix must be upstream rule for the > stable > series. But lets safe that discussion for later. Well, there's a way out of this. Instead of doing commit 170269a9d3c0 as is, we can just switch the default without removing the blacklist just yet. And remove the blacklist one we are reasonably confident that the new default actually works. In which case I'd go for your original series (along with the RFC moving stuff out of blacklist.c to the video.c blacklist) with a replacement of commit 170269a9d3c0 that will simply flip the default. Does this make sense to you? > I've been doing triaging of (Fedora) brightness bugs for the last few days (I > sort of > just rolled into this whole brightness business) and this really is a big > problem, I'm very much aware of that. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
