xf86CrtcDamageShadow ?

[Thomas Hellström]

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.

Regards,
Thomas