Re: [PATCH] acpi-video: Put the Acer Aspire V5-471G on the use_native_backlight dmi list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, May 02, 2014 11:02:54 AM Hans de Goede wrote:
> Hi,
> 
> On 05/01/2014 10:10 PM, Rafael J. Wysocki wrote:
> > 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: stable@xxxxxxxxxxxxxxx
> >>>> Reported-and-tested-by: Vincent Gerris <vgerris@xxxxxxxxx>
> >>>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
> >>>
> >>> 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?
> 
> Yes that seems like a good solution, thanks!
> 
> I'll rebase and resend my RFC for moving the models from blacklist.c to video.c as non
> RFC.
> 
> Who is going to do the only flip the default version of 170269a9d3c0 ?

That would be either you or me I guess. :-)

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]