HAL FDI matched Buttons

[Timo Hoenig]

Hi,

On Mon, 2005-11-28 at 14:14 +0000, Richard Hughes wrote:

> Okay point taken, but if I enable iald, and I don't have a Sony or
> Toshiba laptop it just sits there doing nothing, right?

Why would one enable iald if the system used doesn't have an interface
iald takes care of?

You don't launch CUPS if you don't want to print with a system, do you?

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

We're all using HAL on this list, so we are all discussing about how HAL
should evolve.  No need to get sick.

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

That's where the views differ.  Still no need to get sick, really.

> > 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.
> 
> Introducing yet another layer of abstraction?

Nah, not another layer of indirection.  Just like a PM daemon it would
sit side-by-side to HAL.

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

NetworkManger, as a nice example, does not require anything of all that.

> >  Those
> > daemons will use HAL as a "configuration backing store" and the user can
> > combine them as he likes (he can even use a daemon that provides more
> > than one of those functions - e.g. powersaved which currently can do
> > suspend / resume handling, cpufreq, device power management, LCD
> > brightness).
> 
> Or we could put a little bit of code in HAL to make all this just work.

A little code?  Another couple of addon scripts forked sometime doing
something out of control of the daemon?

Lets summarize the efforts needed:

* ACPI event: easy & done.
* Toshiba HCI: polling, quite a bit of code
* IBM (NVRAM driver): polling, also more than just "a little bit of
code"
* SMBus (FSC): no experience yet

> You can disable any of the addons by simply editing the fdi files, and
> disabling them from being launched.

I don't agree.  HAL is something we all rely on.  If there are some
tweaks which are enabled or disabled depending on the distribution used
-- that's cool.

But seeing HAL x.y having seriously different functionality on different
distributions sounds ridiculous.  To both, users and application
developers.

> Richard.

   Timo