[Intel-gfx] [PATCH 1/2] drm/i915: allow userspace forcewake references also on gen7
We need this to correctly access registers in the gt power well from userspace. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_debugfs.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 6c3be86..4a93dfc 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -1666,7 +1666,7 @@ static int i915_forcewake_open(struct inode *inode, struct file *file) struct drm_i915_private *dev_priv = dev-dev_private; int ret; - if (!IS_GEN6(dev)) + if (INTEL_INFO(dev)-gen 6) return 0; ret = mutex_lock_interruptible(dev-struct_mutex); @@ -1683,7 +1683,7 @@ int i915_forcewake_release(struct inode *inode, struct file *file) struct drm_device *dev = inode-i_private; struct drm_i915_private *dev_priv = dev-dev_private; - if (!IS_GEN6(dev)) + if (INTEL_INFO(dev)-gen 6) return 0; /* -- 1.7.8.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: debugfs: show semaphore registers also on gen7
Corresponding changes to improve our error_state are pending
some other patches to clean up things first.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 4a93dfc..a480935 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -654,7 +654,7 @@ static int i915_ringbuffer_info(struct seq_file *m, void
*data)
seq_printf(m, Size :%08x\n, ring-size);
seq_printf(m, Active : %08x\n, intel_ring_get_active_head(ring));
seq_printf(m, NOPID : %08x\n, I915_READ_NOPID(ring));
- if (IS_GEN6(dev)) {
+ if (IS_GEN6(dev) || IS_GEN7(dev)) {
seq_printf(m, Sync 0 : %08x\n, I915_READ_SYNC_0(ring));
seq_printf(m, Sync 1 : %08x\n, I915_READ_SYNC_1(ring));
}
--
1.7.8.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: paper over missed irq issues with force wake voodoo
Dear Daniel, Am Freitag, den 14.12.2012, 16:01 +0100 schrieb Daniel Vetter: the (author) date is wrong (December instead of January) unless you sent it from the future. If you did, please tell us how the Intel driver will work in eleven months. ;-) […] Thanks, Paul signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: allow userspace forcewake references also on gen7
On Tue, 24 Jan 2012 09:44:28 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: We need this to correctly access registers in the gt power well from userspace. How about a INTEL_INFO(dev)-has_forcewake or check for the -forcewake_get? That would be more self-documenting, and we are less likely to miss one in the future, than adding more random generation checks. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: allow userspace forcewake references also on gen7
On Tue, Jan 24, 2012 at 10:35:04AM +, Chris Wilson wrote: On Tue, 24 Jan 2012 09:44:28 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: We need this to correctly access registers in the gt power well from userspace. How about a INTEL_INFO(dev)-has_forcewake or check for the -forcewake_get? That would be more self-documenting, and we are less likely to miss one in the future, than adding more random generation checks. I'll jot down a todo to create a cleanup patch for -next that introduce some feature flags like has_forcewake has_rc6 and such to avoid such gaffles (hopefully). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: allow userspace forcewake references also on gen7
On Tue, Jan 24, 2012 at 06:44, Daniel Vetter daniel.vet...@ffwll.ch wrote: We need this to correctly access registers in the gt power well from userspace. Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: allow userspace forcewake references also on gen7
On Tue, Jan 24, 2012 at 09:04, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jan 24, 2012 at 10:35:04AM +, Chris Wilson wrote: On Tue, 24 Jan 2012 09:44:28 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: We need this to correctly access registers in the gt power well from userspace. How about a INTEL_INFO(dev)-has_forcewake or check for the -forcewake_get? That would be more self-documenting, and we are less likely to miss one in the future, than adding more random generation checks. I'll jot down a todo to create a cleanup patch for -next that introduce some feature flags like has_forcewake has_rc6 and such to avoid such gaffles (hopefully). I actually wrote about the very same idea in my previous email :). So +1 to that! -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] RGB Problem with Intel i915 driver, i3 2010T, RGB color output over HDMI
Hello all, This e-mail is a continuation of my previews one regarding HDMI modeline output problems. So far with the help of Rodrigo Vivi i have manage to output the 1920x1080p@60hz mode over HDMI to my AV receiver. (To fix my previews problem i inserted the EDID frame directly inside drm_edid.c file. So i dont read EDID from the AV i2c bus anymore. So the mode is always set correctly.) The issue now is that the AV reports that the signal is not in RGB mode and the image shows some strange colors, specially on the white color (showing like greens). Does any one has any idea if this is a problem on the EDID or inside drm/i915? All comments and help are very appreciated.-- Paulo Louro ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fixup assert_pipe to take the pipe A quirk into account
On Mon, 23 Jan 2012 20:40:27 +0100 Daniel Vetter dan...@ffwll.ch wrote: On Sat, Jan 21, 2012 at 08:36:38PM -0800, Keith Packard wrote: On Sun, 22 Jan 2012 01:36:48 +0100, Daniel Vetter daniel.vet...@ffwll.ch wrote: This was completely spamming dmesg on my i855gm. This comes from intel_disable_pll, which wants to turn the pll off, but if the pipe is still active, it won't be able to. This seems bad to me. I honestly can't reconcile your comment with the codepatch. Afaics - the pll disable code checks for the pipe a quirk and does an early exit before mucking around with the hw and calling assert_pipe. - assert_pipe only does a WARN and the patch only changes whether we hit that WARN. All reg reads/writes should be unchanged. - the backtrace I'm seeing goes through crtc_disable. Ah ok so it's coming from the new pipe disabled check Chris added. Patch looks fine... and reminds me to be puzzled about the pipe a force quirk on 855. :) -- Jesse Barnes, Intel Open Source Technology Center signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Correct debugfs printout for RC1e.
On Mon, 23 Jan 2012 16:14:05 -0800, Eric Anholt e...@anholt.net wrote: We had two things in a row claiming to be RC6. I've applied this to drm-intel-fixes -- keith.pack...@intel.com pgp6ExioN2yBO.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Re-enable gen7 RC6 and GPU turbo after resume.
On Mon, 23 Jan 2012 16:14:06 -0800, Eric Anholt e...@anholt.net wrote: Signed-off-by: Eric Anholt e...@anholt.net Cc: sta...@vger.kernel.org I've applied this to drm-intel-fixes -- keith.pack...@intel.com pgpLcUStmh3FO.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PROBLEM FOUND] Problem No HDMI when AV/TV in standby mode
Very ugly hack, In file --- intel_display.c function --- ironlake_crtc_mode_set temp = I915_READ(_TRANSACONF); I915_WRITE(_TRANSACONF, temp ~(721)); I915_WRITE( 0x60028, 0x); //VSYNCSHIFT_A— Vertical Sync Shift Register This register needs to be 0x for progressive mode I915_WRITE(PIPECONF(pipe), pipeconf); POSTING_READ(PIPECONF(pipe)); In file --- i915_reg.h #define PIPECONF_INTERLACE_W_FIELD_INDICATION(7 21) // ( 6 21) Not sure why the PIPECONF MASK is 110 and not 111, from intel pdf 000b Progressive Fetch / Progressive display / 001b PF-ID Progressive Fetch / Interlaced display (HDMI) Requires panel fitting to be enabled Next will be to solve the RGB problem i have. From: paulo_lo...@msn.com To: intel-gfx@lists.freedesktop.org Date: Tue, 24 Jan 2012 20:38:57 + Subject: Re: [Intel-gfx] [PROBLEM FOUND] Problem No HDMI when AV/TV in standby mode Hello all, I think i have found why there is a problem with my Onkyo AV when the TV/AV are in standby mode. I run the following test. Boot PC with AV/TV in standby and dump intel registers to a file TEST1Boot PC with AV/TV on and dump intel register to file TEST2Using the diff to find the difference between both files i found the following: root@SERVER:~# diff test1 test214c14 PIPEACONF: 0xc020 (enabled, active, 8bpc)--- PIPEACONF: 0xc000 (enabled, active, 8bpc)21c21 VSYNCSHIFT_A: 0x038c--- VSYNCSHIFT_A: 0x125c125 TRANSACONF: 0xc060 (enable, active)--- TRANSACONF: 0xc000 (enable, active) So register PIPEACONF, VSYNCSHIFT_A and TRANSACONF are different. By checking intel documentation i found that this registers are responsibly for setting up the progressive/interleave mode. As so im thinking that this registers are not being reinitialize or cleaned. Is this possible? Since im up for one more test i used intel_reg_read/write to modified the registers and correct the values, to my surprise after writing to all the register the AV shows my desktop correctly. My other question is if they need to be reinitialized where in the code shall this be done? I'm up for writing a small patch to fix this issue, just need some one to point me on the right direction. Thanks--Paulo Louro ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PROBLEM FOUND] Problem No HDMI when AV/TV in standby mode
On Tue, Jan 24, 2012 at 10:03:57PM +, paulo louro wrote: Very ugly hack, In file --- intel_display.c function --- ironlake_crtc_mode_set temp = I915_READ(_TRANSACONF); I915_WRITE(_TRANSACONF, temp ~(721)); I915_WRITE( 0x60028, 0x); //VSYNCSHIFT_A— Vertical Sync Shift Register This register needs to be 0x for progressive mode I915_WRITE(PIPECONF(pipe), pipeconf); POSTING_READ(PIPECONF(pipe)); In file --- i915_reg.h #define PIPECONF_INTERLACE_W_FIELD_INDICATION (7 21) // ( 6 21) Not sure why the PIPECONF MASK is 110 and not 111, from intel pdf 000b Progressive Fetch / Progressive display / 001b PF-ID Progressive Fetch / Interlaced display (HDMI) Requires panel fitting to be enabled Wohoo, this is awesome. Can you maybe go right ahead and create a patch for this? Should be nothing more than checking for an interlaced mode and banging the right values into these registers ... Yours, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: argument for deferring retirement
Sometimes it may be the case when we idle the gpu or wait on something
we don't actually want to process the retiring list. This patch allows
callers to choose the behavior.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c|2 +-
drivers/gpu/drm/i915/i915_drv.h|8 +---
drivers/gpu/drm/i915/i915_gem.c| 21 +++--
drivers/gpu/drm/i915/i915_gem_evict.c |2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c|2 +-
6 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8122738..1efc953 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2131,7 +2131,7 @@ int i915_driver_unload(struct drm_device *dev)
unregister_shrinker(dev_priv-mm.inactive_shrinker);
mutex_lock(dev-struct_mutex);
- ret = i915_gpu_idle(dev);
+ ret = i915_gpu_idle(dev, false);
if (ret)
DRM_ERROR(failed to idle hardware: %d\n, ret);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f02a5f5..4fbe117 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1179,13 +1179,15 @@ void i915_gem_do_init(struct drm_device *dev,
unsigned long start,
unsigned long mappable_end,
unsigned long end);
-int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gpu_idle(struct drm_device *dev, bool defer_retirement);
int __must_check i915_gem_idle(struct drm_device *dev);
int __must_check i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
struct drm_i915_gem_request *request);
-int __must_check i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno);
+int __must_check i915_gem_wait_request(struct intel_ring_buffer *ring,
+ uint32_t seqno,
+ bool defer_retirement);
+#define i915_wait_request(ring, seqno) i915_gem_wait_request(ring, seqno,
false)
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int __must_check
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eb98a7f..ad16de9 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1942,8 +1942,9 @@ i915_gem_retire_work_handler(struct work_struct *work)
* request and object lists appropriately for that event.
*/
int
-i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno)
+i915_gem_wait_request(struct intel_ring_buffer *ring,
+ uint32_t seqno,
+ bool defer_retirement)
{
drm_i915_private_t *dev_priv = ring-dev-dev_private;
u32 ier;
@@ -2027,7 +2028,7 @@ i915_wait_request(struct intel_ring_buffer *ring,
* buffer to have made it to the inactive list, and we would need
* a separate wait queue to handle that.
*/
- if (ret == 0)
+ if (ret == 0 !defer_retirement)
i915_gem_retire_requests_ring(ring);
return ret;
@@ -2172,7 +2173,7 @@ i915_gem_flush_ring(struct intel_ring_buffer *ring,
return 0;
}
-static int i915_ring_idle(struct intel_ring_buffer *ring)
+static int i915_ring_idle(struct intel_ring_buffer *ring, bool
defer_retirement)
{
int ret;
@@ -2186,18 +2187,18 @@ static int i915_ring_idle(struct intel_ring_buffer
*ring)
return ret;
}
- return i915_wait_request(ring, i915_gem_next_request_seqno(ring));
+ return i915_gem_wait_request(ring, i915_gem_next_request_seqno(ring),
+defer_retirement);
}
-int
-i915_gpu_idle(struct drm_device *dev)
+int i915_gpu_idle(struct drm_device *dev, bool defer_retirement)
{
drm_i915_private_t *dev_priv = dev-dev_private;
int ret, i;
/* Flush everything onto the inactive list. */
for (i = 0; i I915_NUM_RINGS; i++) {
- ret = i915_ring_idle(dev_priv-ring[i]);
+ ret = i915_ring_idle(dev_priv-ring[i], defer_retirement);
if (ret)
return ret;
}
@@ -3710,7 +3711,7 @@ i915_gem_idle(struct drm_device *dev)
return 0;
}
- ret = i915_gpu_idle(dev);
+ ret = i915_gpu_idle(dev, false);
if (ret) {
mutex_unlock(dev-struct_mutex);
return ret;
@@ -4201,7 +4202,7 @@ rescan:
* This has a dramatic impact to reduce the number of
* OOM-killer events whilst running
[Intel-gfx] [PATCH 2/2] drm/i915: drm/i915: Fix recursive calls to unmap
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris Wilson tracked down the issue to recursive
calls to unmap. This happens because we try to optimize waiting on
requests by calling retire requests after the wait, which may drop the
last reference on an object and end up freeing the object (and then
unmap the object from the gtt).
After the last patch we can now choose to defer processing the retire
list.
Kudos to Chris Wilson for tracking this one down.
This fixes tests/gem_linear_blits in intel-gpu-tools.
v2: v1 used a global, v2 directly modified the call chain.
v3: As Keith Packard pointed out, v2 changed retirement behavior. While
it was intentional, it wasn't related to the bugfix, and so has been
removed. To do this, changed i915_wait_request to be a macro to assure
old behavior is kept.
v4: Rebased and renamed strictly_idle to defer_retirement.
V5: Don't use a macro port new code, just change all the callers.
Also had a badly named argument in the function definition.
This patch fixes gem_unref_active_buffers from i-g-t in the non-VTd
case (ie. do_idle_maps forced to true).
Reported-by: guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 11bddd5..e050b90 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -55,7 +55,7 @@ static bool do_idling(struct drm_i915_private *dev_priv)
if (unlikely(dev_priv-mm.gtt-do_idle_maps)) {
dev_priv-mm.interruptible = false;
- if (i915_gpu_idle(dev_priv-dev, false)) {
+ if (i915_gpu_idle(dev_priv-dev, true)) {
DRM_ERROR(Couldn't idle GPU\n);
/* Wait a bit, in hopes it avoids the hang */
udelay(10);
--
1.7.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: argument for deferring retirement
On Tue, 24 Jan 2012 14:42:02 -0800, Ben Widawsky b...@bwidawsk.net wrote: Sometimes it may be the case when we idle the gpu or wait on something we don't actually want to process the retiring list. This patch allows callers to choose the behavior. bikeshed !defer_retirement sounds like a double-negative to me, might be better to have the parameter called 'do_retire' and change usage to match? /bikeshed In any case, this looks easy to understand to me. Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgp1vnLeujYEI.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: drm/i915: Fix recursive calls to unmap
On Tue, 24 Jan 2012 14:42:03 -0800, Ben Widawsky b...@bwidawsk.net wrote: This patch fixes gem_unref_active_buffers from i-g-t in the non-VTd case (ie. do_idle_maps forced to true). Nice, one-line fix. (if you agree with my bikeshed in the previous patch, this will have to be changed to match) Reviewed-by: Keith Packard kei...@keithp.com -- keith.pack...@intel.com pgptOnCwrurzz.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: argument for deferring retirement
On Tue, Jan 24, 2012 at 20:42, Ben Widawsky b...@bwidawsk.net wrote: Sometimes it may be the case when we idle the gpu or wait on something we don't actually want to process the retiring list. This patch allows callers to choose the behavior. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com (I agree with Keith comments though - defer retirement could be renamed to do_retire or force_retire or similar..). -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Sun, Jan 22, 2012 at 11:40 AM, Daniel Vetter dan...@ffwll.ch wrote: Actually I only need the output of intel_reg_dumper, resolution doesn't really matter that much. It just needs to be a HDMI-only configuration that works. Hi Daniel, here are the tests: TEST-11 Only HDMI connected. TV set on HDMI input. Reboot. The login screen uses the wrong resolution and it's in the wrong position as usual. I connected over VNC to login. Strangely now there is no split screen anymore (I checked and I'm using 3.2.0-drm-intel-fixes+) the screen is black and the resolution is 1024x768 (I can see from VNC) xrandr --output HDMI2 --mode 1024x768 --rate 60.0 (as expected no change since it's the actual res) xrandr --output HDMI2 --mode 1280x720 --rate 60.0 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 1280x720 --rate 50.0 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 800x600 --rate 60.3 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 800x600 --rate 60.3 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 720x480 --rate 59.9 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 640x480 --rate 59.9 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 640x480 --rate 60.0 (the TV does something, but then goes back to black resolution is correct from VNC) I didn't save any dump cause you requested one where HDMI was working and it never did. Any idea? My question is: why I don't even see the split screen anymore and just the black screen? So, just to test, I run with 3.0.0-15-generic-pae and indeed I can see the split screen again. Also, the login screen is 1024x768 (split) rather than 1280x720 (when I run 3.2.0-drm-intel-fixes+) In 3.0.0-15-generic-pae, I can see the split screen but xrandr -q reports way less combinations (1024x768@60.0, 800x600@60.3, 640x480@60). I tried all three and they all work in split screen w/o flickering. The TV goes never black. It just needs to be a HDMI-only configuration that works. So if I understand your request correctly, I don't have such situation with only HDMI. AGAIN, as soon as I connect the VGA cable the TV is not in split screen anymore and I can see just fine. But you already have this test from the previous time so I won't take any log. Test with the i915 driver (i.e. no nomodeset on the kernel cmdline), if you want you can try both VGA cable only and VGA/HDMI but it shouldn't matter. xrandr -q output shows only 55.4 and 60.0 for this resolution, so I think it doesn't make sense to test anything else. TEST-12 VGA and HDMI connected. TV set on VGA input. Reboot. The login screen is black. I connected over VNC to login (login screen is 1024x768) xrandr --output VGA1 --mode 1024x768 --rate 54.4 (nothing changes, as expected) xrandr --output VGA1 --mode 1024x768 --rate 60.0 bingo. I can see the screen with quite a bit of overscan top and bottom (exactly as I usually saw it over VGA from XP) I also tried the same test with only VGA cable connected and it works the same way. xrandr --output VGA1 --mode 800x600 --rate 60.3 also works like in windows, with overscan. I attached logs from 1024x768. So, to conclude, I think we achieved feature parity over VGA. It's just a matter of choosing the right refresh rate... Do you have any idea about the next step for HDMI? thank you, alfonso ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
Hi Angela, did you try with the latest patches from Peter? Peter: any idea for a next step since Angela still experienced the bug? Thank you, alfonso On Sat, Jan 21, 2012 at 11:25 AM, Angela Schmid angela.sch...@wolke7.net wrote: Hello I tested with the patches applied. Xrandr shows the available interlaced modes automatically. xrandr --output VGA1 --off xrandr --output HDMI3 --mode 1920x1080 --rate 25 The television flickers. The lower part of the desktop is visible (lower menu with wastebin) in the upper left quadrant. I start with VGA1 connected too, so that grub is shown in 1024x768 mode. During boot both flicker, which they didn't before. Both show a desktop in 1024x768 correct. Changing HDMI3 to 1920x1080, the VGA1 stays in the 1024x768 mode, both flicker. With the noveau driver (GTX275) I hadn't any side-effects. I personally don't need a VGA1 connection, so I disconnected it for my test, see attached logs. If screenshots are welcome, please tell me how. Yi already mentioned that SandyBridge still has a problem, which I can confirm for my GT2+. Any patches for testing are welcome. Angela Settings used: wget http://paste.debian.net/download/152705 wget http://paste.debian.net/download/152707 wget http://paste.debian.net/download/152708 $ git am 152705 152707 152708 Applying: drm/i915: specify vertical timings in frame units for interlaced modes (gen3+) Applying: drm/i915: allow interlaced mode output on the SDVO connector Applying: drm/i915: allow interlaced mode output on the HDMI connector -Original Message- From: Angela Schmid [mailto:angela.sch...@wolke7.net] Sent: 20 January 2012 19:07 To: 'Alfonso Fiore'; 'Peter Ross' Cc: 'Daniel Vetter'; 'Rodrigo Vivi' Subject: RE: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working Hello From my first mail: I have a Philips 37pf9830 television (at 1920x1080 only interlace possible) over Sandy Bridge HDMI. Changing to 1920x1080i is not working. Nvidia noveau with GTX275 (using yellow DVI-HDMI Adapter) , grub2 (vesa?), Windows 7 over HDMI and a Windows 7 laptop with AMD graphics with HDMI all work fine. I tried several other modelines, which work for the noveau driver, but not for the intel driver. The highest resolution possible is 1280x720@50hz 74.25 1280 1720 1760 1980 720 725 730 750 +hsync +vsync When using only HDMI grub2 will start in 1080i but xorg is not visible afterwards. For booting I have to add a DVI display to start grub2 in a lower resolution. Either disconnect as soon as possible or I use xrandr -output VGA1 -off Addition: I hadn't time to test the fixes. I will have a look next week. Angela -Original Message- From: Alfonso Fiore [mailto:alfonso.fi...@gmail.com] Sent: 20 January 2012 13:53 To: Peter Ross Cc: Daniel Vetter; Rodrigo Vivi; Angela Schmid Subject: Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working Angela, please have a look and comment below. thanks, alfonso On Fri, Jan 20, 2012 at 1:40 PM, Peter Ross pr...@xvid.org wrote: What concerns me is that some other folk have reported working interlaced output on the Sandy Bridge chipset. So I'm left thinking your TV device may be very fussy about the signal timings, hence why you get a blue 'no signal' screen. PATCH-v2 has a problem, where the vertical timings are off by two lines (giving 1920x1078i, instead of 1080i). Your TV may reject this mode, The enclosed patch corrects this problem. It should be applied on-top of the PATCHv2 set. Rebuild your kernel and try changing to an interlaced mode using xrandr. Otherwise, we have kind of exhausted all the readily available options here. The next step would be to reverse engineer the Intel windows driver, since you reported it to output 1080i to your TV. Peter, my apologies if I mislead you. I've never seen any 1080i resolution on my TV. Maybe Angela did? I only saw a working 1024x768 resolution (which is now achieved constantly with the hack of connecting both VGA and HDMI cable to the same TV). Can you please tell me which commands to apply the patch of the patch? thank you, alfonso ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fedora 16, kernel 3.2.0+, i5 2500K, Z68 system freeze
Hi All, I've been hunting around for information on how to help debug the issue I'm having - Hopefully someone here can help My setup is: - ASRock Z68 Pro3 Gen3 motherboard - i5 2500K CPU - Fedora 16 - Vanilla 3.2.0+ kernel (commt ccb19d263fd1c9e34948e2158c53eacbff369344) I'm experiencing frequence total system freezes (not even reset button works). I originally thought it was a power management problem because the freezes only seemed to occur after leaving the system idle for a while, but recently the freezing seems to be happening even when the machine is in full use. I have not seen many other reports involving the Z68/HD3000 combination yet. I have submitted a bug report on the kernel bugzilla tracker: https://bugzilla.kernel.org/show_bug.cgi?id=42597 This has /var/messages and Xorg logs, but neither show anything particularly interesting (no oops for example) I've tried netconsole, but no additional messages are appearing there either. I've also tried i915.semaphores=1 to no avail So I'm open to all and sundry suggestions. I'm willing to build and run developmental / experimental code, apply patches etc to help identify the problem / test potential solutions. Regards, Graeme ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.
On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote: Older specs claimed this was bit 11, but newer specs and the actual simulator code say it was bit 12. Regardless, we don't use MI_FLUSH, or try to enable it any more. Signed-off-by: Eric Anholt e...@anholt.net I'd like to amend this with the following (on this patch instead of the other, so that ppl actually can find it with git blame): Furthermore actually setting bit12 results in gpu hangs both on snb and ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11 must be set, but that doesn't help either. And last but not least, MI_FLUSH seems to work regardless of the setting of these bits. I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk (since it doesn't exist there). On my snb, running xvideo so that MI_FLUSHes are generated by the userland (I think -- I haven't caught them in cat i915_batchbuffers | intel_dump_decode -), with intel_reg_read 0x209c saying 0x1240, things are going fine. Also with 0x209c saying 0x240 (the result of this patch). That 2008 PPT mentioned also said the bit and bit 12, and only in one cut-and-paste of a command line did I see it say two bits should be set. I would trust the actual code more than a ppt. But basically, whatever we do to make this broken code go away, I'm fine with. pgpRDclBJAiUF.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: drm/i915: Fix recursive calls to unmap
On 01/24/12 15:00, Keith Packard wrote: On Tue, 24 Jan 2012 14:42:03 -0800, Ben Widawskyb...@bwidawsk.net wrote: This patch fixes gem_unref_active_buffers from i-g-t in the non-VTd case (ie. do_idle_maps forced to true). Nice, one-line fix. (if you agree with mybikeshed in the previous patch, this will have to be changed to match) Reviewed-by: Keith Packardkei...@keithp.com I agree with the bikeshed, however I am not sure what you expect changed here. do_idle_maps is still forced to true to test the fix. So I'm going to assume you just read the comment too quickly and resubmit with the updated patches. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Correct the bit number for the MI_FLUSH_ENABLE.
On 01/24/12 18:55, Eric Anholt wrote: On Sat, 21 Jan 2012 17:36:13 +0100, Daniel Vetterdan...@ffwll.ch wrote: On Thu, Jan 19, 2012 at 10:50:06AM -0800, Eric Anholt wrote: Older specs claimed this was bit 11, but newer specs and the actual simulator code say it was bit 12. Regardless, we don't use MI_FLUSH, or try to enable it any more. Signed-off-by: Eric Anholte...@anholt.net I'd like to amend this with the following (on this patch instead of the other, so that ppl actually can find it with git blame): Furthermore actually setting bit12 results in gpu hangs both on snb and ivb. Ben Widawsky discovered a ppt that claims that both bit12 and bit11 must be set, but that doesn't help either. And last but not least, MI_FLUSH seems to work regardless of the setting of these bits. I haven't seen bit12 hanging snb/ivb -- I only knew of it hanging ilk (since it doesn't exist there). On my snb, running xvideo so that MI_FLUSHes are generated by the userland (I think -- I haven't caught them in cat i915_batchbuffers | intel_dump_decode -), with intel_reg_read 0x209c saying 0x1240, things are going fine. Also with 0x209c saying 0x240 (the result of this patch). Daniel has a failing test on IVB. I haven't tried hard enough to make it fail on SNB, so I cannot speak to that. That 2008 PPT mentioned also said the bit and bit 12, and only in one cut-and-paste of a command line did I see it say two bits should be set. I would trust the actual code more than a ppt. But basically, whatever we do to make this broken code go away, I'm fine with. I'm in the same boat. I think trying to figure out which source to trust is a losing game for all, and our best bet is to find out what the Windows driver does, and presumably that cut-and-paste is not from the Windows driver. Ben ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] infinite revusion patches v9999
I decided to remove the history of the patches since I expect this version to go upstream. The cover-letter serves to remind us all that this is the final version of the patches, without the clutter in the commit messages. Ben Widawsky (2): drm/i915: argument to control retiring behavior drm/i915: drm/i915: Fix recursive calls to unmap drivers/gpu/drm/i915/i915_dma.c|2 +- drivers/gpu/drm/i915/i915_drv.h|5 ++- drivers/gpu/drm/i915/i915_gem.c| 30 +++ drivers/gpu/drm/i915/i915_gem_evict.c |2 +- drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +- drivers/gpu/drm/i915/i915_gem_gtt.c|2 +- drivers/gpu/drm/i915/intel_overlay.c |6 +++- 7 files changed, 28 insertions(+), 21 deletions(-) -- 1.7.8.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: argument to control retiring behavior
Sometimes it may be the case when we idle the gpu or wait on something
we don't actually want to process the retiring list. This patch allows
callers to choose the behavior.
Reviewed-by: Keith Packard kei...@keithp.com
Reviewed-by: Eugeni Dodonov eugeni.dodo...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c|2 +-
drivers/gpu/drm/i915/i915_drv.h|5 ++-
drivers/gpu/drm/i915/i915_gem.c| 30 +++
drivers/gpu/drm/i915/i915_gem_evict.c |2 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c|2 +-
drivers/gpu/drm/i915/intel_overlay.c |6 +++-
7 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8122738..3f27173 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2131,7 +2131,7 @@ int i915_driver_unload(struct drm_device *dev)
unregister_shrinker(dev_priv-mm.inactive_shrinker);
mutex_lock(dev-struct_mutex);
- ret = i915_gpu_idle(dev);
+ ret = i915_gpu_idle(dev, true);
if (ret)
DRM_ERROR(failed to idle hardware: %d\n, ret);
mutex_unlock(dev-struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f02a5f5..1d10b8c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1179,13 +1179,14 @@ void i915_gem_do_init(struct drm_device *dev,
unsigned long start,
unsigned long mappable_end,
unsigned long end);
-int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gpu_idle(struct drm_device *dev, bool do_retire);
int __must_check i915_gem_idle(struct drm_device *dev);
int __must_check i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
struct drm_i915_gem_request *request);
int __must_check i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno);
+ uint32_t seqno,
+ bool do_retire);
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int __must_check
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index eb98a7f..5b63c56 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1942,8 +1942,9 @@ i915_gem_retire_work_handler(struct work_struct *work)
* request and object lists appropriately for that event.
*/
int
-i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno)
+i915_gem_wait_request(struct intel_ring_buffer *ring,
+ uint32_t seqno,
+ bool do_retire)
{
drm_i915_private_t *dev_priv = ring-dev-dev_private;
u32 ier;
@@ -2027,7 +2028,7 @@ i915_wait_request(struct intel_ring_buffer *ring,
* buffer to have made it to the inactive list, and we would need
* a separate wait queue to handle that.
*/
- if (ret == 0)
+ if (ret == 0 do_retire)
i915_gem_retire_requests_ring(ring);
return ret;
@@ -2051,7 +2052,8 @@ i915_gem_object_wait_rendering(struct drm_i915_gem_object
*obj)
* it.
*/
if (obj-active) {
- ret = i915_wait_request(obj-ring, obj-last_rendering_seqno);
+ ret = i915_wait_request(obj-ring, obj-last_rendering_seqno,
+ true);
if (ret)
return ret;
}
@@ -2172,7 +2174,7 @@ i915_gem_flush_ring(struct intel_ring_buffer *ring,
return 0;
}
-static int i915_ring_idle(struct intel_ring_buffer *ring)
+static int i915_ring_idle(struct intel_ring_buffer *ring, bool do_retire)
{
int ret;
@@ -2186,18 +2188,18 @@ static int i915_ring_idle(struct intel_ring_buffer
*ring)
return ret;
}
- return i915_wait_request(ring, i915_gem_next_request_seqno(ring));
+ return i915_gem_wait_request(ring, i915_gem_next_request_seqno(ring),
+do_retire);
}
-int
-i915_gpu_idle(struct drm_device *dev)
+int i915_gpu_idle(struct drm_device *dev, bool do_retire)
{
drm_i915_private_t *dev_priv = dev-dev_private;
int ret, i;
/* Flush everything onto the inactive list. */
for (i = 0; i I915_NUM_RINGS; i++) {
- ret = i915_ring_idle(dev_priv-ring[i]);
+ ret = i915_ring_idle(dev_priv-ring[i], do_retire);
if (ret)
return ret;
}
@@ -2400,7 +2402,8 @@ i915_gem_object_flush_fence(struct
[Intel-gfx] [PATCH 2/2] drm/i915: drm/i915: Fix recursive calls to unmap
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris Wilson tracked down the issue to recursive
calls to unmap. This happens because we try to optimize waiting on
requests by calling retire requests after the wait, which may drop the
last reference on an object and end up freeing the object (and then
unmap the object from the gtt).
After the last patch we can now choose to defer processing the retire
list.
Kudos to Chris Wilson for tracking this one down.
This patch fixes gem_unref_active_buffers from i-g-t. It was tested by
forcing do_idle_maps to true.
This also fixes tests/gem_linear_blits in intel-gpu-tools.
Reported-by: guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Reviewed-by: Keith Packard kei...@keithp.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_gtt.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e050b90..11bddd5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -55,7 +55,7 @@ static bool do_idling(struct drm_i915_private *dev_priv)
if (unlikely(dev_priv-mm.gtt-do_idle_maps)) {
dev_priv-mm.interruptible = false;
- if (i915_gpu_idle(dev_priv-dev, true)) {
+ if (i915_gpu_idle(dev_priv-dev, false)) {
DRM_ERROR(Couldn't idle GPU\n);
/* Wait a bit, in hopes it avoids the hang */
udelay(10);
--
1.7.8.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] infinite revusion patches v9999
Revusion. Fail. null___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Sandy Bridge Desktop - 1920x1080i interlace not working
On Wed, Jan 25, 2012 at 02:00:37AM +0100, Alfonso Fiore wrote: On Sun, Jan 22, 2012 at 11:40 AM, Daniel Vetter dan...@ffwll.ch wrote: Actually I only need the output of intel_reg_dumper, resolution doesn't really matter that much. It just needs to be a HDMI-only configuration that works. Hi Daniel, here are the tests: TEST-11 Only HDMI connected. TV set on HDMI input. Reboot. The login screen uses the wrong resolution and it's in the wrong position as usual. I connected over VNC to login. Strangely now there is no split screen anymore (I checked and I'm using 3.2.0-drm-intel-fixes+) the screen is black and the resolution is 1024x768 (I can see from VNC) xrandr --output HDMI2 --mode 1024x768 --rate 60.0 (as expected no change since it's the actual res) xrandr --output HDMI2 --mode 1280x720 --rate 60.0 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 1280x720 --rate 50.0 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 800x600 --rate 60.3 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 800x600 --rate 60.3 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 720x480 --rate 59.9 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 640x480 --rate 59.9 (the TV does something, but then goes back to black resolution is correct from VNC) xrandr --output HDMI2 --mode 640x480 --rate 60.0 (the TV does something, but then goes back to black resolution is correct from VNC) I didn't save any dump cause you requested one where HDMI was working and it never did. Any idea? My question is: why I don't even see the split screen anymore and just the black screen? So, just to test, I run with 3.0.0-15-generic-pae and indeed I can see the split screen again. Also, the login screen is 1024x768 (split) rather than 1280x720 (when I run 3.2.0-drm-intel-fixes+) In 3.0.0-15-generic-pae, I can see the split screen but xrandr -q reports way less combinations (1024x768@60.0, 800x600@60.3, 640x480@60). I tried all three and they all work in split screen w/o flickering. The TV goes never black. It just needs to be a HDMI-only configuration that works. So if I understand your request correctly, I don't have such situation with only HDMI. Have you booted with nomodeset and are using the vesa X driver? Iirc you've said that the bios can setup up things correctly, the idea is to grab a register dump to learn how the bios sets things up. AGAIN, as soon as I connect the VGA cable the TV is not in split screen anymore and I can see just fine. But you already have this test from the previous time so I won't take any log. Test with the i915 driver (i.e. no nomodeset on the kernel cmdline), if you want you can try both VGA cable only and VGA/HDMI but it shouldn't matter. xrandr -q output shows only 55.4 and 60.0 for this resolution, so I think it doesn't make sense to test anything else. TEST-12 VGA and HDMI connected. TV set on VGA input. Reboot. The login screen is black. I connected over VNC to login (login screen is 1024x768) xrandr --output VGA1 --mode 1024x768 --rate 54.4 (nothing changes, as expected) xrandr --output VGA1 --mode 1024x768 --rate 60.0 bingo. I can see the screen with quite a bit of overscan top and bottom (exactly as I usually saw it over VGA from XP) I also tried the same test with only VGA cable connected and it works the same way. xrandr --output VGA1 --mode 800x600 --rate 60.3 also works like in windows, with overscan. I attached logs from 1024x768. So, to conclude, I think we achieved feature parity over VGA. It's just a matter of choosing the right refresh rate... Yeah, I kinda suspected that XP just picks the highest refresh rate. And likely no one ever tested your TV with anything else than XP, so that could explain why the lower refresh rate is b0rked :( Do you have any idea about the next step for HDMI? Sorry, I couldn't yet look into the details. Will do it this week. It also looks like someone else descovered the missing ingredient for interlaced support on newer chipset, so it looks like we're on track to enable 1080i on your TV (well, hopefully). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
