> -----Original Message----- > From: daniel.vetter@xxxxxxxx [mailto:daniel.vetter@xxxxxxxx] On Behalf Of > Daniel Vetter > Sent: Thursday, December 21, 2017 3:31 PM > To: Carroll, Lewis <Lewis.Carroll@xxxxxxx>; Daenzer, Michel > <Michel.Daenzer@xxxxxxx> > Cc: Wentland, Harry <Harry.Wentland@xxxxxxx>; dri- > devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table > [patch proposed] > > Fyi Michel, we've discussed similar issues for radeon/amdgpu on irc. > > On Thu, Dec 21, 2017 at 4:21 PM, Carroll, Lewis <Lewis.Carroll@xxxxxxx> > wrote: > >> -----Original Message----- > >> From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel > >> Vetter > >> Sent: Thursday, December 21, 2017 5:07 AM > >> To: Carroll, Lewis <Lewis.Carroll@xxxxxxx> > >> Cc: Wentland, Harry <Harry.Wentland@xxxxxxx>; dri- > >> devel@xxxxxxxxxxxxxxxxxxxxx > >> Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma > table > >> [patch proposed] > >> > >> On Thu, Dec 21, 2017 at 12:00:39AM +0000, Carroll, Lewis wrote: > >> > The discussion sounds similar as well - related to load_lut() not being > called. > >> > > >> > Perhaps after the drm-next-4.14 merge, whatever call stack used to > cause > >> > load_lut to always get called is now gone. Even if > FB_VISUAL_TRUECOLOR > >> > doesn't support a clut, some hardware may still need a default gamma > lut > >> > loaded (appears to be the case with the AST2500). Perhaps checking for > >> > that profile and loading the default LUT prepared by > >> > drm_mode_crtc_set_gamma_size when FB_VISUAL_TRUECOLOR...? > >> > >> Yeah drivers should load that somehow. Unfortunately I'm going on > >> vacations now, so I'm not going to fix anything anytime soon. Might be > >> good to ping Peter Rosin, he did all the fbdev emulation gamma handling > >> rework (which is the patch that removed the superflously-looking call to > >> ->load_lut that some drivers relied on to have a consistent lut state). > >> -Daniel > > > > Enjoy the holidays. > > > > Wonder if it would be better to just call load_lut after > > drm_mode_crtc_set_gamma_size instead of adding a potentially > > unnecessary DPMS ON event to the commit call-back as I did...? Or call > > load_lut in the commit callback instead of the DPMS ON call...? > > > > The first approach (calling load_lut after set_gamma_size) also works on > > two test systems. > > Yeah, I think that's the cleanest approach. The underlying issue is > that a bunch of drivers are not making sure that on driver-load they > have a consistent sw/hw state for the gamma ramp. As long as you had > fbcon enabled the strange ->load_lut call (which isn't really > necessary for drivers that got this right) papered over these issues. > > So a call to you driver's load_lut right affter > drm_mode_crtc_set_gamma_size should fix this correctly. a-b:me if you > submit that patch. Reworked patch attached, commit message changed to summarize the Above discussion. > > /me off for real now > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
Attachment:
drm_ast_load_default_gamma_ramp.patch
Description: drm_ast_load_default_gamma_ramp.patch
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
