[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