[PATCH] Fixes v5: Cursor barriers

Adam Jackson ajax at redhat.com
Mon Dec 6 06:41:28 PST 2010

On Mon, 2010-12-06 at 06:27 -0500, Owen Taylor wrote:
> Reviewed-by: Owen Taylor <otaylor at fishsoup.net>
> This looks good to me - it look like it is sufficient to meet the need
> of making easy-to-hit "hot corners" on a multi-head displays with a good
> amount of flexibility but without adding a lot of unmotivated
> complexity.
> Creating barriers relative to any window rather than to a root window
> isn't needed for the hot-corner case, but since the Window argument is
> needed to say *which* root window in the multi-screen case, it seems
> natural to allow any window.

The spec text could probably be a little clearer that the barrier
coordinates are in screen space not window space, I think.

> There's a slight naming iconsistency in CreateCursorBarrier vs. the
> Barrier resource, but that's OK - resources are almost all one word
> but CreateCursorBarrier is more self-documenting than CreateBarrier.

I was also trying to be unambiguous with GLX swap barriers.

> Though I do wonder, is this a Cursor barrier or a Pointer barrier? I
> always thought of the cursor being the image displayed at the mouse
> pointer.

I suppose a pointer barrier is a stronger concept, since you may not
have a cursor.  I hadn't really made any mental distinction between the
two for barriers, since barriering an invisible cursor seems like very
strange use case.

- ajax

More information about the xorg-devel mailing list