eric at anholt.net
Tue Apr 10 14:46:24 PDT 2007
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.
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).
Eric Anholt anholt at FreeBSD.org
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the xorg