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...? 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
