Ilia Mirkin, Wed, Feb 24, 2021 17:57:41 +0100:
> On Wed, Feb 24, 2021 at 11:53 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> > > Just to be crystal clear -- are you saying that 128x128 works or does
> > > not work? (You said "
Ilia Mirkin, Wed, Feb 24, 2021 17:48:39 +0100:
> On Wed, Feb 24, 2021 at 11:35 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> > > The fact that you're getting lines with modetest means there's
> > > something wrong with 256x
Ilia Mirkin, Wed, Feb 24, 2021 16:10:57 +0100:
> On Wed, Feb 24, 2021 at 4:09 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> > > It might also be worthwhile just testing if the 256x256 cursor works
> > > quite the way one would wa
Ilia Mirkin, Tue, Feb 23, 2021 19:13:59 +0100:
> On Tue, Feb 23, 2021 at 11:23 AM Alex Riesen
> wrote:
> >
> > $ xrandr --listproviders
> > Providers: number : 1
> > Provider 0: id: 0x68 cap: 0x7, Source Output, Sink Output, Source
> > Of
Alex Riesen, Tue, Feb 23, 2021 16:51:26 +0100:
> Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> > I'd recommend using xf86-video-nouveau in any case, but some distros
>
> I would like try this out. Do you know how to force the xorg server to
> choose this driver instead
Ilia Mirkin, Tue, Feb 23, 2021 16:46:52 +0100:
> On Tue, Feb 23, 2021 at 10:36 AM Alex Riesen
> wrote:
> > Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> > > On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> > > wrote:
> > > >
> > > > Thi
Ilia Mirkin, Tue, Feb 23, 2021 15:56:21 +0100:
> On Tue, Feb 23, 2021 at 9:26 AM Alex Riesen
> wrote:
> > Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> > > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > > b/drivers/gpu/drm/nouveau/dispnv50/d
Lyude Paul, Tue, Jan 19, 2021 02:54:13 +0100:
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index c6367035970e..5f4f09a601d4 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -2663,6 +2
On Fri, Mar 4, 2011 at 19:47, Linus Torvalds
wrote:
> Alex, can you confirm that the revert of 951f3512dba5 plus the
> one-liner patch from Takashi that Indan quoted also works for you?
I afraid mine is a different case, because backlight in this system
works properly even with Indan's patch reve
On Fri, Mar 4, 2011 at 19:47, Linus Torvalds
wrote:
> Alex, can you confirm that the revert of 951f3512dba5 plus the
> one-liner patch from Takashi that Indan quoted also works for you?
I afraid mine is a different case, because backlight in this system
works properly even with Indan's patch reve
On Fri, Feb 25, 2011 at 12:35, Alex Riesen wrote:
> On Fri, Feb 25, 2011 at 12:07, Indan Zupancic wrote:
>> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>>> So far I found only two patches (and three changes):
>>>
>>> This is the first:
>>>
&g
On Fri, Feb 25, 2011 at 12:35, Alex Riesen wrote:
> On Fri, Feb 25, 2011 at 12:07, Indan Zupancic wrote:
>> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>>> So far I found only two patches (and three changes):
>>>
>>> This is the first:
>>>
&g
On Fri, Feb 25, 2011 at 12:07, Indan Zupancic wrote:
> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>> So far I found only two patches (and three changes):
>>
>> This is the first:
>>
>> Corruption caused by portions of the screen stopped updating (th
On Fri, Feb 25, 2011 at 00:29, Indan Zupancic wrote:
>>> https://lkml.org/lkml/2011/2/23/34
>>
>> This is just the discussion about the problem described in the ticket.
>> It does not even mention the patch from the previous link, BTW.
>> It does have the patch which returns -EINVAL for
>> I915_P
On Fri, Feb 25, 2011 at 12:07, Indan Zupancic wrote:
> On Fri, February 25, 2011 11:18, Alex Riesen wrote:
>> So far I found only two patches (and three changes):
>>
>> This is the first:
>>
>> Corruption caused by portions of the screen stopped updating (th
On Fri, Feb 25, 2011 at 00:29, Indan Zupancic wrote:
>>> https://lkml.org/lkml/2011/2/23/34
>>
>> This is just the discussion about the problem described in the ticket.
>> It does not even mention the patch from the previous link, BTW.
>> It does have the patch which returns -EINVAL for
>> I915_P
On Thu, Feb 24, 2011 at 20:04, Alex Riesen wrote:
> So, AFAICS, at the moment there is no better patch than this:
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 17bd766..8f8a6a3 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/dr
On Thu, Feb 24, 2011 at 10:18, Indan Zupancic wrote:
>>>
>>> As it turns out this is a bug in the userspace components of the stack for
>>> gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
>>
>> Chris, could you point us at the patch? I ask because Daniel left a
>> comme
On Thu, Feb 24, 2011 at 20:04, Alex Riesen wrote:
> So, AFAICS, at the moment there is no better patch than this:
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 17bd766..8f8a6a3 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/dr
On Thu, Feb 24, 2011 at 10:18, Indan Zupancic wrote:
>>>
>>> As it turns out this is a bug in the userspace components of the stack for
>>> gen2 hardware, with lax kernel side enforcement. Daniel has a fix for both.
>>
>> Chris, could you point us at the patch? I ask because Daniel left a
>> comme
On Thu, Feb 24, 2011 at 01:13, Chris Wilson wrote:
> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds linux-foundation.org> wrote:
>> >
>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>
>> Any update on that one?
>
> No, reverting that will cause just another bug elsewhere. I ne
On Thu, Feb 24, 2011 at 01:13, Chris Wilson wrote:
> On Wed, 23 Feb 2011 15:58:02 -0800, Linus Torvalds
> wrote:
>> >
>> > See bug https://bugzilla.kernel.org/show_bug.cgi?id=27572
>>
>> Any update on that one?
>
> No, reverting that will cause just another bug elsewhere. I need to
> work out ho
On Mon, Jan 10, 2011 at 23:59, Dave Airlie wrote:
> The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:
>
> ?Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)
>
> are available in the git repository at:
>
> ?ssh://master.kernel.org/pub/scm/linux/k
On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>> Lastly, could you verify that my patch at
>> https://lkml.org/lkml/2011/2/16/447 fixes
>> it for you too? (Make sure you're at max brightness before rebooting.)
>
> I'll try it now.
>
I can confirm that i
Sorry for this late answer. I only get a very little time for this.
On Fri, Feb 18, 2011 at 05:57, Indan Zupancic wrote:
> On Thu, February 17, 2011 23:13, Tino Keitel wrote:
>> with kernel 2.6.37, the display brightness of my ThinkPad X61s was
>> always reduced after lid open, resume from suspen
On Mon, Jan 10, 2011 at 23:59, Dave Airlie wrote:
> The following changes since commit 989d873fc5b6a96695b97738dea8d9f02a60f8ab:
>
> Merge master.kernel.org:/home/rmk/linux-2.6-arm (2011-01-03 16:37:01 -0800)
>
> are available in the git repository at:
>
> ssh://master.kernel.org/pub/scm/linux/k
On Sat, Feb 19, 2011 at 13:11, Alex Riesen wrote:
>> Lastly, could you verify that my patch at
>> https://lkml.org/lkml/2011/2/16/447 fixes
>> it for you too? (Make sure you're at max brightness before rebooting.)
>
> I'll try it now.
>
I can confirm that i
Sorry for this late answer. I only get a very little time for this.
On Fri, Feb 18, 2011 at 05:57, Indan Zupancic wrote:
> On Thu, February 17, 2011 23:13, Tino Keitel wrote:
>> with kernel 2.6.37, the display brightness of my ThinkPad X61s was
>> always reduced after lid open, resume from suspen
On Wed, Feb 16, 2011 at 21:05, Jesse Barnes wrote:
> On Wed, 16 Feb 2011 20:59:35 +0100
> Alex Riesen wrote:
>>
>> I don't think it is related. I don't have problems switching
>> the outputs (frankly, didn't try) and I do have problems
>> restoring
On Wed, Feb 16, 2011 at 20:54, Jesse Barnes wrote:
> On Wed, 16 Feb 2011 20:46:45 +0100
> Alex Riesen wrote:
>> > The backlight level on this Dell XPS M1330 reduces every time I reopen
>> > the lid, and BIOS does not seem to know anything about that (the
>> > ke
On Wed, Feb 16, 2011 at 20:26, Alex Riesen wrote:
> Linus Torvalds, Wed, Feb 16, 2011 05:16:01 +0100:
>> Most of the changes are pretty spread out and small, with drivers/gpu
>> (radeon and i915) somewhat standing out from the pack. ...
>
> The backlight level on this Dell XP
Signed-off-by: Alex Riesen
---
Linus Torvalds, Wed, Feb 16, 2011 05:16:01 +0100:
> Most of the changes are pretty spread out and small, with drivers/gpu
> (radeon and i915) somewhat standing out from the pack. ...
The backlight level on this Dell XPS M1330 reduces every time I reopen t
On Wed, Feb 16, 2011 at 21:05, Jesse Barnes wrote:
> On Wed, 16 Feb 2011 20:59:35 +0100
> Alex Riesen wrote:
>>
>> I don't think it is related. I don't have problems switching
>> the outputs (frankly, didn't try) and I do have problems
>> restoring
On Wed, Feb 16, 2011 at 20:54, Jesse Barnes wrote:
> On Wed, 16 Feb 2011 20:46:45 +0100
> Alex Riesen wrote:
>> > The backlight level on this Dell XPS M1330 reduces every time I reopen
>> > the lid, and BIOS does not seem to know anything about that (the
>> > ke
On Wed, Feb 16, 2011 at 20:26, Alex Riesen wrote:
> Linus Torvalds, Wed, Feb 16, 2011 05:16:01 +0100:
>> Most of the changes are pretty spread out and small, with drivers/gpu
>> (radeon and i915) somewhat standing out from the pack. ...
>
> The backlight level on this Dell XP
Signed-off-by: Alex Riesen
---
Linus Torvalds, Wed, Feb 16, 2011 05:16:01 +0100:
> Most of the changes are pretty spread out and small, with drivers/gpu
> (radeon and i915) somewhat standing out from the pack. ...
The backlight level on this Dell XPS M1330 reduces every time I reopen t
Paris
> Tested-by: Dave Young
> Acked-by: James Morris
> Cc: Dave Airlie
> Cc: Alex Riesen
> Cc: Sedat Dilek
> Cc: Linus Torvalds
> Signed-off-by: Chris Wright
FWIW, I confirm the fix.
Paris
> Tested-by: Dave Young
> Acked-by: James Morris
> Cc: Dave Airlie
> Cc: Alex Riesen
> Cc: Sedat Dilek
> Cc: Linus Torvalds
> Signed-off-by: Chris Wright
FWIW, I confirm the fix.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Sun, Feb 13, 2011 at 07:22, Dave Young wrote:
> Finally I bisected it, results:
> 47970b1b2aa64464bc0a9543e86361a622ae7c03 is first bad commit
> commit 47970b1b2aa64464bc0a9543e86361a622ae7c03
> Author: Chris Wright
> Date: ? Thu Feb 10 15:58:56 2011 -0800
>
> ? ?pci: use security_capable() wh
On Sun, Feb 13, 2011 at 07:22, Dave Young wrote:
> Finally I bisected it, results:
> 47970b1b2aa64464bc0a9543e86361a622ae7c03 is first bad commit
> commit 47970b1b2aa64464bc0a9543e86361a622ae7c03
> Author: Chris Wright
> Date: Thu Feb 10 15:58:56 2011 -0800
>
> pci: use security_capable() wh
On Tue, Jan 11, 2011 at 14:33, Pavel Machek wrote:
>> I can reproduce the problem easily by:
>> xset dpms force standby; sleep 3s; xset dpms force on
>
> (You are using "vesa" or "fbcon" X11 driver, right? I seen same problem
> until I switched to "intel" X11 driver).
No, the "intel".
On Tue, Jan 11, 2011 at 14:33, Pavel Machek wrote:
>> I can reproduce the problem easily by:
>> xset dpms force standby; sleep 3s; xset dpms force on
>
> (You are using "vesa" or "fbcon" X11 driver, right? I seen same problem
> until I switched to "intel" X11 driver).
No, the "intel".
___
On Thu, Jan 6, 2011 at 21:55, Alex Riesen wrote:
> On Thu, Jan 6, 2011 at 18:49, Chris Wilson
> wrote:
>>
>> My fear is that some machines have a dependency between the backlight
>> and panel power status. The patch in question changed the timing between
>> turn
On Thu, Jan 6, 2011 at 18:49, Chris Wilson wrote:
>
> My fear is that some machines have a dependency between the backlight
> and panel power status. The patch in question changed the timing between
> turning on the panel and adjusting the backlight which would be restore
> with:
>
> diff --git a/
On Thu, Jan 6, 2011 at 21:55, Alex Riesen wrote:
> On Thu, Jan 6, 2011 at 18:49, Chris Wilson wrote:
>>
>> My fear is that some machines have a dependency between the backlight
>> and panel power status. The patch in question changed the timing between
>> turning on
On Thu, Jan 6, 2011 at 18:49, Chris Wilson wrote:
>
> My fear is that some machines have a dependency between the backlight
> and panel power status. The patch in question changed the timing between
> turning on the panel and adjusting the backlight which would be restore
> with:
>
> diff --git a/
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes wrote:
> That's the easiest way; I think there are existing packages available
> as well, but you may have to check Karmic or newer.
Never mind. I'm lazy (that's not to say someone is too).
I redid the test:
Before running "xset dpms force standby":
On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote:
> On Thu, Dec 30, 2010 at 00:13, Jesse Barnes
> wrote:
>>> After closing and opening the lid (displays backlight is back)
>>>
>>> ? http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>>
>
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes wrote:
>> After closing and opening the lid (displays backlight is back)
>>
>> ? http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>
> I need the intel_reg_dumper output, not intel_gpu_dump. :)
>
Hmm, there is no intel_reg_dumper in intel-gp
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes wrote:
>> > Doesn't change anything here. Display stays blank.
>>
>> Sounds like your problem is separate from SSC then, more likely related
>> to panel power or backlight control. ?Have you tried bisecting for the
>> problem between 2.6.35 and 2.6.36?
>
On Wed, Dec 29, 2010 at 22:18, Jesse Barnes wrote:
>> > + ? ? ? ? ? ? ? if (IS_GEN5(dev) || IS_GEN6(dev))
>> > + ? ? ? ? ? ? ? ? ? ? ? dev_priv->lvds_use_ssc = 0;
>>
>> Doesn't change anything here. Display stays blank.
>
> Sounds like your problem is separate from SSC then, more likely related
>
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes wrote:
> On Wed, 29 Dec 2010 11:40:04 -0800
> Linus Torvalds wrote:
>> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
>> we please just disable spread-spectrum entirely? Or perhaps only if we
>> notice that it was enabled already
On Thu, Dec 30, 2010 at 01:02, Jesse Barnes wrote:
> That's the easiest way; I think there are existing packages available
> as well, but you may have to check Karmic or newer.
Never mind. I'm lazy (that's not to say someone is too).
I redid the test:
Before running "xset dpms force standby":
On Thu, Dec 30, 2010 at 00:20, Alex Riesen wrote:
> On Thu, Dec 30, 2010 at 00:13, Jesse Barnes wrote:
>>> After closing and opening the lid (displays backlight is back)
>>>
>>> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>>
>&g
On Thu, Dec 30, 2010 at 00:13, Jesse Barnes wrote:
>> After closing and opening the lid (displays backlight is back)
>>
>> http://vin-soft.org/~raa/public/test/intel_gpu_dump-after-lid
>
> I need the intel_reg_dumper output, not intel_gpu_dump. :)
>
Hmm, there is no intel_reg_dumper in intel-gp
On Wed, Dec 29, 2010 at 22:53, Jesse Barnes wrote:
>> > Doesn't change anything here. Display stays blank.
>>
>> Sounds like your problem is separate from SSC then, more likely related
>> to panel power or backlight control. Have you tried bisecting for the
>> problem between 2.6.35 and 2.6.36?
>
On Wed, Dec 29, 2010 at 22:18, Jesse Barnes wrote:
>> > + if (IS_GEN5(dev) || IS_GEN6(dev))
>> > + dev_priv->lvds_use_ssc = 0;
>>
>> Doesn't change anything here. Display stays blank.
>
> Sounds like your problem is separate from SSC then, more likely related
>
On Wed, Dec 29, 2010 at 21:16, Jesse Barnes wrote:
> On Wed, 29 Dec 2010 11:40:04 -0800
> Linus Torvalds wrote:
>> Chris - why did that lvds_ssc_freq thing suddenly start mattering? Can
>> we please just disable spread-spectrum entirely? Or perhaps only if we
>> notice that it was enabled already
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
wrote:
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize
On Thu, Dec 23, 2010 at 04:54, Linus Torvalds
wrote:
> Why does that code need to figure out some LVDS clock from the BIOS?
> Why can't the code look at the actual hardware state or similar, since
> presumably the screen is on after boot. THAT we can rely on, since a
> BIOS that doesn't initialize
On Thu, Nov 11, 2010 at 22:10, Alex Riesen wrote:
> an alternative way to reproduce it, is to just wait for screensaver.
> Only the backlight is off, it is possible to see the image on LCD
> matrix if you get the angle right.
Bugzilla bug:
https://bugzilla.kernel.org/show_bug.cgi
On Thu, Nov 11, 2010 at 22:10, Alex Riesen wrote:
> an alternative way to reproduce it, is to just wait for screensaver.
> Only the backlight is off, it is possible to see the image on LCD
> matrix if you get the angle right.
Bugzilla bug:
https://bugzilla.kernel.org/show_bug.cgi?id=22672
Hi,
an alternative way to reproduce it, is to just wait for screensaver.
Only the backlight is off, it is possible to see the image on LCD
matrix if you get the angle right.
The system is the by now fairly old Dell XPS M1330, 64 bit kernel,
KMS used (and works since 2.6.35), no 3D.
There is sadly
63 matches
Mail list logo
