Julien Cristau <jcris...@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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org