[Intel-gfx] [PATCH] Fix GM965 TV out regression
I recently upgraded to ubuntu 12.04 and noticed the TV out no longer works
with kernel 3.2.0.
Tracing back through old kernels, I found the last working kernel was 2.6.35.
Now 4 years ago I fixed a similar issue in the user space intel driver by
waiting for vblank after writing to the TV_CTL register via
http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275
Low and behold, it appears 2 years later this same issue was reintroduced
in kernel 2.6.36 and has led to some very unhappy users eg
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688
Could someone please apply the following which I have confirmed re-fixes
the issue for my TV output via component video connection.
--- intel_tv.c.orig 2012-05-19 16:32:21.0 +1000
+++ intel_tv.c 2012-05-19 16:33:23.0 +1000
@@ -1186,6 +1186,9 @@ intel_tv_detect_type(struct intel_tv *in
I915_WRITE(TV_DAC, save_tv_dac ~TVDAC_STATE_CHG_EN);
I915_WRITE(TV_CTL, save_tv_ctl);
+ intel_wait_for_vblank(intel_tv-base.base.dev,
+ to_intel_crtc(intel_tv-base.base.crtc)-pipe);
+
/* Restore interrupt config */
if (connector-polled DRM_CONNECTOR_POLL_HPD) {
spin_lock_irqsave(dev_priv-irq_lock, irqflags);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Specific resolution without monitor
Hey Carl,
I had the same problem as you.
So i wanted my MediaCenter to start up at for example 15h just before i get
home. But since my TV and my AV receiver where in standby the resolution
detected by the drm driver as always wrong. So to by pass this i have changed a
bit intel drm driver and hard coded my TV EDID data directly into the driver.
This ways every time the MC starts up it thinks is connected to the PC and
setups the right resolution.
Now this is not a simple thing to do since you will need to compile the linux
kernel, you can also only compile the drm driver/module for sure but i dont
know how to do that
So what i did was, with some linux software, named edid grab or read or
something, i extracted my TV edid in HEX format. Then i changed the function
drm_do_get_edid inside the drm_edid.c file located at the linux
kernel/drivers/gpu/drm/ to ignore the i2c bus and to use the edid i defined
inside my block1 byte array. Also needed to comment out some code, since EDID
something comes in multiple messages. Below you can find my modifications.
I hope this help you out. Maybe this is not the right way of doing it, but it
worked for me. I´m not and expert on DRM or I915 driver, just wanted to make it
worked so i hard coded it all. You can always improve and maybe add the
function of reading the EDID from a file like the NVIDIA driver has.
static u8 *drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter
*adapter){ int i, j = 0, valid_extensions = 0; u8 *block, *new;
u8 block1[256] =
{0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x34,0xa9,0xa4,0xa0,0x01,0x01,0x01,0x01,
0x00,0x14,0x01,0x03,0x80,0x00,0x00,0x78,0x0a,0xda,0xff,0xa3,0x58,0x4a,0xa2,0x29,
0x17,0x49,0x4b,0x00,0x00,0x00,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,0x01,
0x01,0x01,0x01,0x01,0x01,0x01,0x02,0x3a,0x80,0xd0,0x72,0x38,0x2d,0x40,0x10,0x2c,
0x45,0x80,0xba,0x88,0x21,0x00,0x00,0x1e,0x02,0x3a,0x80,0x18,0x71,0x38,0x2d,0x40,
0x58,0x2c,0x45,0x00,0xba,0x88,0x21,0x00,0x00,0x1e,0x00,0x00,0x00,0xfc,0x00,0x50,
0x61,0x6e,0x61,0x73,0x6f,0x6e,0x69,0x63,0x2d,0x54,0x56,0x0a,0x00,0x00,0x00,0xfd,
0x00,0x17,0x3d,0x0f,0x44,0x0f,0x00,0x0a,0x20,0x20,0x20,0x20,0x20,0x20,0x01,0xd3,
0x02,0x03,0x36,0x72,0x50,0x9f,0x90,0x14,0x05,0x20,0x13,0x04,0x12,0x03,0x11,0x02,
0x16,0x07,0x15,0x06,0x01,0x23,0x09,0x07,0x01,0x78,0x03,0x0c,0x00,0x10,0x00,0xb8,
0x26,0x2f,0xc0,0x0a,0x81,0x49,0xff,0xfc,0x06,0x16,0x08,0x00,0x18,0x00,0x00,0x00,
0x00,0x00,0xe3,0x05,0x1f,0x01,0x01,0x1d,0x80,0xd0,0x72,0x1c,0x16,0x20,0x10,0x2c,
0x25,0x80,0xba,0x88,0x21,0x00,0x00,0x9e,0x01,0x1d,0x80,0x18,0x71,0x1c,0x16,0x20,
0x58,0x2c,0x25,0x00,0xba,0x88,0x21,0x00,0x00,0x9e,0x01,0x1d,0x00,0xbc,0x52,0xd0,
0x1e,0x20,0xb8,0x28,0x55,0x40,0xba,0x88,0x21,0x00,0x00,0x1e,0x01,0x1d,0x00,0x72,
0x51,0xd0,0x1e,0x20,0x6e,0x28,0x55,0x00,0xba,0x88,0x21,0x00,0x00,0x1e,0x00,0xb6};
//if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL) //
return NULL;
if ((block = kmalloc(EDID_LENGTH*2, GFP_KERNEL)) == NULL)
return NULL;
/* base block fetch */ //for (i = 0; i 4; i++) { //
if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH)) //
goto out; // if (drm_edid_block_valid(block))//
break; // if (i == 0 drm_edid_is_zero(block, EDID_LENGTH)) { //
connector-null_edid_counter++; // goto carp; //
} //} //if (i == 4) // goto carp;
//DRM_DEBUG_KMS(DUMP EDID START\n); //for(i = 0 ; i EDID_LENGTH;
i += 16 )//
DRM_DEBUG_KMS(0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x,0x%x\n,block[i],block[i+1],block[i+2],block[i+3],block[i+4],block[i+5],block[i+6],block[i+7],block[i+8],block[i+9],block[i+10],block[i+11],block[i+12],block[i+13],block[i+14],block[i+15]);
//DRM_DEBUG_KMS(\nDUMP EDID END\n);
DRM_DEBUG_KMS(Overwriting EDID\n);//DRM_DEBUG_KMS(EDID_LENGTH:
%d\n,EDID_LENGTH);
for(i = 0; i 256; i++)block[i]=block1[i];
return block;
/* if there's no extensions, we're done */ if (block[0x7e] == 0)
return block;
new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new) goto out; block = new;
for (j = 1; j = block[0x7e]; j++) {for (i = 0; i 4; i++)
{ if (drm_do_probe_ddc_edid(adapter,
block + (valid_extensions + 1) * EDID_LENGTH,
j, EDID_LENGTH)) goto out;
if (drm_edid_block_valid(block + (valid_extensions +
[Intel-gfx] [REVERT] - drm/i915: Removing TV Out modes
Further to my previous post regarding getting TV Out working on recent
kernels, I see a recent check in to the mainline kernel source removed
support for 576p TV output which I use.
Could someone please revert
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9
or at least reinstate the 576p mode that I use.
I think 480p@59.94Hz is also a valid mode (though I don't use it) and
should be left in and perhaps be renamed to just 480p since there is now
no need to differentiate frequencies.
Something like this?
--- intel_tv.c.orig 2012-05-19 17:06:11.0 +1000
+++ intel_tv.c 2012-05-19 17:19:52.0 +1000
@@ -674,6 +674,54 @@ static const struct tv_mode tv_modes[] =
.filter_table = filter_table,
},
{
+ .name = 480p,
+ .clock = 107520,
+ .refresh= 59940,
+ .oversample = TV_OVERSAMPLE_4X,
+ .component_only = 1,
+
+ .hsync_end = 64, .hblank_end = 122,
+ .hblank_start = 842, .htotal = 857,
+
+ .progressive= true, .trilevel_sync = false,
+
+ .vsync_start_f1 = 12, .vsync_start_f2 = 12,
+ .vsync_len = 12,
+
+ .veq_ena= false,
+
+ .vi_end_f1 = 44, .vi_end_f2 = 44,
+ .nbr_end= 479,
+
+ .burst_ena = false,
+
+ .filter_table = filter_table,
+ },
+ {
+ .name = 576p,
+ .clock = 107520,
+ .refresh= 5,
+ .oversample = TV_OVERSAMPLE_4X,
+ .component_only = 1,
+
+ .hsync_end = 64, .hblank_end = 139,
+ .hblank_start = 859, .htotal = 863,
+
+ .progressive= true, .trilevel_sync = false,
+
+ .vsync_start_f1 = 10, .vsync_start_f2 = 10,
+ .vsync_len = 10,
+
+ .veq_ena= false,
+
+ .vi_end_f1 = 48, .vi_end_f2 = 48,
+ .nbr_end= 575,
+
+ .burst_ena = false,
+
+ .filter_table = filter_table,
+ },
+ {
.name = 720p@60Hz,
.clock = 148800,
.refresh= 6,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REVERT] - drm/i915: Removing TV Out modes
Further to my previous post regarding getting TV Out working on recent
kernels, I see a recent check in to the mainline kernel source removed
support for 576p TV output which I use.
Could someone please revert
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9
or at least reinstate the 576p mode that I use.
I think 480p@59.94Hz is also a valid mode (though I don't use it) and
should be left in and perhaps be renamed to just 480p since there is now
no need to differentiate frequencies.
Something like this?
--- intel_tv.c.orig 2012-05-19 17:06:11.0 +1000
+++ intel_tv.c 2012-05-19 17:19:52.0 +1000
@@ -674,6 +674,54 @@ static const struct tv_mode tv_modes[] =
.filter_table = filter_table,
},
{
+ .name = 480p,
+ .clock = 107520,
+ .refresh= 59940,
+ .oversample = TV_OVERSAMPLE_4X,
+ .component_only = 1,
+
+ .hsync_end = 64, .hblank_end = 122,
+ .hblank_start = 842, .htotal = 857,
+
+ .progressive= true, .trilevel_sync = false,
+
+ .vsync_start_f1 = 12, .vsync_start_f2 = 12,
+ .vsync_len = 12,
+
+ .veq_ena= false,
+
+ .vi_end_f1 = 44, .vi_end_f2 = 44,
+ .nbr_end= 479,
+
+ .burst_ena = false,
+
+ .filter_table = filter_table,
+ },
+ {
+ .name = 576p,
+ .clock = 107520,
+ .refresh= 5,
+ .oversample = TV_OVERSAMPLE_4X,
+ .component_only = 1,
+
+ .hsync_end = 64, .hblank_end = 139,
+ .hblank_start = 859, .htotal = 863,
+
+ .progressive= true, .trilevel_sync = false,
+
+ .vsync_start_f1 = 10, .vsync_start_f2 = 10,
+ .vsync_len = 10,
+
+ .veq_ena= false,
+
+ .vi_end_f1 = 48, .vi_end_f2 = 48,
+ .nbr_end= 575,
+
+ .burst_ena = false,
+
+ .filter_table = filter_table,
+ },
+ {
.name = 720p@60Hz,
.clock = 148800,
.refresh= 6,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/edid: adjust double-clocked cea modes
On Tue, May 15, 2012 at 11:33:43AM -0400, Adam Jackson wrote: On 5/14/12 3:43 PM, Paulo Zanoni wrote: Also, I think flag DRM_MODE_FLAG_DBLCLK does not sound correct for them, so we would need to create flags: - DRM_MODE_FLAG_PR_1_to_10 - DRM_MODE_FLAG_PR_1_or_2 - DRM_MODE_FLAG_PR_1_or_2_or_4 Or any other more creative names. And then we should cross our fingers in the hope that they don't start creating modes with other possible variations of PR :) Anyway, how will the user be able to choose the wanted PR? What about the aspect ratio? Yet Another Connector Property? Well, one thing at a time. Right now we don't have the concept of a mode property. Therefore, modes exposed to userspace should all be unique. Exposing the pixel repeat to userspace as a connector property is wrong because it doesn't apply to all modes for a connector. So my initial inclination would be to do something like this in the flags field: --- a/include/drm/drm_mode.h +++ b/include/drm/drm_mode.h @@ -58,6 +58,9 @@ #define DRM_MODE_FLAG_PIXMUX (111) #define DRM_MODE_FLAG_DBLCLK (112) #define DRM_MODE_FLAG_CLKDIV2 (113) +/* begin non-xorg definitions */ +#define DRM_PIXREP_MASK(15 14) +#define DRM_MODE_FLAG_PIXREP(x) (((x) 14) DRM_PIXMULT_MASK) /* DPMS flags */ /* bit compatible with the xorg definitions. */ The timings for the variably-repeated modes won't change (right?) so this is the only way to get the desired pixel repeat passed into the modesettinng path. And then the one to ten and one two or four modes simply need to be added to the list multiple times, once for each possible pixel replication, and with varying names depending on the effective framebuffer size. Problems with this approach are that it means rewriting the CEA mode list or the VIC table walk or both, and that it means creating a class of modes that userspace can set but not create (which means, if your X driver is parsing EDID itself instead of just using the damn kernel mode list, that many of the modes will be inaccessible to X). Neither is insoluble, just nngh. For the variable pixel-repeat modes I'd propose that we mark them up with a flag and flat-out reject them int the cea edid parser. All these modes are super-low-res interlaced things likely only good to upscale sdtv material. At least on Intel we might as well use the hw scaler for them. The double-clocked ones look slightly more sane, so I guess we could keep these. If I manage to get them to work anywhere else than on my machine here :( The dual-aspect-ratio modes are, well, ugly. Ideally we'd have scaler hardware on all digital output routes so we could just make that a connector property, and then hide the choice of mechanism inside the drm (either in the monitor if the infoframe says so / if it's controllable with DDC/CI or something, or in the GPU if not). I don't know if all the digital outputs in the world live up to that lofty goal. Failing that we could encode the widescreen-ness in the mode name? All quite horrible. TVs really are the worst thing. tbh our current avi infoframe support is ridiculously lacking - we don't even properly work the overscan properties, set the VIC number and all kinds of stuff. I think we can defer worrying about these multi-aspect ratio modes until everything else works somewhat. Cheers, 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] Fix GM965 TV out regression
On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote: I recently upgraded to ubuntu 12.04 and noticed the TV out no longer works with kernel 3.2.0. Tracing back through old kernels, I found the last working kernel was 2.6.35. Now 4 years ago I fixed a similar issue in the user space intel driver by waiting for vblank after writing to the TV_CTL register via http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275 Low and behold, it appears 2 years later this same issue was reintroduced in kernel 2.6.36 and has led to some very unhappy users eg https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688 Could someone please apply the following which I have confirmed re-fixes the issue for my TV output via component video connection. Nice piece of diggin through code! A few minor nitpicks on the patch: - sob-line is missing (see Documentation/SubmittingPatches) - are there any other people who have tested this patch? If so, please include them in the patch with a Tested-by: Name mail@server Rodrigo, can you please check this patch with the docs and maybe quickly run it? Thanks, 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] [REVERT] - drm/i915: Removing TV Out modes
On Sat, May 19, 2012 at 09:41:00PM +1000, Robert Lowery wrote: Further to my previous post regarding getting TV Out working on recent kernels, I see a recent check in to the mainline kernel source removed support for 576p TV output which I use. Could someone please revert http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=55a6713b3f30a5024056027e9dbf03ac8f13bfc9 or at least reinstate the 576p mode that I use. I think 480p@59.94Hz is also a valid mode (though I don't use it) and should be left in and perhaps be renamed to just 480p since there is now no need to differentiate frequencies. Something like this? Hm, I have no idea whether we should just revert the entire commit. Rodrigo, your commit commit 55a6713b3f30a5024056027e9dbf03ac8f13bfc9 Author: Rodrigo Vivi rodrigo.v...@gmail.com Date: Thu Dec 15 14:47:33 2011 -0200 drm/i915: Removing TV Out modes. is a bit thin on justification as to why we need that. Can you please explain? Thanks, 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] Fix GM965 TV out regression
On Sat, 19 May 2012 20:38:20 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote: Could someone please apply the following which I have confirmed re-fixes the issue for my TV output via component video connection. Rodrigo, can you please check this patch with the docs and maybe quickly run it? The patch looks reasonable (just lacking a POSTING_READ prior to the wait as that is not guaranteed by the wait). My guess would be that we need a vblank to be sure that the writes latched and we indeed switched off the detection mode prior to turning the pipe off. Not sure how that results in ghost TV detection, and so it would be good to capture any final explanation as a code comment to make sure that the wait isn't deleted again in future. -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
[Intel-gfx] [PATCH] drm/i915: don't return -ENXIO from gmbus xfer
... too much risk for flaky edid transfers. This regression has been introduced in commit e646d5773572bf52017983d758bdf05777dc5600 Author: Daniel Kurtz djku...@chromium.org Date: Fri Mar 30 19:46:38 2012 +0800 drm/i915/intel_i2c: always wait for IDLE before clearing NAK This patch keeps the improved NAK handling on the hw side, but reverts the change to return -ENXIO in case the gmbus controller reports a NAK. Cc: Daniel Kurtz djku...@chromium.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518 Reported-and-Tested-by: Julian Simioni julian.simi...@gmail.com Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_i2c.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index e04255e..0588d8e 100644 --- a/drivers/gpu/drm/i915/intel_i2c.c +++ b/drivers/gpu/drm/i915/intel_i2c.c @@ -418,10 +418,11 @@ clear_err: * If no ACK is received during the address phase of a transaction, * the adapter must report -ENXIO. * It is not clear what to return if no ACK is received at other times. -* So, we always return -ENXIO in all NAK cases, to ensure we send -* it at least during the one case that is specified. +* +* Unfortunately we can't afford false positives in returning -ENXIO, +* hence never return -ENXIO. */ - ret = -ENXIO; + ret = i; goto out; timeout: -- 1.7.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: unlock mutex before intel_modeset_init_hw
On Fri, May 18, 2012 at 10:22:32PM +0100, Chris Wilson wrote: On Fri, 18 May 2012 17:57:13 -0300, Paulo Zanoni przan...@gmail.com wrote: From: Paulo Zanoni paulo.r.zan...@intel.com Because on IVB, intel_modeset_init_hw calls gen6_enable_rps with locks the mutex. This problem broke suspend on my machine. It was introduced in the following commit: commit 2e1352cf196094f44e73776f41087f4c489ab936 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Wed May 9 11:56:28 2012 +0100 drm/i915: gen6_enable_rps() wants to be called after ring initialisation This fix was actually suggested by Chris Wilson on a conversation, so the credit goes to him. I just bisected the problem, reported to him and tested his idea. Cc: Chris Wilson ch...@chris-wilson.co.uk Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com My mistake, I thought I was being consistent with the other callsites, when in fact it was the exact opposite. Daniel, do you mind erasing the mistake from history and crediting Paulo for v3? :) History rectified, thanks for the fix. -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] OpenGL sampler objects on sandybridge with Ubuntu Linux 12.04
Hi, Please file a bug report with the below details on bugs.freedesktop.org against Mesa - DRI/Intel(i965). Thanks, Daniel On Wed, May 16, 2012 at 09:58:45AM +, Mark Newiger wrote: Hello, We are using an MiniPC with the following configuration: - Intel SandyBridge PC Mainboard DH61AG and integrated Intel HD Graphics 3000 - Dual OS: Windows 7 32bit and Ubuntu 12.04 32bit When using OpenGL sampler objects for configuring textures, on Ubuntu I have to create a mipmap chain by calling glGenerateMipmap(). Otherwise the texture sampling will not work (e.g. returns black). Take the following example: // Init int texture; glGenTextures(1, texture); glBindTexture(GL_TEXTURE_2D, texture); glTexImage2D(...); int sampler; glGenSamplers(1, sampler); glSamplerParameteri(sampler, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glSamplerParameteri(sampler, GL_TEXTURE_MAG_FILTER, GL_LINEAR); // Render loop glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture); glBindSampler(0, sampler); ... This works perfectly on Windows but not on Ubuntu. For Ubuntu Linux I have to add the following: //Init ... glTexImage2D(...); glGenerateMipmap(GL_TEXTURE_2D); Without the mipmap the texture sampling does not work, although I am not using any mipmaps. When using the traditional texture filter configuration, this problem does not occur and the code behaves the same on Windows and Linux: // Render loop glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); Seems to be a driver bug for me. Or did I oversee something ? Thanks and best regards Mark Best regards, Mark Newiger | Senior Software Engineer SeeFront GmbH Esplanade 41 | D-20354 Hamburg, Germany Office: +49 40 416 22 64-83 mark.newi...@seefront.commailto:mark.newi...@seefront.com | www.seefront.comhttp://www.seefront.com Managing Director: Christoph Grossmann Registered seat of the company: Hamburg Register Court: Amtsgericht Hamburg HRB 98205 VAT-ID-No. DE248406189 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- 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] drm/i915: don't clobber the pipe param in sanitize_modesetting
On Sun, May 13, 2012 at 09:33:42PM +0100, Chris Wilson wrote: On Sun, 13 May 2012 22:29:25 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: ... we need it later on in the function to clean up pipe - plane associations. This regression has been introduced in commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Thu Mar 22 15:00:50 2012 + drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Cc: Chris Wilson ch...@chris-wilson.co.uk Cc: sta...@kernel.org (the regression was Cc: stable, too) Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk Queued for -next, thanks for the review. -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] drm/i915: Convert BUG_ON(!pll-active) and friends to a WARN
On Sun, May 13, 2012 at 09:15:51PM +0100, Chris Wilson wrote: On Sun, 13 May 2012 22:08:10 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, May 13, 2012 at 08:16:12PM +0100, Chris Wilson wrote: Turn a fatal lockup into a merely blank display with lots of shouty messages. v2: Whilst in the area, convert the other BUG_ON into less fatal errors. In particular, note that we may be called on a PCH platform not using PLLs, such as Haswell, and so we do not always want to BUG_ON(!pll) Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Ok, I guess you want me to drop v1 of this again. I'll wait for a bit of feedback on these two then (and the tested-by from qa on the 2nd one). Up to you, I thought that the original patch was overshadowed by the your change request and little reason for it to be split. It would be good to get QA's tested-by on the second patch at any rate. Ok, I've picked up v2 of patch 1 and the 2nd patch. Looks like we still have an issue somewhere in that code that makes ilk unhappy :( -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] drm/i915: fixup infoframe support for sdvo
On Sat, May 12, 2012 at 08:22:00PM +0200, Daniel Vetter wrote:
At least the worst offenders:
- SDVO specifies that the encoder should compute the ecc. Testing also
shows that we must not send the ecc field, so copy the dip_infoframe
struct to a temporay place and avoid the ecc field. This way the avi
infoframe is exactly 17 bytes long, which agrees with what the spec
mandates as a minimal storage capacity (with the ecc field it would
be 18 bytes).
- Only 17 when sending the avi infoframe. The SDVO spec explicitly
says that sending more data than what the device announces results
in undefined behaviour.
- Add __attribute__((packed)) to the avi and spd infoframes, for
otherwise they're wrongly aligned. Noticed because the avi infoframe
ended up being 18 bytes large instead of 17. We haven't noticed this
yet because we don't use the uint16_t fields yet (which are the only
ones that would be wrongly aligned).
This regression has been introduce by
3c17fe4b8f40a112a85758a9ab2aebf772bdd647 is the first bad commit
commit 3c17fe4b8f40a112a85758a9ab2aebf772bdd647
Author: David Härdeman da...@hardeman.nu
Date: Fri Sep 24 21:44:32 2010 +0200
i915: enable AVI infoframe for intel_hdmi.c [v4]
Patch tested on my g33 with a sdvo hdmi adaptor.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Forwarded from the bug entry:
Tested-by: Peter Ross pr...@xvid.org (G35 SDVO-HDMI)
---
drivers/gpu/drm/i915/intel_drv.h |4 ++--
drivers/gpu/drm/i915/intel_sdvo.c | 11 +--
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d51f27f..3e09188 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -280,12 +280,12 @@ struct dip_infoframe {
uint16_t bottom_bar_start;
uint16_t left_bar_end;
uint16_t right_bar_start;
- } avi;
+ } __attribute__ ((packed)) avi;
struct {
uint8_t vn[8];
uint8_t pd[16];
uint8_t sdi;
- } spd;
+ } __attribute__ ((packed)) spd;
uint8_t payload[27];
} __attribute__ ((packed)) body;
} __attribute__((packed));
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 7d3f238..125228e 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -887,17 +887,24 @@ static bool intel_sdvo_set_avi_infoframe(struct
intel_sdvo *intel_sdvo)
};
uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
uint8_t set_buf_index[2] = { 1, 0 };
- uint64_t *data = (uint64_t *)avi_if;
+ uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
+ uint64_t *data = (uint64_t *)sdvo_data;
unsigned i;
intel_dip_infoframe_csum(avi_if);
+ /* sdvo spec says that the ecc is handled by the hw, and it looks like
+ * we must not send the ecc field, either. */
+ memcpy(sdvo_data, avi_if, 3);
+ sdvo_data[3] = avi_if.checksum;
+ memcpy(sdvo_data[4], avi_if.body, sizeof(avi_if.body.avi));
+
if (!intel_sdvo_set_value(intel_sdvo,
SDVO_CMD_SET_HBUF_INDEX,
set_buf_index, 2))
return false;
- for (i = 0; i sizeof(avi_if); i += 8) {
+ for (i = 0; i sizeof(sdvo_data); i += 8) {
if (!intel_sdvo_set_value(intel_sdvo,
SDVO_CMD_SET_HBUF_DATA,
data, 8))
--
1.7.8.3
--
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] Fix GM965 TV out regression
On Sat, May 19, 2012 at 04:52:10PM +1000, Robert Lowery wrote: I recently upgraded to ubuntu 12.04 and noticed the TV out no longer works with kernel 3.2.0. Tracing back through old kernels, I found the last working kernel was 2.6.35. Now 4 years ago I fixed a similar issue in the user space intel driver by waiting for vblank after writing to the TV_CTL register via http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/i830_tv.c?id=1142be53eb8d2ee8a9b60ace5d49f0ba27332275 Low and behold, it appears 2 years later this same issue was reintroduced in kernel 2.6.36 and has led to some very unhappy users eg https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/763688 Could someone please apply the following which I have confirmed re-fixes the issue for my TV output via component video connection. Nice piece of diggin through code! A few minor nitpicks on the patch: - sob-line is missing (see Documentation/SubmittingPatches) - are there any other people who have tested this patch? If so, please include them in the patch with a Tested-by: Name mail@server Signed-off-by: Robert Lowery rglow...@exemail.com.au I'm not aware of anyone else that has tested this patch as yet. Rodrigo, can you please check this patch with the docs and maybe quickly run it? Thanks, 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
