Constraining cursor to RandR crtcs

[Andy Ritger]

On Sun, 1 Apr 2007, Keith Packard wrote:

> On Sun, 2007-04-01 at 19:33 -0700, Andy Ritger wrote:
>
>> Interesting problem, though I'd like to raise the "Mechanism, not Policy"
>> warning.
>
> Yeah, noted.
>
>> Is it necessary for the X server to solve #1 (or #2) at all?  If the X
>> screen is just a rectangle of pixels, shouldn't the cursor be able to
>> move anywhere within that rectangle?
>
> That's what it does now, and it's rather confusing -- the cursor ends up
> missing in action on a regular basis.

NVIDIA's TwinView implementation suffers from the same problem --
that the cursor can be in a region of the screen that is not visible.
I don't think I've seen many user complaints from that.  I assume users
just wiggle the mouse around until it finds its way back into a visible
portion of the screen.

That's certainly not ideal, but I'd worry that imposing cursor placement
rules from the X server might introduce more/different problems than
what the rules are trying to solve.

For example, how would this interact with cases where the composite
manager distorts the X screen relative to its CRTC regions?  The
output-accessible region (what the CRTCs display) may not be the same
as the desired input-accessible region.

>> Maybe clamping cursor(s) to CRTCs should be left up to the window manager?
>> It's the window manager's job to clamp windows to the CRTCs' regions;
>> maybe the window manager should also own that responsibility for the
>> cursor(s)?
>
> I'm not sure we have the mechanisms in place to make this feasible
> though. We could specify an 'input' region for the root window that
> ensured that the cursor never left the visible part, but that doesn't
> say what to do when the visible regions are disjoint -- the core
> protocol is not very helpful here, and the existing implementation makes
> it impossible to get from one island to another.

Not necessarily an efficient solution, but the window manager *could*
watch pointer events and use XWarpPointer to warp the pointer if it
moved somewhere the window manager didn't want.

Thanks,
- Andy


> What I did was to make it work like the old Zaphod mode (as used by the
> existing Xinerama implementation); that seems to have been reasonably
> well accepted.
>
>> Also, how does your proposal handle arbitrary overlap of CRTCs?
>
> Yeah, there's no special case needed here. If the pointer is in any
> CRTC, the code doesn't warp it anywhere.
>
> Oh, and if we decide to add a pan rectangle to each crtc, we can drive
> panning from this code as well.
>
> -- 
> keith.packard at intel.com
>