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 > > Lewis > > -----Original Message----- > From: Wentland, Harry > Sent: Wednesday, December 20, 2017 6:29 PM > To: Carroll, Lewis <Lewis.Carroll@xxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: drm/ast: Linux 4.14 AST DRM driver might not load gamma table [patch proposed] > > This looks similar to this bug that I spotted while finally going through my large dri-devel backlog: https://bugzilla.kernel.org/show_bug.cgi?id=198123 > > The discussion continues here https://lists.freedesktop.org/archives/dri-devel/2017-December/160667.html > > Not sure if this is related but the symptoms sound quite similar. > > Harry > > On 2017-12-17 07:08 PM, Carroll, Lewis wrote: > > Happy Holidays. > > > > > > > > Test-driving Linux 4.14 from the Ubuntu Bionic repo on an AMD EPYC server using the A-Speed AST2500 BMC and the AST DRM driver and framebuffer console configured into the kernel, I have observed multiple systems where the analog VGA color palette for the framebuffer console is incorrect. Background is blue and all text colors other than white / gray are incorrect. > > > > > > > > Instrumenting the AST DRM driver, it seems the default gamma table isn't loaded to the silicon until there is a DPMS action. When there is a DPMS action other than DPMS OFF, the gamma table is loaded and all is well. On these boards, the kernel is not calling for a DPMS event at driver init so the gamma table is not loaded. > > > > > > > > The attached proposed patch adds a DPMS ON event to the commit callback after a kernel modeset call. This solves the problem, however there may be a better / more proper way to solve this. > > > > > > > > Assuming no one on the mailing list has hardware on which to verify this, I am happy to be a test driver for any suggested fixes. > > > > > > > > Regards, > > > > > > > > Lewis Carroll > > > > Principal Solutions Architect > > > > AMD Enterprise Business Group > > > > > > > > > > > > _______________________________________________ > > dri-devel mailing list > > dri-devel@xxxxxxxxxxxxxxxxxxxxx > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
