[PATCH] Xi: check all handlers before applying property changes.

Peter Hutterer peter.hutterer at who-t.net
Wed Oct 8 18:45:30 PDT 2008

On Thu, Oct 09, 2008 at 03:20:36AM +0200, Simon Thum wrote:
> > So your point is to never have properties in the driver that could be in the
> > server? This may be tough, as drivers have a quicker turnover time, and
> > features can get added easier.
> Well, against double-handling a prop in general. Uh, I didn't even rant
> about order dependencies which may sneak in.

doh. yes, those would be an issue.
> Alternative (assuming only-one-handler): Should anyone 'capture' an
> existing prop we could add some controlled pass-through behaviour, e.g.
> by starting the handler list from the current (or any specified) handler on.

I'm not sure I understand what you mean here.
> > If the state is changed through changing the property - easy. Otherwise, the
> > code must ensure that XIChangeDeviceProperty() is called.
> Then you really should be looking at VTSwitch or power mgmt.
> That part is clear, but it's so easy to circumvent unexpectedly. But I
> don't know anything reliable either.

ok, I'll check that and make sure it isn't broken.

> > which case we get an error value. And I hope that any property is reasonably
> > documented so that one knows what values are legit :)
> Do you intend to have some point to collect related info? E.g. wiki? It
> could help a lot to easily see what types there are, how others did etc.

right now, the properties are documented in the header files that define their
names. They should eventually be added to the man pages, once they settle down
a bit.
> > Sure, it may get complicated if we have 10 handlers for each property. But at
> > that point we should got back to the drawing board and see what we have done
> > wrong. Because I don't think that merging the code from 10 different handlers
> > into one handler would be any more straightforward.
> Sorry, but I can't help regarding that as an argument against multiple
> handlers per prop - but anyway.

So based on the current implementation (the one that is in master), what's
your concrete proposal then? Just leave it an beat up anyone trying to
double-handle a property? Not that I would be opposed to that, but it's likely
going to be me who's going to be beaten up :)

More information about the xorg mailing list