<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"><html><head><meta name="qrichtext" content="1" /><style type="text/css">p, li { white-space: pre-wrap; }</style></head><body style=" font-family:'DejaVu Sans'; font-size:8pt; font-weight:400; font-style:normal;">> > 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? </body></html>