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

Michel Dänzer michel at daenzer.net
Tue Dec 19 10:48:15 UTC 2017


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

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.


-- 
Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer


More information about the dri-devel mailing list