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

[Simon Thum]

Peter Hutterer wrote:
> On Wed, Oct 08, 2008 at 11:05:07PM +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.

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 agree with the example being of questionable use. However, as we just
> started with the whole thing I don't think we can quite grasp what the next
> few months may bring in terms of property support. And I wouldn't be surprised
> if a use-case pops up where we need that.
I hope you don't mind me digging out some old saying from the
forfathers: 'Don't try to fix a problem you don't have'.

> One other example I came up with while writing the email: some property
> that needs handling in the DIX and one of the DDXes. This would require two
> separate handlers, the code can't be merged into one.
Well, yes. But IMO that smells too.

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

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

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

Cheers,

Simon