Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37

[Dave Airlie <airlied@gmail.com>]

On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra <crmafra2@gmail.com> wrote:
>>>
>>> I added https://bugzilla.kernel.org/show_bug.cgi?id=24982 to the list of
>>> post-2.6.36 regressions for further tracking.
>>
>> I also tested on 2.6.38-rc3+ now and the issue is not solved,
>> just like Takashi expected.
>
> Hmm. That commit (bf9dc102e284) still reverts cleanly.
>
> Keith, Dave, should we just revert it? It's definitely a regression,
> and we do _not_ allow "fixes" to one thing that just causes a
> regression to another.
>
> Quite frankly, I think it's totally wrong to just blindly set DPMS
> status to ON like that. It's as wrong as it was to leave it off, and
> the regressions reported are basically mirror images of the exact same
> bug that that commit tried to fix.
>
> IOW, the commit message says:
>
>    When setting a new crtc configuration, force the DPMS state of all
>    connectors to ON. Otherwise, they'll be left at OFF and a future mode set
>    that disables the specified connector will not turn the connector off.
>
> but setting it to ON doesn't actually _fix_ anything, because you just
> get the exact same issue in reverse, ie you just get
>
>   .. and a future mode set  that ENables the specified connector will
>    not turn the connector ON.

If we are setting a mode on a connector it automatically will end up
in a DPMS on state,
so this seemed correct from what I can see.

A future mode set shouldn't ever not turn the connector on, since
modesetting is an implicit
DPMS,

It sounds like something more subtle than that, though I'm happy to
revert this for now, and let Keith
think about it a bit more.

Dave.