On 2017-12-18 12:37, Michel Dänzer wrote: > > Following up by e-mail, since I can't find Peter Rosin in the kernel > bugzilla. > > > On 2017-12-16 02:41 AM, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=198123 >> >> --- Comment #8 from Deposite Pirate (dpirate@xxxxxxxxxxxxxxx) --- >> Ok, I went through all the git bisect process. Here are the results: >> >> [...] >> >> b8e2b0199cc377617dc238f5106352c06dcd3fa2 is the first bad commit >> commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 >> Author: Peter Rosin <peda@xxxxxxxxxx> >> Date: Tue Jul 4 12:36:57 2017 +0200 >> >> drm/fb-helper: factor out pseudo-palette >> >> The pseudo-palette has nothing to do with the crtc, so move it >> out of the crtc loop and update the palette once, then break out >> early. >> >> Signed-off-by: Peter Rosin <peda@xxxxxxxxxx> >> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >> Link: >> http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-peda@xxxxxxxxxx >> >> :040000 040000 a8c2650554e199fee994ac63c2700c73ba2ecffe >> 7f72ed414efadd77ef1d718e7477475c4ba1127d M drivers > > My guess would be this is because fb_helper->funcs->gamma_set is no > longer called from drm_fb_helper_setcmap in the FB_VISUAL_TRUECOLOR case > (was previously called via setcolreg). No, that's not right, fb_helper->funcs->gamma_set() wasn't called for the FB_VISUAL_TRUECOLOR case before the commit either. However, crtc_funcs->load_lut() was called, but that operation is now gone in a later cleanup. However#2, that ->load_lut() did not use anything that was provided in the call to drm_fb_helper_setcmap, since the load_lut implementations generally didn't look at the pseudo_palette variable. So, the now-missing ->load_lut() call probably just reloaded the clut? > Peter, how is the hardware CLUT intended to be initialized in that case > with this change? I thought that truecolor visuals didn't have any hardware clut. Seems like an easy enough mistake to make, and I still don't get it... I don't know what the correct behavior is since I don't get what is going on with that, but I assume it should be fairly easy to rearrange things so that a write to the hw clut is triggered. Are we sure that FB_VISUAL_TRUECOLOR is involved at all? Why? Or is that just a red herring? Cheers, Peter _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
