[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTim-1MofNWc_PkmKE3dPWB3Ahe8d8jP_aUD5konx@mail.gmail.com>
Date: Fri, 4 Feb 2011 11:42:33 +1000
From: Dave Airlie <airlied@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Keith Packard <keithp@...thp.com>,
Carlos Mafra <crmafra2@...il.com>,
Dave Airlie <airlied@...hat.com>,
"Rafael J. Wysocki" <rjw@...k.pl>, Takashi Iwai <tiwai@...e.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Maciej Rutecki <maciej.rutecki@...il.com>,
Florian Mickler <florian@...kler.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Kernel Testers List <kernel-testers@...r.kernel.org>,
Network Development <netdev@...r.kernel.org>,
Linux ACPI <linux-acpi@...r.kernel.org>,
Linux PM List <linux-pm@...ts.linux-foundation.org>,
Linux SCSI List <linux-scsi@...r.kernel.org>,
Linux Wireless List <linux-wireless@...r.kernel.org>,
DRI <dri-devel@...ts.freedesktop.org>
Subject: Re: 2.6.38-rc3-git1: Reported regressions 2.6.36 -> 2.6.37
On Fri, Feb 4, 2011 at 11:11 AM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard <keithp@...thp.com> wrote:
>>
>> The goal is to make it so that when you *do* set a mode, DPMS gets set
>> to ON (as the monitor will actually be "on" at that point). Here's a
>> patch which does the DPMS_ON precisely when setting a mode.
>
> Ok, patch looks sane, but it does leave me with the "what about the
> 'fb_changed' case?" question. Is that case basically guaranteed to not
> change any existing dpms state?
Yes its inconsistent behaviour but nothing in the fb_changed case will
affect the DPMS
state. I expect we should probably do that so all paths via that
function turn DPMS on,
and it'll be consistent, might be something for 39.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists