[Patch 0/8] Pointer barriers

[Adam Jackson]

On 2/21/11 10:51 PM, Peter Hutterer wrote:

> Notes on the PB support in general:
> - having a pointer barrier specify which direction it doesn't work is very
>    confusing. Both from the client-side and whithin the server it was
>    counter-intuitive.
>
>    I'd prefer an interface like this
>       barrier = XFixesCreatePointerBarrier(dpy, DefaultRootWindow(dpy),
>                                              100, 0, 100, 200,
>                                              PointerBarrierPositiveX);
>    to block movement from left to right. The above call would currently block
>    all directions but let left-to-right movement through.

I don't have any objection to this, I'll need to edit the fixesproto 
docs before releasing 5.0 but that's trivial.

> - The barrier itself is an "elevated" barrier, i.e. you cannot get onto the
>    pixel the barrier represents (from the blocking directions). This is
>    necessary to avoid trapped cursors when the barrier blocks both
>    directions. This needs to be either added to the protocol or I need to
>    spend the time to implement the exact protocol spec (top/left edge of the
>    pixel). The latter would result in x = barrier or x = barrier + 1,
>    depending on where you're coming from.

The barrier is intended to be on the edges between the pixels.  I'll try 
to hammer this bit out.

For the series through #6, where applicable:

Reviewed-by: Adam Jackson <ajax at redhat.com>

The RANDR CRTC confine bit is very much worth landing on its own even if 
barriers miss 1.10.0.

- ajax