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

[Barry Scott]

Ł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.

I do not think you need to defense about y1 or y2 being out of range.
The transformation must always give you valid line numbers. In which case:

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
    y2 = box_in_crtc_coordinates.y2

is all that is needed.

If this is correct the patch to DRI2 did not need its defensive code either.

Of course adding asserts would enforce this API contract on the 
transformation.

Barry