Xv to pixmaps (was Xv Xdbe combination)

[Michel Dänzer]

On Mon, 2010-04-19 at 07:56 +0200, Matthew Fincham wrote: 
> On 16-04-10 16:02, Michel Dänzer wrote:
> >
> >> While I can see the Intel driver is receiving a pixmap drawable
> >> and apparently writing to it, I see nothing on the screen.
> >>      
> > (How) Are you copying the pixmap contents to a visible window? Pixmaps
> > are offscreen by definition.
> >
> >    
> I am writing a Qt application.
> I have QPixmap - which effectively has a handle to a X pixmap - that 
> gets written to and blitted to the screen.
> I am confident this section is fine. If the pixmap is written to without 
> using Xv then the contents of the pixmap are correctly rendered on the 
> screen.

Okay, that sounds good then.


> I have attached a tgz with a number of files in:
> 
>   - .diff files are the "diff -u"'s of the modified files
>   - Xorg.0.log is a snippet of the log showing some debug logs
>   - some source files
> 
> I have included the Xorg log and some of the source files because the 
> changes included *lots* of logs so that I could trace the execution path 
> - this my first look at the X server code, so I am still feeling my way. 

BTW I think you're doing great so far considering this. :)


> 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).

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.

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.

It might be possible to make the patch less invasive overall by changing
xf86XVEnlistPortIn/RemovePortFromWindow() to
xf86XVEnlistPortIn/RemovePortFromDrawable() which handle the drawable
type internally.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer