Hi Daniel, hi others,
Can you please boot with drm.debug=0xe and grab a new dmesg with the
backtrace?
Ok, thanks for looking into this, and sorry for taking so long. I'm back
now and had now finally some availability to check this issue again with
the latest kernel.
Seems to be fixed,
On 15.08.2014 00:22, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Looks perfectly fine to me.
Signed-off-by: Thomas Richter rich...@rus.uni-stuttgart.de
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915
-by: Thomas Richter rich...@rus.uni-stuttgart.de
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 529 +++---
1 file changed, 325 insertions(+), 204 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b
On 15.08.2014 00:22, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Looks like IEGD does a one time init
800x600 mode. Looks fine.
Signed-off-by: Thomas Richter rich...@rus.uni-stuttgart.de
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/dvo_ns2501.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501.c
b
the plane B and C max watermark value.
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm
...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/intel_display.c | 37 +---
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915
. Seems
to be fine so far.
v2: Disable double wide also when turning the pipe off
v3: Reorder wrt. force pipe B quirk
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/intel_display.c | 20
...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 56b47d2..d5ea393 100644
--- a/drivers/gpu/drm
On 15.08.2014 00:22, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Calling the mode_set hook on DPMS changes doesn't seem to be necessary
for ns2501. Just drop it.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Thomas Richter
-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/intel_dvo.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index
On 15.08.2014 00:22, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/dvo_ns2501.c | 17 -
1
.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/dvo_ns2501.c | 529 +++---
1 file changed, 325 insertions(+), 204 deletions(-)
diff --git a/drivers/gpu/drm/i915/dvo_ns2501
trick the VGA BIOS to set up
the 56Hz mode we can't get the magic values for the orther mode. So
when checking whether a mode is valid also check the pixel clock so that
we filter out the 56Hz variant.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Reviewed-by: Thomas Richter rich
...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 47 +---
2 files changed, 46 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b
.
Reviewed-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 6462bcf..e1c0c0b 100644
--- a/drivers/gpu/drm/i915
things get enabled.
v2: Reorder wrt. double wide handling changes
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Tested-by: Thomas Richter rich...@rus.uni-stuttgart.de
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 39
disable bit
doesn't interfere with the S3 resume fortunately.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
Works on the S6010 as advertized, though cannot test on the R31 since it
does not resume from S3 - it does not even reach the real-mode entry
hook of the kernel.
Tested-by: Thomas
Hi Ville
just testing your alm_fixes11 branch. So far, everything works fine,
including suspend2ram, for the first time! Yippiee!
However, there is one thing that bothers me, namely that the brightness
adjustment is no longer working. Specifically, fujitsu_laptop fails with:
Fujitsu laptop
Hi Ville, hi Daniel,
this is again a ping on the status of the i830 code. I reviewed the
code I received, at least the code I could review (I do not know enough
about the internal wirings of the intel_display source, only on the
ns2501 dvo source), but I haven't heart anything back. Is there
Hi Daniel, dear list,
just tried the latest nightly build of 3.15.0+, and I'm sorry to say
that the watermark configuration of the 830GM is still off.
This is what I get from the kernel: (not to be taken too serious, but
humor is the only thing that keeps me from getting seriously anoyed
Am 16.05.2014 18:50, schrieb Daniel Vetter:
On Fri, May 16, 2014 at 07:04:54PM +0300, Ville Syrjälä wrote:
On Fri, May 16, 2014 at 05:09:53PM +0200, Daniel Vetter wrote:
On Fri, May 16, 2014 at 03:41:05PM +0100, Chris Wilson wrote:
On Fri, May 16, 2014 at 04:02:48PM +0200, Thomas Richter
Hi Daniel, hi folks,
still a couple of observations from my side on this. The 1024x786x24
mode here uses a clock of 65MHz (65000kHz), if that is inserted into the
watermark computation, it computes from that a prefetch of 40 entries,
and thus a watermark level of four, which is much much too
Hi Daniel, hi folks,
according to my knowledge, the pipe A quirk is unconditionally enabled
on the 830 to allow resume to work properly. Unfortunately, it does
quite the opposite on the S6010, it breaks resume completely.
If the pipe A quirk is disabled, then the boot console works
Hi folks,
as by discussion, the problem with the i830 watermark problems is likely
that the 830 requires the number of entries in the buffer to be a
multiple of the cache line size. I provide hereby a small patch
against intel_pm.c that performs the alignment for GEN2 chips.
Tested on the
Am 02.06.2014 10:27, schrieb Daniel Vetter:
Can you go right ahead and please submit this as a patch?
Certainly, but I would prefer to get more information on this. Even
though the R31 *also* works without the pipe A quirk, I am not sure it
does work on all other hardware configurations.
Hi Daniel, hi others,
please find a patch attached that disables the pipe A quirk for the
Fujitsu S6010. I will probably add a line for the R31 later, I only
need to add the model number.
How is the watermark-alignment patch for the 830 doing, btw?
Greetings,
Thomas
From
Hi Daniel,
From 2006abcd850f8c0995153ffb491efd590103f17f Mon Sep 17 00:00:00 2001
From: thort...@math.tu-berlin.de
Date: Mon, 2 Jun 2014 17:32:55 +0200
Subject: [PATCH 2/2] Disabling the pipe A quirk for the Fujitsu S6010.
Signed-off-by: thort...@math.tu-berlin.de
Like I've explained,
Am 02.06.2014 19:39, schrieb Daniel Vetter:
nack = not acknowledged, i.e. rejected. Comes from tcp. I've applied the
patch instead to just remove the quirk on all i830M.
Ok, thanks, I'm fine with that.
Greetings,
Thomas
___
Intel-gfx
Hi Daniel, dear intel experts,
We've put a crtc restriction on VGA (it needs to be crtc 0) to work around
some issues. DVI/LVDS should work on crtc 1. You can set this with the
--crtc knob for xrandr.
Unfortunately, I cannot. Whenever I put DVI1 (which is connected to the
internal screen) on
Am 03.06.2014 16:45, schrieb Daniel Vetter:
Yeah, both connectors use CRTC 0. Have you tried what happens if you:
- disable DVI1 first (--off)
- then enable it on crtc 1?
Same difference, internal screen goes blank with --off, and stays blank
after moving it to crtc 1 if I try to re-enable
Am 03.06.2014 17:14, schrieb Chris Wilson:
On Tue, Jun 03, 2014 at 05:04:52PM +0200, Thomas Richter wrote:
Am 03.06.2014 16:45, schrieb Daniel Vetter:
Yeah, both connectors use CRTC 0. Have you tried what happens if you:
- disable DVI1 first (--off)
- then enable it on crtc 1?
Same
Am 03.06.2014 17:26, schrieb Chris Wilson:
I should have said VGA. Thinking about it, it is likely a shared DDC line
so that only a single EDID can be read.
Actually, it gets the EDID from the VGA panel just fine, also shows me
the modes it supports. DVI1 has no edit, though it gets its
Hi folks,
when switching resolutions with xrandr (or otherwise) on the 830MG
chipset, I usually get a Pipe A underrun error,
sometimes resulting in a completely black screen. To my understanding,
the internal screen is connected to pipe B on
this laptop, thus I wonder why I get the error.
Am 05.06.2014 22:43, schrieb Chris Wilson:
On Thu, Jun 05, 2014 at 07:15:50PM +0300, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjäläville.syrj...@linux.intel.com
Using names initializers when filling out the watermark structs
saves you from having go look up the struct definition
Update on the 830MG Updates:
As Ville already said, resume from suspend-to-ram is broken. No
surprise, old broken bios. However, there is a big difference between
the kernel with the pipe-A quirk disabled, and the one with pipe-a and
pipe-b quirks enabled: If resumed without the quirk, the
Hi Ville, hi others,
As Ville already said, resume from suspend-to-ram is broken. No
surprise, old broken bios. However, there is a big difference between
the kernel with the pipe-A quirk disabled, and the one with pipe-a and
pipe-b quirks enabled: If resumed without the quirk, the display is
Am 06.06.2014 22:08, schrieb Ville Syrjälä:
Yup, I flashed the bios last week with version 1.07, the latest I could
find on the Fujitsu pages. It was 1.06 before, though I did not observe
any difference between 1.06 and 1.07 with respect to the broken resume
operation.
1.07 is what have as
Am 07.06.2014 00:23, schrieb Daniel Vetter:
On Fri, Jun 6, 2014 at 11:15 PM, Bob Paauwebob.j.paa...@intel.com wrote:
+ /* Fujitsu-Siemens Lifebook S6010 VBT lies */
+ if (IS_I830(dev))
+ return true;
My old D945GNT board with a 945G and really old BIOS also has a VBT
that
Dear Daniel, dear intel experts,
please find a minimally-invasive patch to add a minimum watermark level
to the current watermark logic. This fixes the flickering and video
overlay crashes on 830M(G) chipsets. Note that this patch does not alter
the watermark algorithm on any other family of
Dear intel experts,
just tried to debug the i830 resume on the S6010. With netconsole and
netcat, I found that the kernel locks up when trying to load the i915
module on suspend. Here is the output of the kernel:
[ 1772.867519] hid-generic 0003:046D:C05F.002B: input,hidraw0: USB HID
v1.11
Dear intel experts,
the attached patch is a minimally invasive modification of the watermark
computation for the 830GM chipset graphics. It adds a minimum watermark
level to test against. The minimum value is zero for all other families
of the intel chipset graphics, thus causing no change
Hi Ville, hi Daniel, dear intel experts,
just went through the problem I send around, and I guess I understand
now what happens here. The reason *why* resume fails is that there is a
deadlock situation in intel_display.c:
*) loading the module calls intel_modeset_init()
*)
Hi Ville, dear intel experts,
without the deadlock in i915, I had at least a partial success in
restoring the video on the Fujitsu S6010.
Apparently, the bios does not re-initialize the 830MG registers, nor the
registers of the ns2501 DVO.
Instead, the 830MG is configured in a 640x480 mode (no
Am 09.06.2014 13:08, schrieb Ville Syrjälä
No, we do restore the mode you were using before suspend.
Are you still using vbetool? That would explain why things go bad since
vbetool will clobber whatever i915 already did.
No, vbetool is out of the equation (see the script attached to the
Am 09.06.2014 13:31, schrieb Ville Syrjälä:
So now you're using acpi_sleep=s3_bios, or nothing?
Ok, tried now with acpi_sleep=s3. Unfortunately, this hangs the machine
completely during resume, I cannot even ping it.
Then, I tried the same trick again, namely unloading the i915 module
Hi Ville, dear Intel experts,
more on the partial resume from suspend for the S6010. It seems that the
culprit is really the lack of a proper
initialization of the DVO. The minimum sequence to restore the display
does not require to modify the 830 registers
directly, but rather needs to setup
Am 09.06.2014 21:46, schrieb ville.syrj...@linux.intel.com:
From: Ville Syrjäläville.syrj...@linux.intel.com
In my earlier rewrite I missed a few important registers. Thomas Richter
noticed that they're needed to make his machine resume correctly.
Thanks, this *almost* works, much better than
Hi Ville,
thanks for the latest patch. As said, the screen did not come back quite
correctly. I checked the register values
again, and I am sorry to say that I was wrong - register values do
differ. Apparently, the code configures now
the wrong pipe to generate output to the DVO and thus the
Hi Ville,
Either pipe can drive DVO just fine. Looks like it's using pipe A in
your register dump, and all the registers look fine to me. Well, DPLL B
VCO enable is off since we don't currently have a mechanism to kick pipe
B into action during resume/load. In theory that would need to be
Am 15.06.2014 14:26, schrieb Ville Syrjälä:
We all know nightly is rather broken with 830. Nothing new here. I
suggest just trying my alm_fixes5 branch.
Excuse my ignorance, but there is something I do not get. There are
patches that are tested and working. Having them in an off-side
Am 16.06.2014 19:59, schrieb Daniel Vetter:
On Sun, Jun 15, 2014 at 09:38:49PM +0200, Thomas Richter wrote:
Thanks for keeping the repository, but that's not a solution, at least not
for most of the remaining users of old hardware.
Repositories with patches are normal procedures until those
Hi Martin,
I'm trying to figure out how to ask X what color depth it is using...?
I think:
martin@merkaba:~ xdpyinfo | grep -i depth of root
depth of root window:24 planes
but am not completely sure.
This is thinkpad x60 with Debian 6.0.9.
AFAIK the 830GM chipset does not offer
Hi Daniel, hi group,
just being curious - what is the status of the i830 watermark problems,
i.e. the state of affairs
concerning that the i830 does not allow the maximum watermark value, but
requires a headroom of eight entries to
avoid flickering.
I provided a patch for this a while ago,
Am 25.11.2013 16:23, schrieb Daniel Vetter:
On Mon, Nov 25, 2013 at 04:14:12PM +0100, Thomas Richter wrote:
Hi Daniel, hi group,
just being curious - what is the status of the i830 watermark
problems, i.e. the state of affairs
concerning that the i830 does not allow the maximum watermark value
Hi Daniel,
just a short notice that I tried the same patch - namely adjusting the
minimum watermark value (thus the maximual watermark setting) now on the
i830 based Fujitsu, and it does work here as well as it did on the R31.
Thus, this seems to be the real culprit.
This is the laptop with
On 12/02/2013 02:26 PM, Rodrigo Vivi wrote:
From: Daniel Vetterdaniel.vet...@ffwll.ch
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max
Hi Daniel, hi folks,
back from a couple of business trips, so finally some time to look into
the i830 support on this old laptop.
Sorry to say that the current drm-nightly does not work at all. It just
generates a hang, resulting in a black screen and nothing else. All you
can do there is
Hi Daniel, hi folks,
here is more debug output from the blank screen/hang on the i830 based
laptop:
Dec 19 15:48:19 tyleet kernel: [ 10.919155] [drm:drm_pci_init],
Dec 19 15:48:19 tyleet kernel: [ 11.317545] lib80211_crypt: registered
algorithm 'NULL'
Dec 19 15:48:19 tyleet kernel: [
Hi Daniel,
Quick shot in the dark: Can you please try the below diff?
If that doesn't work please remove the locking in that function completely
(i.e. remove the calls to drm_modset_lock|unlock_all).
If that doesn't help please compile a pristine -nightly with lockdep
(CONFIG_PROVE_LOCKING)
Dear intel-experts,
a while ago I reported that the latest kernel from intel-drm-nightly
broke operations on i830 completely. In the meantime,
I found the reason. The trouble is in intel_crtcl_init():
static void intel_crtc_init(struct drm_device *dev, int pipe)
{
/*
* On
On 01/07/2014 03:15 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjäläville.syrj...@linux.intel.com
Looks like I managed to break 830M in a few different ways recently. But I
recently found one for myself so hopefully that'll not happen again.
I have a few other things lined up for
Hi folks,
during the changes from 3.12rc7 to 3.13rc4, the performance of
XDrawRectangles() dropped considerably. Interestingly, it is not the raw
rectangles drawing operations that are slow, but it seems that the
per-call overhead has increased by one magnitude. In specific, if you
use the
On 01/08/2014 06:10 PM, Chris Wilson wrote:
On Wed, Jan 08, 2014 at 04:57:52PM +0100, Thomas Richter wrote:
Hi folks,
during the changes from 3.12rc7 to 3.13rc4, the performance of
XDrawRectangles() dropped considerably. Interestingly, it is not the
raw rectangles drawing operations
Hi Daniel, dear intel-experts,
again I had the chance to test the latest intel-drm-nightly of the
3.14.0 kernel on the Siemens S6010 with its dreadful nso2501 DVO.
Unfortunately, there are still a couple of issues here, and I also want
to report on some progress and some workarounds.
1) Panning
Am 08.04.2014 13:52, schrieb Daniel Vetter:
On Tue, Apr 8, 2014 at 11:48 AM, Thomas Richter
Hm, my X30 also locks up here on resume. What hack do you apply to
make the ns2501 driver get through resume? I don't care about black
screen, but I just wonder whether my X30 has the same issue - atm
Am 08.04.2014 13:37, schrieb Ville Syrjälä:
On Tue, Apr 08, 2014 at 11:48:14AM +0200, Thomas Richter wrote:
I saw the watermark issue on my S6010 too. I have no good explanation
for it since low value in the register means the watermark is actually
high.
I know )-:
So it's a mystery why
On 08.04.2014 18:10, Daniel Vetter wrote:
On Tue, Apr 8, 2014 at 2:05 PM, Thomas Richter
Also, from the linux suspend mechanism, /usr/lib/pm-utils/sleep.d/99video is
just useless or breaks more than it helps. I just removed it. It tries some
weird workarounds that are not beneficial
Dear intel-gfx developers,
panning on i830 based graphics seem to be working only half-ways.
Vertical panning works fine, but horizontal panning flickers at about
60Hz frequency at specific pixel positions. The problem persists
throughout kernel 3.10.9, and potentially later.
How to
Dear intel-gfx developers,
when booting up the 3.10.9 kernel on a Fujitsu-Siemens S4575, I get the
following warnings from the linux kernel (see below). The hardware is a
00:02.0 VGA compatible controller: Intel Corporation 82830M/MG
Integrated Graphics Controller (rev 04)
with the
Dear intel-gfx developers,
suspend from standby is broken on the Fujitsu-Siemens Lifebook S2474, at
least from kernel 3.4 up to 3.10.9. The hardware is a 00:02.0 VGA
compatible controller: Intel Corporation 82830M/MG Integrated Graphics
Controller (rev 04), i.e. a 830GM. The machine suspends
Dear intel-gfx developers,
When panning is enabled on the 830GM, horizontal panning creates a lot
of flickering on specific pixel positions.
After testing, I found that the reason for this is that panning works by
altering the frame origin pointer, which,
however, has certain alignment
Hi Daniel,
I've just looked at the docs and they only mention that the base address
must be pixel aligned. But it could very well be that the watermarks are a
bit off for your chipset. The below quick hack should test this theory.
-Daniel
diff --git a/drivers/gpu/drm/i915/intel_pm.c
On 02.09.2013 16:18, Daniel Vetter wrote:
Checked with the above modifications. Unfortunately, the result is
negative. With the above modifications and my changes commented out,
the screen flickers in normal state (without panning) but in a
different way: With the above enabled, you get a
Am 02.09.2013 16:18, schrieb Daniel Vetter:
Hm, I've probably botched the watermarks again. Can you please retest with
the below diff?
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index dfdc7ad..b667ff0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++
Hi folks,
Can you please test with
Option LinearFramebuffer true?
Thanks, Daniel
Tested again. Yes, indeed, LinearFramebuffer does make a difference.
Without it, panning to the right causes flicker, with it, moving the
mouse to the right - panning right (thus scrolling the screen
Hi Daniel, hi folks,
just playing again with the support code for the NS2501 DVO in my old
laptop. Despite finding one bug I'll send a patch
for soon, there is something else that makes we wonder, and that is the
connection to external monitors.
Just to remind you, the NS2501 in this
Hi Ville, hi Daniel,
Thus, here my questions:
*) Can I, within the dvo driver code, somehow detect to which display
pipe the DVO and thus the TFT is actually connected
to?
Something like this:
intel_dvo = container_of(dvo, struct intel_dvo, dev);
pipe =
Hi Daniel, hi folks,
after another evening of debugging, I believe I know now how to prevent
the ns2501 DVO from locking up. It rather seems that this is due to a
bug in the intel_display module, in specific in the pll update function.
That is, edit intel_display.c, function
Hi Daniel,
btw I've just read through your dvo code again and I think we can fix this
easier. If I read your enable hack correctly then we need to have the dpll
running and the DVO port on. The problem now is that in the dvo -modeset
callback this is explicitly _not_ the case.
Please also
On 06.10.2013 01:37, Daniel Vetter wrote:
On Sun, Oct 6, 2013 at 1:09 AM, Thomas Richtert...@math.tu-berlin.de wrote:
Now if you follow the callchains around the dvo-dpms callbacks the DVO
port and DPLL are always enabled at that point in time, so I think we
should be able to fix this all by
On 08.10.2013 10:39, Daniel Vetter wrote:
On Tue, Oct 8, 2013 at 9:24 AM, Daniel Vetterdan...@ffwll.ch wrote:
I guess step one is to bisect the regression in 3.11. Fixing things on
top of 3.10 is imo pointless if later kernels break things harder ...
btw the two SNA patches I've just
Hi Daniel, dear kernel developers,
just tried the 3.12.rc3+ from the intel-drm git. This version *worked*
again, pretty much the same way the 3.10.10 worked.
Side effects are, however, quite the same when you connect an external
monitor:
If connected while the gdm login screen is on, the
On 09.10.2013 00:00, Daniel Vetter wrote:
My drm-intel git branch doesn't yet have the two patches that are meant to
replace your ns2501 hack ... So I'm not too sure what exactly you've
tested that made things magically better?
Is there a difference between the 3.12rc4 from kernel.org and the
Hi Daniel,
finally had access again to the Fujitsu laptop with the 835GM chipset.
This time, I checked up the nightly-built branch based on the 3.12.rc4
kernel. Similar to the 3.11 kernel, I get a blank screen during login,
i.e. gdm does not render its graphics. The boot console, even after
Daniel, others,
last Friday, I tried drm-intel-nightly on an IBM R31 Thinkpad. This also
comes with a 835GM chipset (same as the Fujitsu), but the
display is connected via LVDS and not via the NS2501 DVO.
*) Panning also causes the flicker we know already. Interestingly,
kernel 3.2.0-4 *does
Am 22.10.2013 14:03, schrieb Chris Wilson:
Ah, /var/log/Xorg.0.log has greater verbosity than stdout/stderr. I am
just curious where we reject the -intel driver and hence fail to init
the screen.
/var/logXorg.0.log is zero bytes long at this point. I wouldn't call
this greater. (-;
Let it be
Hi Daniel, dear intel experts,
again trying to get the old Fujitsu laptop to work. The problem with the
latest drm-nightly built is that
the system again locks up - if the bios is configured to show an image
only on the internal display and
nothing on the external VGA. If the bios is
On 03.11.2013 18:13, Daniel Vetter wrote:
Have you tried my patch to reorder the dvo sequence a bit? That /should/
get all these things right:
http://www.spinics.net/lists/intel-gfx/msg34349.html
There's also a follow-up patch for you to test:
On 03.11.2013 18:13, Daniel Vetter wrote:
Have you tried my patch to reorder the dvo sequence a bit? That /should/
get all these things right:
http://www.spinics.net/lists/intel-gfx/msg34349.html
There's also a follow-up patch for you to test:
On 03.11.2013 22:18, Daniel Vetter wrote:
Hm, that would mean that the cursor is somehow stuck in the enabled state,
despite that we've tried to disabled it very hard. Can you please try out
the below patch? If this doesn't work please take not of the different
WARNINGs you're hitting and
Hi Daniel, dear intel experts,
just another note: I just switched the default depth from 24 to 16 bit
by adding a DefaultDepth into
the screen section of X11. Strangely enough, that gives much *less*
banding than the 24bpp output
Anyhow, 16bpp breaks the gdm login, and 8bpp breaks almost
Hi Daniel,
I also tried a lot with the two-monitor case and again went deeply into the
DPLL setup logic.
The differences I observed before are simply due to the initial resolution
(800x600), in the final
resolution, the DPLL settings are actually correct. What I get there is:
I suspect that due
Hi Daniel, dear intel experts,
the following is a solution for the flicker on i830 panning. To remind
you, when panning is enabled on an i830,
the display shows an annoying 30Hz flicker on some forbidden
positions. On such positions, half of the frames
is black, and the other half shows a
On 06.11.2013 11:34, Daniel Vetter wrote:
}
To clarify: Do you need this patch to make the single-pipe mode work
reliably? It's a bit unclear in your answer ...
Well, from what I can tell, I haven't seen the above warning since, but
it was neither easily reproducable. Working reliable is
Hi Daniel, dear intel-experts,
please find a revised patch attached that addresses the flicker with
panning on the i830 chipset. This patch has now been tested
on various screen layouts and seems to be quite reliable, i.e. I haven't
seen the flicker since.
Unfortunately, I have not been able
Am 11.11.2013 16:43, schrieb Daniel Vetter:
Oh, that's really interesting. gen2 has a unified display fifo on
machines that support 2 outputs. DSPARB tells the hw how to exactly
split this up between the two pipes. There are two bit ranges of
interest here:
/* snip */
Hmm, why I understand
On 12.11.2013 18:22, Daniel Vetter wrote:
Thanks for the explanation how the fifos work, that was helpful.
Yeah, I've meant BEND = max and AEND split so that the two resulting sizes
are proportional to the pixel clock (i.e. both pipes should take equal
amount of time roughly to go through the
On 13.11.2013 21:20, Daniel Vetter wrote:
Thanks Daniel for your explanations. As always, very helpful.
Tile buffers aren't linear any more in memory. Tiles are 2kb in size and
are laid out in x-major direction. The tile itself is 128 bytes wide and
16 lines high. So presuming you start
, but I'll keep looking.
At least this is something.
So long,
Thomas
From ba72c1e506bb162f8ac595af94cc6ed850439883 Mon Sep 17 00:00:00 2001
From: Thomas Richter t...@math.tu-berlin.de
Date: Thu, 14 Nov 2013 18:16:14 +0100
Subject: [PATCH 11/11] Added a workaround for pipe-A underruns on i830
1 - 100 of 144 matches
Mail list logo
