Re: RFA: acpi-support -- glue layer for translating laptop buttons, plus legacy suspend support
Julien Cristau <jcristau@debian.org> writes:
> 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.
Sorry. You're right. That was uncalled for. The introduction of hal
has caused a few new problems for me, but I don't know anything about
most users.
My list of hal related regressions are
a) laptop keys remapped or disappearing (might be caused by the driver -
I don't know)
b) unwanted auto-mounting
c) the keyboard problem described below
>> 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.
OK. I did not. But I guess that's something that's changed with recent
console-setup changes? Some testing now reveals that you're right: I
now get a Norwegian keyboard layout for every keyboard like device no
matter what I write in xorg.conf.
That's still confusing to me. I did manage to locate the settings in
/etc/default/console-setup. But it's still unclear how to handle
multiple input devices using this facility.
Not that it matters much, but I find it a bit strange that the
"ThinkPad Extra Buttons" and "Video Bus" devices are configured as 105
keys keyboards with Norwegian layout:
(**) ThinkPad Extra Buttons: always reports core events
(**) ThinkPad Extra Buttons: Device: "/dev/input/event8"
(II) ThinkPad Extra Buttons: Found keys
(II) ThinkPad Extra Buttons: Configuring as keyboard
(II) XINPUT: Adding extended input device "ThinkPad Extra Buttons" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: "/dev/input/event1"
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"
(II) config/hal: Adding input device Video Bus
(**) Video Bus: always reports core events
(**) Video Bus: Device: "/dev/input/event5"
(II) Video Bus: Found keys
(II) Video Bus: Configuring as keyboard
(II) XINPUT: Adding extended input device "Video Bus" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "no"
(**) Option "xkb_options" "lv3:ralt_switch"
>> 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.
You're right. This seems to be taken care of by console-setup now. It
was not when I created this file (which I did not do just for fun,
although writing XML config files is my idea of a fun night :-)
>> 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.
I think we might have different interpretations of "work".
Suddenly ignoring xorg.conf changes in favour of a new config file
without any clear (to me at least) indication how to restore previous
behaviour is
1) unexpected
2) broken
IMHO. You are of course free to have a different opinion. I just
wanted to register mine.
Bjørn
Reply to: