On Thu, 2010-08-05 at 12:47 -0700, Timothy B. Terriberry wrote:
> So now it's just the suspend issue. Same behavior as 2.6.34:
> when resuming, the display is off, and switching VTs, etc., won't
> turn
> it on. What does work, if I type very carefully, is hibernating and
> then
> resuming.
Sus
Brice Goglin wrote:
Le 05/08/2010 20:47, Timothy B. Terriberry a écrit :
This no longer works on 2.6.35 (black screen after starting X).
Could be https://bugzilla.kernel.org/show_bug.cgi?id=16496 ?
Reverting that patch (or, more accurately, just deleting the redundant
backlight_off call) do
Le 05/08/2010 20:47, Timothy B. Terriberry a écrit :
> This no longer works on 2.6.35 (black screen after starting X).
Could be https://bugzilla.kernel.org/show_bug.cgi?id=16496 ?
Brice
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://
Any suggestions of patches to test for those of us still experiencing
eDP problems? I've seen a bunch fly by the list, but it's been unclear
to me which were supposed to address what issues, or how successful any
of them were.
I was able to get 2.6.34 to work on my Dell E6510 by reverting
885
On Thu, Aug 05, 2010 at 10:54:09AM -0700, Jesse Barnes wrote:
> Longer answer: drm-intel-next bits are targeted at the next kernel
> release. When important fixes from drm-intel-next land in Linus's tree,
> you can request that they be back ported to the stable tree by sending a
> note to sta...@k
On Thu, 05 Aug 2010 16:38:55 +0100
Sergio Monteiro Basto wrote:
> Hi, Have some kind of howto doc ?, about merging, testing os using
> drm-intel-next with a stable kernel, lets say kernel-2.6.35.
Short answer: you don't. The drm-intel-next branch is a full kernel
tree by itself, and I wouldn't
Hi, Have some kind of howto doc ?, about merging, testing os using
drm-intel-next with a stable kernel, lets say kernel-2.6.35.
Thanks,
--
Sérgio M. B.
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@li
