[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: