Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
On Wed, 2009-04-15 at 10:25 +0200, Bjørn Mork wrote:
> 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.
please stop the FUD.
> 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?
>
we don't ignore existing keymap configuration, and you get the same
layout after the upgrade as was configured in xorg.conf.
> 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.
that's fine, you don't have to.
> 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.
no, it didn't. you're just spreading nonsense.
Cheers,
Julien
Reply to: