On 20-04-10 11:15, Michel Dänzer wrote:
One unexpected thing I found was that the (x,y) of the drawable, when it
was a pixmap, was not (0,0) but an apparently random number. This may
point to a problem with what I have done, but it is worked around (see
xf86xv.c:1819).
Are you using XAA? Textured video to pixmaps can't work reliably with
that. Use EXA (or UXA with newer versions of the intel driver).
I have been using XAA, but it doesn't work when using EXA either
One other potential problem I notice is that xf86XVDestroyPixmap()
always removes all pixmap privates. In contrast to windows, pixmaps are
reference counted; pScreen->DestroyPixmap decreases the reference count
and only actually destroys the pixmap when it goes to 0. So
xf86XVDestroyPixmap() should only remove the privates etc. when the
reference count is 1, in which case the lower layers will decrease it to
0 and destroy the pixmap.
Thanks. I didn't see that and have now fixed it.
Also, the patch just removes the pDraw->type != DRAWABLE_WINDOW checks
in a couple of places where the surrounding code still assumes that the
drawable is a window. Maybe those cases aren't immediately relevant for
you though.
Yes, they are not being called at the moment. I would need to either
reinsert them or implement them if we get to the point where a patch can
be submitted.
It might be possible to make the patch less invasive overall by changing
xf86XVEnlistPortIn/RemovePortFromWindow() to
xf86XVEnlistPortIn/RemovePortFromDrawable() which handle the drawable
type internally.
Good idea.
I have a few questions:
1. Does REGION_INIT/REGION_UNINIT need to be called when using a pixmap?
2. Any reason why the drawable (x,y) is not (0,0) when it is a pixmap -
should it be? The position seems to vary quite a bit, and the numbers
seem quite large (>2000).
3. Pixmap memory - is it card or system memory?
Currently the pixmap is just black where I expect the image to have been
drawn to the pixmap. I think this is related to the (x,y) of the
drawable, but maybe others have other ideas.
Thanks again.
Matthew
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
