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 <[email protected]>
The RANDR CRTC confine bit is very much worth landing on its own even if
barriers miss 1.10.0.
- ajax
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
