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

[Simon Thum]

Peter Hutterer wrote:
> On Wed, Oct 08, 2008 at 09:12:44AM +0200, Simon Thum wrote:
>> Peter Hutterer wrote:
>>> Axis range changes are one example I can think of. The driver needs to update
>>> it for axis inversion, the server for scaling.
>> Hmm - that essentially forbids moving inversion into the server (which
>> could be done), because we'd never know if the driver wouldn't also do
>> it.
> 
> Not necessarily. Once the server has support for X, we can just remove it from
> the driver and say that you need at least server Y with this driver version.
> Or, once the server has a "XYZ" property, you can just make e.g. "Evdev XYZ"
> an alias for "XYZ", keeping backwards compat with clients.
We're arguing in different directions here. My point is, that this all
is superfluous if you avoid double-defined props in the first place.
Enforcing that somewhat helps to resist the temptation :)

The question is whether one needs it. Your last major change was all
about reducing complexity. You could go further in that direction by
adopting only-one-non-ignoring-handler - at the expense of not
supporting some (IMO questionable) useages.

>> Yes, but the actual propery value may not be what reflects the state in
>> the server, e.g. as in the 'Enabled' prop. So there is a difference.
> 
> if a property does not reflect the state as it is in the server, I'd consider
> this a bug. Regarding the example: the "enabled" prop actually calls
> Enable/DisableDevice, so it should always be the server state.
Sure, we can reasonably assume that. The mere point is the the state is
not determined by the prop, just reflected (e.g. someone else could call
EnableDevice, like VTSwitch or power mgmt). This small difference is
what I'd say makes for a difference in return codes. (Plus, pretty
unrelated: your only chance of knowing is having a getter).

> if (!checkonly) { // this line got added
>   foo();
> }
> 
> I can't imagine it being much simpler than that.
Overkill was mainly referring to the possibilities it opens (n-times
handled props) and the associated complexity, which would inevitably
affect property users (like you and me).

So, I pushed that far enough - it is your decision, and I can live with
whatever you end up with.

> This way git-blame points at you if it breaks :)
Great :)
> I think I just ammended from the rounding patch you sent, never bothered to
> change the author.
I sent a patch? Ooops.

Cheers,

Simon