xf86CrtcDamageShadow ?

[Thomas Hellström]

Eric Anholt wrote:
> 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.
>
>   
Yes, OK, I see what you mean.

/Thomas