[Bug 198123] Console is the wrong color at boot with radeon 6670

Peter Rosin peda at axentia.se
Mon Dec 18 13:50:21 UTC 2017


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 at bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198123
>>
>> --- Comment #8 from Deposite Pirate (dpirate at 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 at 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 at axenita.se>
>>     Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>>     Link:
>> http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-peda@axentia.se
>>
>> :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


More information about the dri-devel mailing list