[Intel-gfx] [patch] Fix XV scan line calculation when rotated

[Barry Scott]

Łukasz Kuryło wrote:
> On piątek 19 czerwca 2009 18:40:48 Barry Scott wrote:
> > Łukasz Kuryło wrote:
> > > > > Or maybe after transformation to crtc coordinates, crtc->y is
> > > unnecesary?
> > > > We need someone that knows what crtc->y is used for to comment.
> > > > Then fixing the code to match will be simple.
> > > >
> > > > Barry
> > >
> > >
> > > I've updated my odg drawing. I'm thinking this should be good 
> approach:
> > >
> > >
> > > box_in_crtc_coordinates = *box;
> > > if (crtc->transform_in_use)
> > > pixman_f_transform_bounds (&crtc->f_framebuffer_to_crtc,
> > > &box_in_crtc_coordinates);
> > > y1 = (box_in_crtc_coordinates.y1 <= 0) ? 0 : 
> box_in_crtc_coordinates.y1;
> > > y2 = (box_in_crtc_coordinates.y2 <= crtc_last_scanline) ?
> > > box_in_crtc_coordinates.y2 : crtc_last_scanline;
> > >
> > >
> > > My assumption here is that after transformation to crtc space all
> > > coordinates of the box are relative to "upper left" corner of given
> > > crtc (if rotated 180 than it's lower right corner, etc.) anyway
> > > relative to first scanline.
> > > With this assumption box_in_crtc_coordinates.y1 can be negative. All
> > > thats left is that we need to now how many scanlines crt has. In
> > > normal case thats crtcbox.y2 - crtcbox.y1.
> > > But when rotation is added we need to calculate that in other way. Or
> > > maybe that information is available somewhere without calculation?
> > That's good to know what the crtc-y is for.
> > I agree it should not be used at all as the transformation will bring
> > the box
> > into the valid range of lines for the crtc.
> It will NOT! pixman_f_transform_bounds does NOT clip box to selected 
> crt area. It return smallest box
> My only assumption was that after transformation all coordinates are 
> relative to crtc origin (first pixel of first scanline). But I'm not 
> sure of that.
> I need to dig more in code to see what kind of tranformations are 
> handled by crtc->f_framebuffer_to_crtc.
We are both "assuming" and being "not sure".

What I can say is that for a single screen this works and I have 
instrumented the code to
see the before and after values to satisfy my self that this works.

I assume that before transformation the coordinates are clipped to the 
framebuffer and therefore
after transformation it is clipped to the crtc.

I don't have a dual head config that I can test this out on. Do you?

It would be easy to add a couple ErrorF to resolve this one way or the 
other.
Can you do this so that we can remove the uncertainy?

Barry