On 2017-12-18 02:50 PM, Peter Rosin wrote:
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@bugzilla.kernel.org wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #8 from Deposite Pirate (dpirate@metalpunks.info) --- 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@axentia.se 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@axenita.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link:http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-emai...
: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?
Makes sense.
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.
Maybe not as far as fbdev is concerned, but I don't know that there's even a way to disable the CLUT in the KMS API.
Are we sure that FB_VISUAL_TRUECOLOR is involved at all? Why? Or is that just a red herring?
FB_VISUAL_TRUECOLOR seems to be the default used by fbcon, so I assume it's used in this case as well, but it can be checked with fbcon -i.