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