xf86CrtcDamageShadow ?

[Eric Anholt]

On Wed, 2007-04-11 at 08:53 +0200, Thomas Hellström wrote:
> Eric Anholt wrote:
> > On Tue, 2007-04-10 at 21:45 +0200, Thomas Hellström wrote:
> >   
> >>> On Tue, 2007-04-10 at 19:09 +0200, Thomas Hellström wrote:
> >>>       
> >>>> Hi,
> >>>>
> >>>> I have a couple of questions related to the xf86CrtcDamageShadow
> >>>> function:
> >>>>
> >>>> The current version may damage regions which is not part of the
> >>>> framebuffer.
> >>>> For example, if a rotated (90) buffer has dimensions 1024x768, and the
> >>>> unrotated framebuffer has the
> >>>> same dimensions, xf86CrtcDamageShadow will call DamageDamageRegion with
> >>>> a 768x1024 region, which is larger than the
> >>>> original 1074x768 pixmap.
> >>>>         
> >>> Sounds like it's ignoring rotation?
> >>>       
> >> This happens with an original non-rotated setup. Framebuffer (resizable)
> >> is 1024x768. When "xrandr -o 1" (90 degrees) is called, a rotated buffer
> >> (1024x768) is allocated using the crtc callbacks, and xf86CrtcDamageShadow
> >> calls DamageDamageRegion with a 768x1024 region, but the buffer
> >> intersection is only 768x768.
> >>
> >> I'm not sure whether the framebuffer should have been resized to 768x1024
> >> in this case, but since rotation is set up per output, I guess not.
> >>     
> >
> > Yeah, that bug should have been fixed yesterday -- we had a situation in
> > the classic randr path where we were theoretically scanning out an area
> > not part of the framebuffer, which should never happen.
> >   
> OK, I'll update and check. Thanks.
> > That said, your Render hooks should have dealt with the silly requests
> > it got appropriately, by only rendering the 768x768 region (since the
> > source picture didn't have repeating turned on).
> >
> >   
> Yes, I suspected that. Is there a reason EXA is not performing composite 
> area validation?
> If the responsibility is left to the driver hooks the validation code 
> will be duplicated across
> drivers.

No, you don't need any validation code -- you have to be able to program
your hardware to source from pixels inside or outside the pixmap in the
way the protocol requires.  Think about having the normal no-repeat
setting, bilinear filtering, and trying to draw the full source image
rotated 45 degrees -- you can't trim away accesses outside of the source
pixmap because of the filtered edges.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070411/8bc6bb11/attachment.pgp>