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:
>>>> I have a couple of questions related to the xf86CrtcDamageShadow
>>>> The current version may damage regions which is not part of the
>>>> 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
If the responsibility is left to the driver hooks the validation code
will be duplicated across
More information about the xorg