Constraining cursor to RandR crtcs
Keith Packard
keithp at keithp.com
Mon Apr 2 10:21:06 PDT 2007
On Mon, 2007-04-02 at 10:49 +0100, Colin Guthrie wrote:
> I had the following layout
> +---------------------------------+---------------------------------+
> | | |
> | | |
> | | |
> | | |
> | | |
> | | |
> | 3 | 4 |
> +---------------------------------+ |
> | |
> | |
> 2 | 1 |
> +---------------------------------+
>
>
> If I moved the mouse from point 1 to point 2, the cursor would be hidden
> from me. I did indeed just wiggle it until I could see it again.
That's what I'm trying to avoid.
>
> If the mouse were to warp from point 1 to point 3 as I moved it towards
> point 2, then this would have been nice I think. However, if I had just
> moved the mouse one tiny pixel into the dead space when I didn't mean
> to, (e.g. some app on the right screen had a button at it's bottom left
> corner) and subsequently moved it back to the right screen only to find
> my cursor now in point 4, I would have found this quite annoying.
I've just discovered this myself, so it looks like my existing
implementation isn't ideal.
> Unless moving from 1 -> 2 (warp) 3 -> back towards 4 quickly -> (unwarp)
> 1 happened (e.g. with some sort of fuzziness to determine when to
> "unwarp" then I could see it getting quite annoying.
The other alternative is to just confine the cursor to the visible
region in this case -- make it 'impossible' to move from 1 to 2, and
just block the cursor at 1. That seems better to me, and makes it much
more like the existing root window where you simply cannot move outside
of the window at all.
What would remain with this solution is a way to get between disjoint
areas of the screen -- two CRTCs separated by a blank space would become
effectively isolated.
> So while I like the principle of the auto-warp, I think it needs to be
> done flexibly to allow user control (e.g. turn it off) and also to have
> some degree of intelligence (with configurable thresholds etc.
Yeah, it looks like there isn't an obvious correct solution that works
in all cases.
--
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/20070402/e710c5f7/attachment.pgp>
More information about the xorg
mailing list