[PATCH] Fixes v5: Cursor barriers
Peter Hutterer
peter.hutterer at who-t.net
Tue Dec 7 15:47:22 PST 2010
On Tue, Dec 07, 2010 at 11:45:46AM -0500, Adam Jackson wrote:
> On Tue, 2010-12-07 at 11:26 +1000, Peter Hutterer wrote:
>
> > > + Servers supporting the X Input Extension version 2.0 or higher
> > > + respect these barriers for any cursor on relative motion events.
> > > + Absolute positioning devices do not obey these barriers as there's
> > > + no benefit to target acquisition to do so.
> >
> > Is it worth making it a per-device barrier with the usual XIAllDevices,
> > XIAllMasterDevices. Though it could be interesting handling a blocked master
> > device on a non-blocked SD...
>
> I can just about imagine a use for being able to make barriers
> per-master, it'd give you a cute way of confining people to different
> outputs. Slaves don't seem that interesting (see Daniel's comment).
>
> Maybe just leave an XID slot in the request and note that values other
> than None/XIAllDevices may mean something else in a later Fixes version?
would probably have to be a CARD16 num_devices + LISTofDEVICEID. I'd say
enforce 0 as num_devices for now and return BadImplementation for anything
non-zero. 0 is XIAllDevices anyway, so that doubles nicely.
Cheers,
Peter
> > > +DestroyCursorBarrier
> > > +
> > > + barrier: BARRIER
> > > +
> > > + Destroys the named barrier.
> > > +
> > > + Errors: Barrier
> >
> > Do we need a new error here? BadValue would be sufficient, especially given
> > that the request has no other value.
>
> Traditionally, a new type means a new error. Keith?
>
> - ajax
>
More information about the xorg-devel
mailing list