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