HAL FDI matched Buttons

[David Zeuthen]

Hey,

On Mon, 2005-11-28 at 14:14 +0000, Richard Hughes wrote:
> > I cannot understand why you want to transform HAL to a
> > do-everything-big-unmaintainable ACME daemon. There are perfectly
> > working solutions for all your needs, so there is no need to reinvent
> > the wheel over and over again.

So I don't really see how having two daemons makes anything easier. In
my view it only makes things harder because the interfaces are
different, the release schedules are different, the ABI guarantees are
different and so forth. There's also a host of practical issues with it
such as lifecycle management.

I suggest looking at the archives and why we ended up with the add-on
concept. It was *specifically* designed to make it trivial to write
small add-on daemons for this.

There's also the ISV angle which people keep forgetting.

> Well, this is opensource software, and I figured that just because some
> other program can do something shouldn't stop a new solution if it is
> technically superior. I'm getting sick of this "but daemon x can already
> do this" as an argument against new functionality. I'm not asking you to
> help me, or forcing you to use it. I'm saying this functionality helps
> me, and I think it's useful being in HAL.

And so do I.

> > > Yes, just like people contribute fdi files to get their music player
> > > detected correctly, they could contribute a keymapping. Drop one file
> > > into the fdi folder and it would just work (unless trucked up interface
> > > like toshiba or sony, which would need a bit of glue code..)
> > 
> > My idea would be to use HAL as a "configuration store" where a hotkey
> > daemon (regardless if it is iald or something else) can fetch its
> > instructions on how to interpret the hardware, but leave it to the
> > particular daemon to interpret them.

And that daemon should just be a simple hal addon and ideally be
distributed with the HAL sources to keep it easy for distributors and
LFS/Gentoo enthusiasts to get this in a working state so users don't
have to read HOWTO's or ask questions on IRC how this stuff works.

> 
> > This way, users can choose _which_ hotkey daemon, _which_
> > powermanagement daemon, _which_ cpufreq daemon etc. to use.

Oh, yea, like we _need_ choices for boring non-user visible software...

> This would be a disaster for distros. Really, this stuff is supposed to
> "just work" and the user shouldn't have to do lots of research, install
> a random daemon, configure it, and work out how to interact with it.

Strong agreement.

> Or we could put a little bit of code in HAL to make all this just work.

Go for it.

Cheers,
David