At Thu, 3 Feb 2011 17:11:14 -0800,
Linus Torvalds wrote:
>
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard 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
On Fri, Feb 4, 2011 at 11:11 AM, Linus Torvalds
wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard 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
On Fri, Feb 4, 2011 at 10:30 AM, Linus Torvalds
wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie wrote:
>>
>> 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.
>
> The more I look at that function, the
On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
wrote:
> On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra 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
On Thu 3.Feb'11 at 17:11:14 -0800, Linus Torvalds wrote:
> On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard 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
At Thu, 3 Feb 2011 17:11:14 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.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
On Thu, Feb 3, 2011 at 8:09 PM, Rafael J. Wysocki wrote:
> On Thursday, February 03, 2011, Takashi Iwai wrote:
>> At Thu, 3 Feb 2011 07:42:05 -0800,
>> Linus Torvalds wrote:
>> >
>> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra
>> > wrote:
>> > > On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael
On Thursday, February 03, 2011, Takashi Iwai wrote:
> At Thu, 3 Feb 2011 07:42:05 -0800,
> Linus Torvalds wrote:
> >
> > On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra
> > wrote:
> > > On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
> > >>
> > >> If you know of any other
On Thu, 3 Feb 2011 17:11:14 -0800, Linus Torvalds wrote:
> 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?
None of the existing drivers turn anything on or off in the
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
>
> On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra wrote:
> > On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael J. Wysocki wrote:
> >>
> >> If you know of any other unresolved post-2.6.36 regressions, please let us
> >> know
> >> either and
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard 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
On Thu, 3 Feb 2011 16:30:56 -0800, Linus Torvalds wrote:
> On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie wrote:
> >
> > 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.
>
> The more I look at that
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie wrote:
>
> 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.
The more I look at that function, the more I disagree with you and
with that patch.
The code is just
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
wrote:
>
> Maybe the right thing to do is to set it to 'unknown', something like this.
>
> TOTALLY UNTESTED!
Doing some grepping and "git blame", I found this: commit 032d2a0d068
("drm/i915: Prevent double dpms on") which took a very similar
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra 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
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
>
> If you know of any other unresolved post-2.6.36 regressions, please let us
> know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
I'm sorry if I'm overlooking
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra wrote:
> On Thu ?3.Feb'11 at ?1:03:41 +0100, Rafael J. Wysocki wrote:
>>
>> If you know of any other unresolved post-2.6.36 regressions, please let us
>> know
>> either and we'll add them to the list. ?Also, please let us know if any
>> of the
This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com wrote:
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
If you know of any other unresolved post-2.6.36 regressions, please let us
know
either and we'll add them to the list. Also, please let us know if any
of
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com wrote:
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
If you know of any other unresolved post-2.6.36 regressions, please let us
know
either and
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
If you know of any other unresolved post-2.6.36 regressions, please let us
know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
I'm sorry if I'm overlooking something, but
On Thursday, February 03, 2011, Takashi Iwai wrote:
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com wrote:
On Thu 3.Feb'11 at 1:03:41 +0100, Rafael J. Wysocki wrote:
If you know of any other unresolved
On Thu, Feb 3, 2011 at 8:09 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Thursday, February 03, 2011, Takashi Iwai wrote:
At Thu, 3 Feb 2011 07:42:05 -0800,
Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 3:23 AM, Carlos R. Mafra crmaf...@gmail.com wrote:
On Thu 3.Feb'11 at 1:03:41 +0100,
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra crmaf...@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
On Thu, Feb 3, 2011 at 2:10 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Maybe the right thing to do is to set it to 'unknown', something like this.
TOTALLY UNTESTED!
Doing some grepping and git blame, I found this: commit 032d2a0d068
(drm/i915: Prevent double dpms on) which took a
On Fri, Feb 4, 2011 at 8:10 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Feb 3, 2011 at 1:56 PM, Carlos Mafra crmaf...@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
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie airl...@gmail.com wrote:
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.
The more I look at that function, the more I disagree with you and
with that patch.
The
On Fri, Feb 4, 2011 at 10:30 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie airl...@gmail.com wrote:
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.
The
On Thu, 3 Feb 2011 16:30:56 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Feb 3, 2011 at 4:06 PM, Dave Airlie airl...@gmail.com wrote:
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.
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.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,
On Thu, 3 Feb 2011 17:11:14 -0800, Linus Torvalds
torva...@linux-foundation.org wrote:
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?
None of the existing drivers turn
On Fri, Feb 4, 2011 at 11:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.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
On Thu 3.Feb'11 at 17:11:14 -0800, Linus Torvalds wrote:
On Thu, Feb 3, 2011 at 5:05 PM, Keith Packard kei...@keithp.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
This message contains a list of some post-2.6.36 regressions introduced before
2.6.37, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.36 regressions, please let us
34 matches
Mail list logo
