New version of xfixes with client side cursor support

David Reveman davidr at
Wed Feb 21 01:44:30 PST 2007

On Tue, 2007-02-20 at 19:59 -0800, Keith Packard wrote:
> On Tue, 2007-02-20 at 10:50 +0100, David Reveman wrote:
> > I think we look at this in two different ways. The request name should
> > probably have been NameCursorImagePixmap as it was never intended to
> > name the pixmap for a specific cursor but rather the image currently
> > used as cursor for the core pointer so there's no right or wrong cursor,
> > it's just that image. But I understand that this is not good enough.
> When you're going to paint the cursor at a specific location, there is a
> right and wrong cursor; you need to get the cursor for the target
> location (in both space and time), not some other cursor. I think we
> need stable cursor names here, or at least stable for some length of
> time. One option is to have the server allocate pixmap IDs itself and
> send those to clients instead of 'serial numbers'. 

Yes, I though about doing this.

> The only issue there is deallocating them, but I suggest that we can
> free them when the client to which they were sent was closed down (or
> when it explicitly freed them itself). Of course, the server would
> re-use the same pixmap ID when that was easy, so the client wouldn't
> have to constantly free pixmaps.

Sounds good enough.

> For ARGB cursors, this just means having another name for the existing
> cursor image, which is nearly free, taking only a resource manager
> bucket to point at the pixmap. For two-color cursors, we have to create
> an ARGB cursor image and attach that to the resource.
> > However, having it actually name a specific cursor instead should be
> > good enough. Even if it's just naming the current cursor as the cursor
> > serial could be used to make sure that we're not drawing the wrong
> > cursor at the wrong spot.
> One of the goals of a composited desktop is that we always present a
> 'correct' image, containing snapshots of every application in a
> consistent state and with a correct cursor displayed in the right
> place. 

Yep, I understand the importance of this.

> For performance reasons, we don't ever want a round-trip, so we need to
> find mechanisms (like Composite) which make the whole redisplay possible
> without needing data in the client.

Sure, it would be nice to never have to do a round trip. A round-trip
just the first time the client see a new cursor isn't too bad though.

> >     image = XFixesGetCursorImage (dpy);
> If you're getting the image, you've just done a round trip, and you
> might as well just follow this with XCreatePixmap and XPutImage, it's
> the same performance as having the server copy the data itself with a
> new request.

I just realized that each frame of an animated cursors got a different
serial number and I didn't think this was the case. My intentions were
to at least save some resources for animated cursors but if we bind
cursors to textures based on serial numbers and each frame got a
different serial number, that's of course useless.

So yes, XFixesGetCursorImage and then glTexImage2D or whatever is just
as good. You'll end up with lots of textures for all cursors, especially
for animated cursors but maybe we can live with that for now.

I'm probably OK with doing a round-trip each time the compositing
manager see a new cursor image. I can add the server allocate pixmap IDs
for cursors if you like that, though.

> > I don't think there's any way to know when a cursor serial no longer
> > exist but simply just keeping the last 20 or so used cursors bound
> > should be good enough.
> We could tell the client when a cursor is no longer interesting, and it
> could free the appropriate pixmap at that point.

Is adding another cursor event to xfixes the best way to do that?

I've attached patches that only include the addition of a
DisplayCursorPosition event that can be used to properly track the
cursor position. I couldn't find a better solution than having
CheckMotion in dix/events.c call a FixesCheckMotion function directly.

Let me know what you think about these patches and whether you would
want the "cursor pixmap ID" and "cursor no longer interesting" additions
to go in before we bump the version of xfixes or if the CursorPosition
event is enough for now.


- David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixesproto-version-4-to-5.diff
Type: text/x-patch
Size: 1316 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libXfixes-version-4-to-5.diff
Type: text/x-patch
Size: 1550 bytes
Desc: not available
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xserver-xfixes-5.diff
Type: text/x-patch
Size: 4848 bytes
Desc: not available
URL: <>

More information about the xorg mailing list