Constraining cursor to RandR crtcs

[Keith Packard]

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.

> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20070401/5c2e4169/attachment.pgp>