Bug 72220

Created attachment 90087 [details]
abnormal color

Created attachment 90088 [details]
Normal color

Created attachment 90089 [details]
dmesg

Created attachment 90090 [details]
xorg log

Looks like an error in the secondary sprite plane handling.

(In reply to comment #5)
> Looks like an error in the secondary sprite plane handling.

Wouldn't that require "-vo xv:adaptor=1" on the mplayer cmdline? Or are we lacking gen8 textured video code (no xvinfo output included so I can't tell what's being used here)?

Created attachment 90330 [details]
vxiinfo

We tried to play h264 video file with the same parameters, the color was error too.

(In reply to comment #6)
> (In reply to comment #5)
> Looks like an error in the secondary sprite plane
> handling.

Wouldn't that require "-vo xv:adaptor=1" on the mplayer cmdline?
> Or are we lacking gen8 textured video code (no xvinfo output included so I
> can't tell what's being used here)?

Yes. This is related with that the texutred Xv is not added for gen8.

Note that currently bdw should support both sprite- and texture-based Xv playback now.

(In reply to comment #10)
> Note that currently bdw should support both sprite- and texture-based Xv
> playback now.

Thanks for the clarification. And your efforts are appreciated. 
I check it on BDW. And the textured XV can work as expected.

Hi, JinXian
     Will you please double check it again?

Thanks.

(In reply to comment #11)
> (In reply to comment #10)
> > Note that currently bdw should support both sprite- and texture-based Xv
> > playback now.
> 
> Thanks for the clarification. And your efforts are appreciated. 
> I check it on BDW. And the textured XV can work as expected.
> 
> Hi, JinXian
>      Will you please double check it again?
> 
> Thanks.

Yes, it works well now on latest drm-intel-nightly(1be8f2b4dd6d3db00af24d4891c82d2650bd282d), thanks.

Can you please now test with "mplayer -vo xv:adaptor=1 MPEG-2.mpeg" to see if the original problem with the sprites being miscolored is still true?

(In reply to comment #13)
> Can you please now test with "mplayer -vo xv:adaptor=1 MPEG-2.mpeg" to see
> if the original problem with the sprites being miscolored is still true?

Yes, with command "mplayer -vo xv:adaptor=1 MPEG-2.mpeg", the miscolored problem still can be reproduced.

I tested this myself and it does look like the hardware is simply doing something wrong. I didn't find any magic bit to fix it. Need to poke at some hardware folks...

This should be fixed now. Please confirm.

Don't think so, Ville found out what was going wrong, but as yet there have been no patches.

Isn't it:

commit b934e3839c15da95f9d5fd8fe29fbb04774d15c3
Author: Ville Syrj?l? <ville.syrjala@linux.intel.com>
Date:   Wed Mar 5 13:05:45 2014 +0200

    drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW

Yes, apologies I missed it when looking for recent commits from Ville.


commit c7c656226842679bcd9f39dc24441b4ff398a850
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Wed Mar 5 13:05:45 2014 +0200

    drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDW
    
    Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1
    registers with 0xffffffff. Move the parens to the correct place
    to avoid this.
    
    In particular this caused bit 30 of said registers to be set, which
    caused the sprite CSC to produce incorrect results.
    
    Cc: stable@vger.kernel.org
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220
    Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
    Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

checked on latest -nightly(07071a9d41aed59f4f2ba66afb82ec35557a80c1), this bug still can be reproduce.

(In reply to comment #20)
> checked on latest -nightly(07071a9d41aed59f4f2ba66afb82ec35557a80c1), this
> bug still can be reproduce.

Are you still seeing this?

Also what's the problem with BYT and HSW?

Created attachment 97438 [details]
mplayer dmesg on HSW-M

This bug still can be reproduce on latest -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to reproduce on BYT and HSW too.

(In reply to comment #22)
> Created attachment 97438 [details]
> mplayer dmesg on HSW-M
> 
> This bug still can be reproduce on latest
> -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to
> reproduce on BYT and HSW too.

Is the exact same color issue, or something else?

Can you take a picture with a camera?

Created attachment 97458 [details]
adaptor=0

Created attachment 97459 [details]
adaptor=1

(In reply to comment #23)
> (In reply to comment #22)
> > Created attachment 97438 [details]
> > mplayer dmesg on HSW-M
> > 
> > This bug still can be reproduce on latest
> > -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to
> > reproduce on BYT and HSW too.
> 
> Is the exact same color issue, or something else?
> 
> Can you take a picture with a camera?

I uploaded two pictures. you can check the difference between adaptor=1 and adaptor=0. thanks.

Created attachment 97460 [details]
adaptor=1

(In reply to comment #26)
> (In reply to comment #23)
> > (In reply to comment #22)
> > > Created attachment 97438 [details]
> > > mplayer dmesg on HSW-M
> > > 
> > > This bug still can be reproduce on latest
> > > -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to
> > > reproduce on BYT and HSW too.
> > 
> > Is the exact same color issue, or something else?
> > 
> > Can you take a picture with a camera?
> 
> I uploaded two pictures. you can check the difference between adaptor=1 and
> adaptor=0. thanks.

I don't see any significant color difference there. The sprite case looks to have some kind of moire stuff there but I'm not sure if that's due to the camera or display. In any case it looks nothing like the BDW issue this bug is about.

Also I can't see any color problems on my HSW machine here.

I think I'm going to need a better description of the problem before I can proceed.

Created attachment 97550 [details]
snapshot

(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #23)
> > > (In reply to comment #22)
> > > > Created attachment 97438 [details]
> > > > mplayer dmesg on HSW-M
> > > > 
> > > > This bug still can be reproduce on latest
> > > > -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to
> > > > reproduce on BYT and HSW too.
> > > 
> > > Is the exact same color issue, or something else?
> > > 
> > > Can you take a picture with a camera?
> > 
> > I uploaded two pictures. you can check the difference between adaptor=1 and
> > adaptor=0. thanks.
> 
> I don't see any significant color difference there. The sprite case looks to
> have some kind of moire stuff there but I'm not sure if that's due to the
> camera or display. In any case it looks nothing like the BDW issue this bug
> is about.
> 
> Also I can't see any color problems on my HSW machine here.
> 
> I think I'm going to need a better description of the problem before I can
> proceed.

Sorry, I mean here has blue borders upper and lower of the screen while playing video with parameter "adaptor=1", but the blue borders haven't with "adaptor=0"  .
Please check the snapshot for details. thanks.

(In reply to comment #30)
> (In reply to comment #28)
> > (In reply to comment #26)
> > > (In reply to comment #23)
> > > > (In reply to comment #22)
> > > > > Created attachment 97438 [details]
> > > > > mplayer dmesg on HSW-M
> > > > > 
> > > > > This bug still can be reproduce on latest
> > > > > -nightly(8c7da4ebd7c0aa6f24a558634f6f59204cf65c0b), This bug is able to
> > > > > reproduce on BYT and HSW too.
> > > > 
> > > > Is the exact same color issue, or something else?
> > > > 
> > > > Can you take a picture with a camera?
> > > 
> > > I uploaded two pictures. you can check the difference between adaptor=1 and
> > > adaptor=0. thanks.
> > 
> > I don't see any significant color difference there. The sprite case looks to
> > have some kind of moire stuff there but I'm not sure if that's due to the
> > camera or display. In any case it looks nothing like the BDW issue this bug
> > is about.
> > 
> > Also I can't see any color problems on my HSW machine here.
> > 
> > I think I'm going to need a better description of the problem before I can
> > proceed.
> 
> Sorry, I mean here has blue borders upper and lower of the screen while
> playing video with parameter "adaptor=1", but the blue borders haven't with
> "adaptor=0"  .
> Please check the snapshot for details. thanks.

I would guess that's just because HSW/BYT sprites don't support scaling. So the video aspect ratio doesn't match the display aspect ratio and mplayer tries to scale the video to the proper aspect ratio, but the hardware can't actually do that. Currently we have no way to tell userspace that the sprite doesn't support scaling.

Closing this bug as fixed.

mplayer asks what the best size is for a particular video frame - we obviously report no scaling and so expect mplayer to fill the entire output. Maybe this

static int sna_video_sprite_best_size(ClientPtr client,
                                      XvPortPtr port,
                                      CARD8 motion,
                                      CARD16 vid_w, CARD16 vid_h,
                                      CARD16 drw_w, CARD16 drw_h,
                                      unsigned int *p_w,
                                      unsigned int *p_h)
{
        struct sna_video *video = port->devPriv.ptr;
        struct sna *sna = video->sna;

        if (sna->kgem.gen >= 075) {
                *p_w = vid_w;
                *p_h = vid_h;
        } else {
                *p_w = drw_w;
                *p_h = drw_h;
        }

        return Success;
}

is garbage?

Hmm, should that really be >= 071 then? Or maybe < 071?

(In reply to comment #33)
> Hmm, should that really be >= 071 then? Or maybe < 071?

Yeah >=071 seems like the right choice here. But that won't help mplayer as it doesn't use XvQueryBestSize(). I cooked up a quick and dirty patch to make it do that and it then it falls back to using swscale. But I'm not sure if such a patch would be OK for upstream since the best size query is more of a hint, and if the driver author was more worried about quality than anything else it might reject the scaling request. Based on a quick look at all the open source drivers only tdfx would fall back to swscale for downscaling with my patch, the rest would seem unaffected. And I have no idea what the closed source drivers would do.

Created attachment 98639 [details] [review]
[PATCH] vo_xv: Check whether the Xv adaptor/port supports scaling

Here's my mplayer patch for reference. I guess I could post it to mplayer-dev-eng and see what happens...

Chris&Ville, can QA close this bug?

Yes, the remaining colorkeying looks to be a mplayer issue.

(In reply to comment #37)
> Yes, the remaining colorkeying looks to be a mplayer issue.

Verified according the comment.

Closing old verified.