[Intel-gfx] [PATCH] Use 720x480 as the preferred mode for SDVO-TV

There is no preferred mode for SDVO-TV, so choose 720x480 as preferred mode Signed-off-by: Hai Lan --- drivers/gpu/drm/i915/intel_sdvo.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 7c50cdc..

Re: [Intel-gfx] Placement and cropping of video due to aspect ratio mismatch

On Tue, 2011-05-31 at 16:28 +0800, Jyotsana wrote: > Hi, > > I am playing video using "libva-1.0.7" and gstreamer-vaapi plugin. > A window is created and passed to the plugin so that video is rendered > on it. > There is an observation if the aspect ratio of the window is different > from the as

[Intel-gfx] [PATCH 2/2] drm/i915: Fix missed interrupts on gen6 blit ring by holding FORCEWAKE up.

Before this patch, I was experiencing missed IRQs (hang, then dmesg saying IRQ missed, then continuing) when running piglit copypixels-sync about 0.5% of the time (no single run series I've done so far got beyond 400 consecutive successes). With this patch, I'm over 3200 consecutive successes with

[Intel-gfx] [PATCH 1/2] drm/i915: Control gen6 ring interrupts through a single mask field.

The BSpec says that the GTIMR is not to be used for masking interrupts. Regardless, writing one register should be better than writing two registers. Signed-off-by: Eric Anholt --- drivers/gpu/drm/i915/i915_irq.c | 19 + drivers/gpu/drm/i915/intel_ringbuffer.c | 32 +

Re: [Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

On 6/1/11 5:06 PM, Florian Mickler wrote: Well... because the endeffect is the same in my case. :) But yes, if there is a preferred mode, that should be used. Is there a preferred mode in all cases? For any display with a discrete number of pixels (LCDs, etc), almost always. CRTs, most of

Re: [Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

On Wed, 01 Jun 2011 16:48:30 -0400 Adam Jackson wrote: > On 6/1/11 4:44 PM, Florian Mickler wrote: > > I think using horizontal spanning as a default is a good idea. > > > > Also bringing all outputs up in their preferred mode could be the right > > move. > > > > [That commit in question wouldn't

Re: [Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

On 6/1/11 4:44 PM, Florian Mickler wrote: I think using horizontal spanning as a default is a good idea. Also bringing all outputs up in their preferred mode could be the right move. [That commit in question wouldn't help my case, since I have a "Right Of" in the xorg.conf and thus it would use

Re: [Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

On Wed, 01 Jun 2011 15:30:03 -0400 Adam Jackson wrote: > On 6/1/11 6:06 AM, Florian Mickler wrote: > > Recently the kernel started reporting my outputs in a different ordering > > due to > > > > commit cb0953d734 > > (drm/i915: Initialize LVDS and eDP outputs before anything else) > >

Re: [Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

On 6/1/11 6:06 AM, Florian Mickler wrote: Recently the kernel started reporting my outputs in a different ordering due to commit cb0953d734 (drm/i915: Initialize LVDS and eDP outputs before anything else) Which made X choose a "wrong" resolution for my VGA display. Since they are alig

Re: [Intel-gfx] UXA clipping reduction

On Wed, 1 Jun 2011 00:02:53 -0700, Eric Anholt wrote: > 1) Clip against each box of the clip > 2) Reject per box > 3) draw. I didn't try to figure out the old code, but the new code looks correct to me. Reviewed-by: Keith Packard -- keith.pack...@intel.com pgpLw85aLaP0x.pgp Description: P

[Intel-gfx] [PATCH 1/3] uxa: Simplify BLT solid acceleration for spans filling by only clipping once.

We were clipping each span against the bounds of the clip, throwing out the span early if it was all clipped, and then walked the clip box clipping against each of the cliprects. We would expect spans to typically be clipped against one box, and not thrown out, so we were not saving any work there

[Intel-gfx] UXA clipping reduction

There's this odd pattern in some UXA code that appears to have been carried over from fbfillrect.c where for each thing to be filled we: 1) clip against the clip extents 2) trivial reject 3) clip that against each box of the clip 4) reject per box 5) draw. I don't see a justification for this com

[Intel-gfx] [PATCH 3/3] uxa: Simplify uxa_poly_fill_rect by only clipping once.

--- uxa/uxa-accel.c | 87 +-- 1 files changed, 27 insertions(+), 60 deletions(-) diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c index 8f6da63..dd83542 100644 --- a/uxa/uxa-accel.c +++ b/uxa/uxa-accel.c @@ -785,10 +785,7 @@ uxa_poly_fill_rect(D

[Intel-gfx] [PATCH 2/3] uxa: Simplify Composite solid acceleration for spans by only clipping once.

Unlike the previous commit removing this style of code, the code in this one was originally wrong, and would fail to clip in the second pass of clipping when y was > pbox->y2. Bug #37233. --- uxa/uxa-accel.c | 79 -- 1 files changed, 24 insert

[Intel-gfx] Multiple monitors

Hi all, I am trying to setup xorg.conf for 2 monitors 1. Integrated monitor (HDMI1) 2. External monitor (HDMI3) so i need the External monitor to work. here what i did so far: $ xrandr Screen 0: minimum 320 x 200, current 4000 x 2000, maximum 8192 x 8192 VGA1 disconnected (normal left inv

[Intel-gfx] [PATCH] change initial modesetting if outputs are aligned in 1 dimension

Recently the kernel started reporting my outputs in a different ordering due to commit cb0953d734 (drm/i915: Initialize LVDS and eDP outputs before anything else) Which made X choose a "wrong" resolution for my VGA display. Since they are aligned horizontally, I wish them to be aligned in