setting evdev properties from HAL?

[Peter Hutterer]

On Sun, Jul 05, 2009 at 03:00:32PM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > On Sat, Jul 04, 2009 at 02:32:09PM +0200, Simon Thum wrote:
> >> Asbjørn Sannes wrote:
> >>> But for "Evdev Axis Calibration" I have not found anything that works ..
> >>>
> >>> Any hints and suggestions are welcome :)
> >> One could probably do a patch which adds property manipulation to
> >> config/hal, but it didn't surface yet.
> >>
> >> I remember to have heard hal can be configured to invoke scripts like
> >> yours on device add/remove. Not sure of it, though.
> >  
> > I started that once but I'm being told HAL is on its way out so I decided
> > not to finish them. If you want to pick it up - be my guest, patches below.
> > Having said that, it is questionable whether they will go upstream if you do
> > finish them. There is quite a push away from HAL and adding new HAL-only
> > functionality is not the way to go. Especially for things like this that can
> > be set at runtime.
> What I had in mind wasn't actually hal-only. AFAIK we already merge hal
> keys into config. Likely, a udev-based solution would have to offer
> something similar anyway. So if we pick up config items which e.g. start
> with "Input Property " and then modify props accordingly, that might be
> a more sustainable approach.

So, thinking about the whole problem again: the whole reason for properties
is that they are run-time configurable and not just available at server
startup. 

So - yes - we could add more logic to the server to parse the options at
device init time. We need to ensure this configuration and parsing happens
with a pure HAL configuration, a xorg.conf and libudev.
Which means we have one more API to maintain (that is possibly not even
going to be used that much). And this API has some overlap with the Options
parsing stuff from the config file. So we're left with two independent
parsing APIs, users possibly mixing both of them into their configurations,
making support quite interesting. For example, if you can set the same
option through properties and through a traditional Options flag, it comes
down to the driver implementation which one has precedence.

I think we should just encourage the development of client applications that
provide user-configurable property setting mechanisms instead.

Cheers,
  Peter