Constraining cursor to RandR crtcs
aritger at nvidia.com
Mon Apr 2 00:29:04 PDT 2007
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"
> 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
> 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.
> 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
More information about the xorg