79138eec1b49cbaca6a16f2bdd8579b5828aeb28 causing black screen

Maarten Maathuis madman2003 at gmail.com
Tue Jun 2 11:14:31 PDT 2009


On Tue, Jun 2, 2009 at 6:46 PM, Matthias Hopf <mhopf at suse.de> wrote:
> On May 24, 09 18:17:40 +0200, Maarten Maathuis wrote:
>> The problem seems fairly obvious.
>
> Well, it wasn't to me. Actually, it still isn't.
>
> I stumbled over this code, and asked for why this was coded this way,
> without getting any answers. So I assumed that it was just a bug and
> nobody cared. I remember that there are issues with gamma LUT in RandR
> not being set when they ought to, which AFAIK are not fixed yet - this
> looked like the culprit for this issue.
>
>> Old style:
>> Only set gamma on currently inactive (=first activation) crtcs
>
> inactive != first activation

Let me rephrase, transition from inactive to active. Note that enabled
is something you want, active is something that you get (after it's
done).

>
> This assumption can have all kinds of side effects.
>
>> New style (someone doesn't realize the situation):
>> Only set gamma on currently active(=not the first activation)
>>
>> So your luts are now empty and all colors become black (HW cursor is a
>> world of it's own).
>
> That would imply that somewhere(!) crtc->gamma_* is NULLed. Which I
> wonder why. Also, the comment doesn't indicate what's happening here.
>

It is not that those values are empty, they are are just not
transmitted to the driver until a late stage in modesetting. It
happens after all the normal modesetting and before crtc commit. This
to avoid banging hw that isn't ready for it. So it is in fact a piece
of vram, registers, whatever that was empty.

> I will revert the commit for now, but I'm not convinced yet that this
> piece of code is actually correct. But given the issues we're seeing
> here, the old behavior is presumably better.

You are free to change the style if it is unclear.

>
> CU, and sorry for any issues caused

No problem, it's just git head, please don't shy away from mentioning
or changing odd code in the future.

>
> Matthias
>
> --
> Matthias Hopf <mhopf at suse.de>      __        __   __
> Maxfeldstr. 5 / 90409 Nuernberg   (_   | |  (_   |__          mat at mshopf.de
> Phone +49-911-74053-715           __)  |_|  __)  |__  R & D   www.mshopf.de
>


More information about the xorg-devel mailing list