xf86CrtcDamageShadow ?

Thomas Hellström thomas at tungstengraphics.com
Tue Apr 10 23:53:39 PDT 2007

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


More information about the xorg mailing list