| Summary: | [x11-overlay] x11-base/xorg-server-1.6.0 ignores multiple keyboard layouts configured in hal | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexey Charkov <alchark> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
The fdi file used
The X server log |
||
|
Description
Alexey Charkov
2009-03-29 22:48:36 UTC
Created attachment 186685 [details]
The fdi file used
The fdi file specifies 'us,ru' as a keyboard layout. I have also tried the other syntax (input.x11_options.XkbLayout) with no success.
Created attachment 186689 [details]
The X server log
All of the options specified seem to be merged, except for input.xkb.rules, which remains 'evdev' no matter what I specify in the fdi file. The layout switching does not work, though.
Other than the fact, you're using old option style, which is a minor thing, that wouldn't affect anything, there's a major flaw of that file. For it to be a valid fdi file, tag opened within <deviceinfo> should be <device>. Only inside that that you put options. So I suspect this is invalid. (In reply to comment #3) > Other than the fact, you're using old option style, > which is a minor thing, that wouldn't affect anything, there's > a major flaw of that file. > For it to be a valid fdi file, tag opened within <deviceinfo> > should be <device>. Only inside that that you put options. > > So I suspect this is invalid. > That's true, I have never even noticed that it's somewhat incomplete. However, adding the <device> tag does not change anything, unfortunately. As for the new-style option syntax, I tried it as well (as I mentioned in comment #1), but then I get even funnier results, with the old-style (from Gentoo-shipped fdi's) and new-style (from my custom one) options being added side by side rather than merged. My current lshal output is like this: udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' info.addons.singleton = {'hald-addon-input'} (string list) info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) info.product = 'AT Translated Set 2 keyboard' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' (string) input.device = '/dev/input/event2' (string) input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) input.product = 'AT Translated Set 2 keyboard' (string) input.x11_driver = 'evdev' (string) input.xkb.layout = 'us,ru' (string) input.xkb.model = 'evdev' (string) input.xkb.options = 'grp:alt_shift_toggle' (string) input.xkb.rules = 'xorg' (string) input.xkb.variant = ',winkeys' (string) linux.device_file = '/dev/input/event2' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/class/input/input2/event2' (string) With the new-style options I get this: udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' info.addons.singleton = {'hald-addon-input'} (string list) info.capabilities = {'input', 'input.keyboard', 'input.keypad', 'input.keys', 'button'} (string list) info.category = 'input' (string) info.parent = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) info.product = 'AT Translated Set 2 keyboard' (string) info.subsystem = 'input' (string) info.udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input' (string) input.device = '/dev/input/event2' (string) input.originating_device = '/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port' (string) input.product = 'AT Translated Set 2 keyboard' (string) input.x11_driver = 'evdev' (string) input.x11_options.XkbLayout = 'us,ru' (string) input.x11_options.XkbOptions = 'grp:alt_shift_toggle' (string) input.x11_options.XkbRules = 'xorg' (string) input.x11_options.XkbVariant = ',winkeys' (string) input.xkb.layout = 'us' (string) input.xkb.model = 'evdev' (string) input.xkb.rules = 'base' (string) input.xkb.variant = '' (string) linux.device_file = '/dev/input/event2' (string) linux.hotplug_type = 2 (0x2) (int) linux.subsystem = 'input' (string) linux.sysfs_path = '/sys/class/input/input2/event2' (string) Isn't that lovely? :-D I am using sys-apps/hal-0.5.12_rc1 and app-misc/hal-info-20090309. Try with rules = 'evdev'. And new style overrides the old. Well, yes, it did actually override the old-style entries at X startup despite of lshal showing both. As for setting rules to evdev, nothing changes (just checked to be sure). As I've mentioned in comment #2, it remains at 'evdev' in X logs no matter what my settings are. Another extremely funny issue is that after I use `setxkbmap -layout us,ru` from a terminal, I get the Xfce4 'Run command' window appearing at Alt+F2 instead of KRunner (I am in a KDE4 session with no Xfce4 programs running). With KDE, there's also that "evdev managed" keyboard stuff, mentioned on the forums in the sticky. (In reply to comment #8) > With KDE, there's also that "evdev managed" keyboard stuff, > mentioned on the forums in the sticky. > Thanks, but it's been a long time since I've switched to Xorg/HAL xkb configuration rather that DE-specific tricks. Otherwise I would not have had this problem, as `setxkbmap` actually DOES set the correct layout (and that is what the KDE applet uses internally). And, as you might have noticed, my XkbModel is set to 'evdev'. Is this xorg-server from x11-overlay? By now, I probably forgot you're talking about 1.6.0 (even if I noticed it in the first place). But my point still stands - I've been using xorg-server 1.6.0 from x11 overlay for about a month and it works for me. (In reply to comment #10) > Is this xorg-server from x11-overlay? > Yes, it is. @Rafał: Are you using multiple layouts? If so, could you please post your fdi here? Well, no, I'm not using multiple layouts, I tested that manually.
As root, I used 'hal-set-property' to set those hal keys to
given values (multi layout and switch), then without leaving
my current session, I switched to a different vt,
ran 'startx -- :1', opened a terminal and simply tried pressing
a few keys - layout switching did work.
My fdi file (that's posted many times on the forums) looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keys">
<merge key="input.x11_options.XkbRules" type="string">evdev</merge>
<merge key="input.x11_options.XkbModel" type="string">evdev</merge>
<merge key="input.x11_options.XkbLayout" type="string">pl</merge>
<merge key="input.x11_options.XkbOptions" type="string">altwin:menu</merge>
</match>
</device>
</deviceinfo>
During the test, first I changed just XkbLayout and XkbOptions,
then I added XkbVariant, both times it worked.
and input.keyboard is probably even better than input.keys, but that's irrelevant as it seems it's applied anyway. But my problem is exactly in "multiple layouts", as the bug description reads. The first layout ('us' in my case) works well, and so do the options and variant fields.
(In reply to comment #15) > But my problem is exactly in "multiple layouts", as the bug description reads. > The first layout ('us' in my case) works well, and so do the options and > variant fields. > ...your point ? Once the settings hit hald, it should not matter. During the test, new settings affected only the new session, but I have ps2 keyboard/mouse, with usb keyboard it's probably enough to disconnect and reconnect it after changing hal settings. I was setting XkbLayout to 'pl,ru' and XkbOptions to 'altwin:menu,grp:alt_shift_toggle' and it did work. For a start, try doing a similar test, though your hal settings suggest it should already work. What's your xkeyboard-config' version ? It should not, but unfortunately it does. As you can see, in my case it not only hits hald, but even goes into xorg (as the log says, at least). But at some point up there it gets discarded, so when I check it with setxkbmap it's not in. (In reply to comment #16) > What's your xkeyboard-config' version ? > x11-misc/xkeyboard-config-1.5 Now, that I've read your log, I've got a silly idea: try adding a rule that removes evdev driver for "Asus Laptop extra buttons"; alternatively, try using keys instead of keyboard - perhaps that extra device is somehow interfering with your keyboard. I'm using input.keyboard for exactly this reason: otherwise other stuff besides the actual keyboard matches as well, which I do not want. BTW, the same thing occurs with xorg-server-9999. I'll probably try to go through git bisect, but that's for a later moment. It starts to get even more exciting, as now I experience the same problem with xorg-server-1.5.3-r5! Did the input subsystem change in any way with kernel 2.6.29? This is what I use now (from gentoo-sources). Unfortunately, checking with 2.6.28 is a bit problematic, as I have btrfs at /home. Perhaps you should try something less trivial: a rule, that first removes all xkb keys (both old and new) from devices matching input.keys and then adds new style keys to the device matching input.keyboard. Resolved by nuking the KDE4 config in ~/.kde4 and having it recreated from scratch (i.e. nothing to do with either of xorg, hal or kernel). Must have been some glitch upon ext4->btrfs conversion of /home. Thanks for the follow up, that was indeed tricky to find. Cheers |
