[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

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.


Reply to: