* Nick Bowler -- Tuesday 21 June 2011:
> We're at -rc4 now, but it seems that the following patch (drm/i915: add
> missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made
> it in yet?
>
> http://permalink.gmane.org/gmane.linux.kernel/1148279
>
> The i915 driver has been broken s
* Nick Bowler -- Tuesday 21 June 2011:
> We're at -rc4 now, but it seems that the following patch (drm/i915: add
> missing intel_enable_plane() call to i9xx_crtc_mode_set()) has not made
> it in yet?
>
> http://permalink.gmane.org/gmane.linux.kernel/1148279
>
> The i915 driver has been broken s
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting
* Nick Bowler -- Monday 06 June 2011:
> After upgrading to 3.0-rc2, my second display is no longer working
> correctly on a desktop with an Intel G45 graphics chip.
[...]
> What I do know is that the problem was originally introduced by
> 49183b2818de ("drm/i915: Only enable the plane after setting
From: Melchior FRANZ
Fix garbled up virtual linux console on Acer TM 5735Z-452G32Mnss
(colored stripes, unreadable text) by adding the intel_enable_plane()
call also to i9xx_crtc_mode_set(), which didn't inherit it from
intel_crtc_mode_set() like its twin ironlake_crtc_mode_set().
Signed-o
From: Melchior FRANZ
Fix garbled up virtual linux console on Acer TM 5735Z-452G32Mnss
(colored stripes, unreadable text) by adding the intel_enable_plane()
call also to i9xx_crtc_mode_set(), which didn't inherit it from
intel_crtc_mode_set() like its twin ironlake_crtc_mode_set().
Signed-o
* Melchior FRANZ -- Thursday 12 May 2011:
> > Chris Wilson (4):
> > drm/i915: Only enable the plane after setting the fb base (pre-ILK)
>
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame b
* Melchior FRANZ -- Thursday 12 May 2011:
> > Chris Wilson (4):
> > drm/i915: Only enable the plane after setting the fb base (pre-ILK)
>
> This patch introduces a bug on my infamous "Acer Travelmate
> 5735Z-452G32Mnss": when KMS takes over, the frame b
Hey,
* Michael Chang -- Tuesday 17 May 2011:
> If you change brightness from lowest to highest, the LPBC value changes
> this way
>
> Highest Lowest
> 0x10 , 0x19 .. 0xe5
Yes. (Though it's 0x01, not 0x10.)
---0xFF ... initial value and after closing/reopening l
* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
> You can know your LPBC value by:
> $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
>
> And alter it's value via setpci (assuming set it to max)
> $ setpci -s 00:02.0 F4.B=ff
>
> I assume you've tried this .. as you report setpci works for you
Hey,
* Michael Chang -- Tuesday 17 May 2011:
> If you change brightness from lowest to highest, the LPBC value changes
> this way
>
> Highest Lowest
> 0x10 , 0x19 .. 0xe5
Yes. (Though it's 0x01, not 0x10.)
---0xFF ... initial value and after closing/reopening l
* Michael Chang -- Tuesday 17 May 2011:
[LBPC]
> You can know your LPBC value by:
> $ lspci -xxx -s 00:02.0 | awk '/^f0:/ {print $6}'
>
> And alter it's value via setpci (assuming set it to max)
> $ setpci -s 00:02.0 F4.B=ff
>
> I assume you've tried this .. as you report setpci works for you
* Takashi Iwai -- Sunday 15 May 2011:
> IIRC, you reported that the backlight gets normal when you revert my
> commit in 2.6.38.x. So, this was regarded as a regression at first.
Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in
https://bug
* Takashi Iwai -- Sunday 15 May 2011:
> IIRC, you reported that the backlight gets normal when you revert my
> commit in 2.6.38.x. So, this was regarded as a regression at first.
Yes. And it *is* a regression, which is the whole point of my
initial complaint, as reported by Maciej in
https://bug
Hey,
* Michael Chang -- Friday 13 May 2011:
> But there's more questions in my mind, made me feel not
> able to proceed any further.. :(
No problem. The reason for inconsistencies in my reports is
simply that I've realized some properties only later. So here's
a new error description, based on dd
Hey,
* Michael Chang -- Friday 13 May 2011:
> But there's more questions in my mind, made me feel not
> able to proceed any further.. :(
No problem. The reason for inconsistencies in my reports is
simply that I've realized some properties only later. So here's
a new error description, based on dd
* Chris Wilson -- Thursday 12 May 2011:
> So we think that enabling the plane at this point is masking a bug in our
> modeset, or that some side-effect of writing those registers or waiting
> for that vblank has a vital latching or delay that we have not accounted
> for.
Attached are the requested
* Chris Wilson -- Thursday 12 May 2011:
> So we think that enabling the plane at this point is masking a bug in our
> modeset, or that some side-effect of writing those registers or waiting
> for that vblank has a vital latching or delay that we have not accounted
> for.
Attached are the requested
* Linus Torvalds -- Tuesday 10 May 2011:
> But please do test, just to make sure that 39-final is good.
> Chris Wilson (4):
> drm/i915: Only enable the plane after setting the fb base (pre-ILK)
This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes ove
* Linus Torvalds -- Tuesday 10 May 2011:
> But please do test, just to make sure that 39-final is good.
> Chris Wilson (4):
> drm/i915: Only enable the plane after setting the fb base (pre-ILK)
This patch introduces a bug on my infamous "Acer Travelmate
5735Z-452G32Mnss": when KMS takes ove
* Michael Chang -- Tuesday 10 May 2011:
> Could you please try this patch and get the log ? We wonder why
> is_backlight_combination_mode () returns false.
This information was already buried in the bugzilla thread:
https://bugzilla.kernel.org/show_bug.cgi?id=31522
"It turned out that on this
* Michael Chang -- Tuesday 10 May 2011:
> Could you please try this patch and get the log ? We wonder why
> is_backlight_combination_mode () returns false.
This information was already buried in the bugzilla thread:
https://bugzilla.kernel.org/show_bug.cgi?id=31522
"It turned out that on this
* Joey Lee -- Monday 09 May 2011:
> The following is debug patch, and please add kernel parameter
> drm.debug=0x02 :
The result is with acpi_osi=Linux:
boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlig
* Joey Lee -- Monday 09 May 2011:
> The following is debug patch, and please add kernel parameter
> drm.debug=0x02 :
The result is with acpi_osi=Linux:
boot phase:
[3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
[3.310280] [drm:intel_panel_get_backlight], get backlig
* Joey Lee -- Sunday 08 May 2011:
> ? ??2011-05-07 ? 22:22 +0200?Melchior FRANZ ???
> > It has turned out that acpi key events seem to be handled correctly
> > and even the state of /sys/class/backlight/acer-wmi/brightness is
>
> That's interesting for acer-wmi generated
* Joey Lee -- Sunday 08 May 2011:
> 於 六，2011-05-07 於 22:22 +0200，Melchior FRANZ 提到：
> > It has turned out that acpi key events seem to be handled correctly
> > and even the state of /sys/class/backlight/acer-wmi/brightness is
>
> That's interesting for acer-wmi generated
* Melchior FRANZ -- Friday 06 May 2011:
> last patch prevents the backlight from being turned off, but it also
> breaks the brightness adjustment keys at runtime with acpi_osi=Linux.
It has turned out that acpi key events seem to be handled correctly
and even the state of /sys/class/bac
* Melchior FRANZ -- Friday 06 May 2011:
> last patch prevents the backlight from being turned off, but it also
> breaks the brightness adjustment keys at runtime with acpi_osi=Linux.
It has turned out that acpi key events seem to be handled correctly
and even the state of /sys/class/bac
* Joey Lee -- Friday 06 May 2011:
> ? ??2011-05-06 ? 10:52 +0200?Melchior FRANZ ???
> > ... and changing backlight brightness worked with acpi_osi=Linux, too.
> > Unfortunately, that does no longer work now, although I haven't changed
> > anything. Pressing the brightnes
* Melchior FRANZ -- Thursday 05 May 2011:
> This revised patch works correctly for me.
... and changing backlight brightness worked with acpi_osi=Linux, too.
Unfortunately, that does no longer work now, although I haven't changed
anything. Pressing the brightness buttons causes some AC
* Joey Lee -- Friday 06 May 2011:
> 於 五，2011-05-06 於 10:52 +0200，Melchior FRANZ 提到：
> > ... and changing backlight brightness worked with acpi_osi=Linux, too.
> > Unfortunately, that does no longer work now, although I haven't changed
> > anything. Pressing the brightnes
* Melchior FRANZ -- Thursday 05 May 2011:
> This revised patch works correctly for me.
... and changing backlight brightness worked with acpi_osi=Linux, too.
Unfortunately, that does no longer work now, although I haven't changed
anything. Pressing the brightness buttons causes some AC
* Takashi Iwai -- Thursday 05 May 2011:
> Try the fixed patch below.
> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 456f404..4c6e187 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -332,6 +332,7 @@ typedef
* Takashi Iwai -- Thursday 05 May 2011:
> Try the fixed patch below.
> ---
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 456f404..4c6e187 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -332,6 +332,7 @@ typedef
* Takashi Iwai -- Monday 02 May 2011:
* > At Sat, 30 Apr 2011 13:34:51 +0200, Melchior FRANZ wrote:
> > * Takashi Iwai -- Saturday 30 April 2011:
> > > acpi_osi quirk should be better added statically, then.
> >
> > No, I guess the problem here is that acer_wmi do
* Takashi Iwai -- Monday 02 May 2011:
* > At Sat, 30 Apr 2011 13:34:51 +0200, Melchior FRANZ wrote:
> > * Takashi Iwai -- Saturday 30 April 2011:
> > > acpi_osi quirk should be better added statically, then.
> >
> > No, I guess the problem here is that acer_wmi do
Dropping Linus from the CC.
* Takashi Iwai -- Saturday 30 April 2011:
* * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote:
> > Yes, backlight adjustment generally works on this notebook, but only
> > with "acpi_osi=Linux" on the command line.
>
> acpi_osi
* Takashi Iwai -- Saturday 30 April 2011:
> I remember vaguely that the value zero could be interpreted as the max.
> Also, with the patch, does the backlight level can be adjusted
> correctly to different values? I wonder whether LBPC adjustment
> really works or not on your machine.
> +
Dropping Linus from the CC.
* Takashi Iwai -- Saturday 30 April 2011:
* * At Sat, 30 Apr 2011 10:32:04 +0200, Melchior FRANZ wrote:
> > Yes, backlight adjustment generally works on this notebook, but only
> > with "acpi_osi=Linux" on the command line.
>
> acpi_osi
* Takashi Iwai -- Saturday 30 April 2011:
> I remember vaguely that the value zero could be interpreted as the max.
> Also, with the patch, does the backlight level can be adjusted
> correctly to different values? I wonder whether LBPC adjustment
> really works or not on your machine.
> +
* Takashi Iwai -- Friday 29 April 2011:
[https://bugzilla.kernel.org/show_bug.cgi?id=31522]
> Looking at bugzilla, the problem seems like the case lbpc=0.
> What about the patch below instead?
> - val *= lbpc;
> + if (lbpc)
> + va
* Takashi Iwai -- Friday 29 April 2011:
> Melchior FRANZ wrote:
> > The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
> > [...] when using KMS my notebook's[2] screen remains dark, because the
> > backlight isn't turned on.
> Could
* Linus Torvalds -- Wednesday 27 April 2011:
> Go forth and test,
Doesn't work on my notebook with i915/KMS. But then again, neither did
2.6.38 or any of its stable releases. The last working version was
2.6.38-rc8. The problem has been reported[1], but the bug got closed
in the wrong assumption t
* Takashi Iwai -- Friday 29 April 2011:
[https://bugzilla.kernel.org/show_bug.cgi?id=31522]
> Looking at bugzilla, the problem seems like the case lbpc=0.
> What about the patch below instead?
> - val *= lbpc;
> + if (lbpc)
> + va
* Takashi Iwai -- Friday 29 April 2011:
> Melchior FRANZ wrote:
> > The bug was introduced with commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0
> > [...] when using KMS my notebook's[2] screen remains dark, because the
> > backlight isn't turned on.
> Could
* Linus Torvalds -- Wednesday 27 April 2011:
> Go forth and test,
Doesn't work on my notebook with i915/KMS. But then again, neither did
2.6.38 or any of its stable releases. The last working version was
2.6.38-rc8. The problem has been reported[1], but the bug got closed
in the wrong assumption t
* Melchior FRANZ -- Tuesday 26 April 2011:
> [https://bugzilla.kernel.org/show_bug.cgi?id=31522]
I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/l
* Melchior FRANZ -- Tuesday 26 April 2011:
> [https://bugzilla.kernel.org/show_bug.cgi?id=31522]
I've replied to this error message, but here again for this audience:
The commit that broke all 2.6.38.* releases for my machine is this:
http://git.kernel.org/?p=linux/kernel/git/torvalds/l
* Chris Wilson -- Wednesday 16 March 2011:
> There's only one patch directly related to i915, so you could begin there.
I'll try later. Was just too obvious for now. :-}
> Useful information to include is a dmesg (particularly one with
> drm.debug=0xe kernel parameters) and lspci
OK, thanks f
* Chris Wilson -- Wednesday 16 March 2011:
> There's only one patch directly related to i915, so you could begin there.
I'll try later. Was just too obvious for now. :-}
> Useful information to include is a dmesg (particularly one with
> drm.debug=0xe kernel parameters) and lspci
OK, thanks f
50 matches
Mail list logo
