On Tue, Aug 28, 2012 at 04:49:15PM +0200, Indan Zupancic wrote: > On Tue, August 28, 2012 16:14, Daniel Vetter wrote: > > On Tue, Aug 28, 2012 at 03:56:31PM +0200, Indan Zupancic wrote: > >> Hello, > >> > >> On Tue, August 28, 2012 08:53, Jani Nikula wrote: > >> > From: Daniel Vetter <daniel.vetter at ffwll.ch> > >> > > >> > This is a prep patch to stop drm/i915 from changing the LBPC registers > >> > itself - but we still need to properly save/restore it on > >> > suspend/resume. > >> > > >> > Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch> > >> > Signed-off-by: Jani Nikula <jani.nikula at intel.com> > >> > --- > [...] > >> It seems weird that LBPC wouldn't be restored during resume by some BIOSes, > >> is this really necessary? > > > > ba3820ade317ee36e496b9b40d2ec3987dd4aef0 claims so. But that commit > > managed to put too many things into the same thing unfortunately. > > Is that the right SHA? Because that just reverts my combination mode > removal patch. Assuming it is the right commit, then I think it's > incorrect in saying that it caused backlight dimming problems after > resume. That particular problem was caused by a bogus shift. The > problems caused by removing the mode was a lower max brightness > and/or less brightness levels. Yeah, right commit but imo with sub-par commit message. Your other mail clarified things, thanks. > By the way, saving LBPC only makes sense if it's done before it was > set to 0 to disable the panel. I don't know if the current code does > the right thing, I haven't looked at it for a while. I think we can coax it into doing the right thing, see my other mail. If your completely sure that lbpc /should/ be handled by the bios across s/r I think we can drop this. But tbh I have no idea how this really is supposed to work, and unfortunately we're not allowed to cross-check with the windows driver codebase :( Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
