Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau <jcristau@debian.org> writes:
> On Sun, 2009-04-12 at 14:04 +0200, Michael Meskes wrote:
>> On Mon, Apr 06, 2009 at 09:55:39PM +0200, Michael Biebl wrote:
>> > As (co-)maintainer of pm-utils and hal, I'd prefer if we could work towards
>> > standardizing on one power management stack in Debian (and not install 3 by
>> > default [1]), i.e. I'd support in phasing out acpi-support and would gladly
>> > accept patches for hal and pm-utils which add (if there are) any missing bits
>> > from acpi-support.
>>
>> Not sure whether most users agree after reading #515214.
>
> 515214 isn't most users. most users just want things to work.
False. All users want all things to work. The "just" is nice to have,
but not important. It's infinitely better to have to configure things
than not being able to.
But I think you're on to the problem: It's true that hal makes most
things work. The rest can't be made to work if you use hal. Or at
least require you to configure a new, non-intuitive, complex system.
#515214 is about the rest, the way I read it.
Well, you can always argue that the rest can be fixed. Provide patches
etc. But the point is that hal implies a regression for many (most?)
users. It provides no new (visible) funcionality, but adds complexity
and lots of bugs by making auto-configuration override previous local
configuration. That's got to be wrong.
hal breaks existing working configurations without warnings. The simple
test case is using a non-US keyboard properly configured as such in
xorg.conf. Introduce evdev/hal and watch users get frustrated. The
problem of course: keyboard layout cannot be auto-configured. But why
ignore existing configuration?
I still haven't got a clue how to really fix this, but have resorted to
this for now:
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keyboard">
<merge key="input.xkb.model" type="string">pc105</merge>
<merge key="input.xkb.layout" type="string">no</merge>
</match>
</device>
</deviceinfo>
IMHO, this is an ugly hack. I never wanted to configure hal. I wanted
to configure X. In fact, I already had a working X configuration so I
didn't expect to configure anything at all...
Yes, I expected things to "just work", given that it did prior to using
evdev/hal. hal broke that expectation.
The same goes for the suspend/resume support. I have an existing
working configuration, using acpi-support and pm-utils. There is
absolutely no upside to me moving this to hal and some power-daemon. It
just obfuscates the configuration, making GUI configuration utilities
mandatory and leaving me reading c++ bloat instead of some simple shell
script to find out why things didn't work as expected.
Just my .02 € as an ordinary user.
Bjørn
Reply to: