CVS Update: xc (branch: trunk)

Benjamin Herrenschmidt benh at kernel.crashing.org
Mon Oct 10 01:12:45 PDT 2005


> Ah.  The intention of the pinned pixmaps in my mind is just for the
> purpose of helping to attempt an accelerated op.  For example, with
> component alpha we'd like to copy out the [chunk of the] destination
> pixmap, and use it as a source with the source and mask to do the
> composite into the real destination.  If making the temporary for the
> destination results in kicking out the source, mask, or destination, we
> lose.  However, if we could hold them still for a moment while we try to
> fit the temporary in, that would be nice.
> 
> However, your point is good.  In fact, what I was trying with exaGlyphs
> would have been illegal, because it would have been pinned across whole
> exaComposite()s.

And it's currently happening too with what's in CVS, I haven't tried to
track it down yet though.

I suppose to acheive your goal, you could add a simple interface to
pin/unpin a pixmap so you locally pin them when you need them there, and
make sure you "unpin" them when getting to a fallback... Though I see
your problem with allocating source possibly kicking out mask before you
had a chance to draw to it ... Not sure what is the best scenario
here... 

BTW. Talking about pixmaps ... I noticed another problem. Occasionally,
on wakeup from sleep, I end up with the cursor data overlapping the
framebuffer. I noticed that when EXA kicks pixmaps out (on LeaveVT for
example) it actually de-allocate them in addition to kicking their
content out. I'm not too fan of that, at least for pinned ones (and the
cursor should be pinned). Currently, I _think_ our cursor pixmap gets
trashed but I don't think we have a code path that re-allocates  it when
coming back. We end up coming back with curosor_offset set to 0.. If X
calls us again to ask if we support HW cursor, we'll say no and it will
silently fallback to SW, but I suspect in some cases, that doesn't
happen and we do end up manipulating a cursor at 0 overlapping the front
buffer... I'll try to track it down more precisely, but you are welcome
with any clue on that one ;)

Ben.





More information about the xorg mailing list