You are not logged in.
So I configured hal to add layouts, but xorg ignores the fdi policy.
Heres the Xorg.0.log http://dpaste.de/Zjis/
Offline
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us,ru(Winkeys),he"
(**) Option "xkb_options" "grp:switch,grp:caps_toggle,grp_led:scroll"
Doesn't look "ignored" to me.
1000
Offline
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us,ru(Winkeys),he"
(**) Option "xkb_options" "grp:switch,grp:caps_toggle,grp_led:scroll"Doesn't look "ignored" to me.
Oh, right, forgot to comment on that:
I can't switch layouts even if log shows that
Same thing happens if I try manually to add layouts through KDE settings. The layout tray icon shows up but even switching through that doesn't affect xorg.
Last edited by faulty (2009-09-18 16:34:44)
Offline
In Keyboard layout in KDE, choose "Evdev managed keyboard" and then configure the layout switching in the other tabs.
Offline
In Keyboard layout in KDE, choose "Evdev managed keyboard" and then configure the layout switching in the other tabs.
Thats the problem, it doesn't work. I mean I can configure through there, but it doesnt affect xorg.
Last edited by faulty (2009-09-18 18:44:51)
Offline
This is what my 10-keymap.fdi looks like http://dpaste.de/UZ3K/
Trying to manually run hal-setup-keymap gives error "hal-setup-keymap: Failed to get UDI"
Offline
And lshal http://dpaste.de/6I0Z/
...
Offline
bump
Offline
Exactly the same behavior I can observe in my box. I cannot switch layout in openbox WM.
As a temporary solution I propose the following:
1. log into Gnome session
2. set your favorite keyboard layouts
3. logout and login to your openbox/fluxbox/... session
4. open terminal and run gnome-settings-daemon
It takes settings defined previously in Gnome.
Offline
Same problem here. In all desktop environments keyboard layout settings in HAL's fdi-files stopped working. Setxkbmap works as a workaround, but it's a joke that every update since xorg 1.5 the user has to google for new workarounds.
Trying starting hal-setup-keymap results also in: "hal-setup-keymap: Failed to get UDI".
Last edited by lynucs (2009-10-14 06:24:19)
Pinky, are you pondering what I'm pondering?
Offline
Same thing happens if I try manually to add layouts through KDE settings. The layout tray icon shows up but even switching through that doesn't affect xorg.
Same problem in a fresh install on an Aspire One with stock kernel.
Offline
Okay, I found some better workaround than freaking around with setxkbmap for people who use gnome-settings-daemon in their sessions.
In gnome-keyboard-properties go to layouts and click on reset to defaults. Your layouts from .fdi will appear in the layout list. However, if you're using Capslock to switch between the layouts, you will need to set it manually (click "layout settings"). Alt+Shift is recognized automagically. Not sure why it doesn't with Capslock that way.
all environments using gnome-settings-daemon will use your ol'e good layouts defined in .fdi after that. Hope that this will save someon some minutes of life.
EDIT: okay forget it.. you need to do the thing described above each time you login what a pain
Last edited by lynucs (2009-10-14 09:19:47)
Pinky, are you pondering what I'm pondering?
Offline
I have this problem since the newest updates with stock kernel. Started with this new 2.6.31 kernel
Offline
Well, but what to do people who do not use Gnome at all?
Offline
knedlyk, you could port all your settings to setxkbmap.
is there anyway one can automate resetting the keyboard layouts to defaults in gnome-keyboard-properties without gui? maybe some crazy gnome hack over dbus-launch or whatever gnome devs are smoking? so that i could add it to my session script maybe.
Pinky, are you pondering what I'm pondering?
Offline
I found a way to automate the keyboard layout settings with gconftool-2.
I've put that 3 lines into my session script:
exec gconftool-2 --type list --set /desktop/gnome/peripherals/keyboard/kbd/layouts --list-type string "[de,ru]" &
exec gconftool-2 --type list --set /desktop/gnome/peripherals/keyboard/kbd/options --list-type string "[grp_led grp_led:scroll,grp grp:alt_shift_toggle]" &
exec gconftool-2 --type string --set /desktop/gnome/peripherals/keyboard/model "pc105" &
It works, however i can't set up variants for my layouts. Actually the first line's list string should be sth like "[de nodeadkeys, ru winkeys]" for me. But the character between the language and variant shouldn't be just a space, but some special split-character which i don't know how to reproduce.
If you're not sure which layouts and keyboard model you need, go to gnome-keyboard-properties and create _new_ keyboard layouts there. this will affect the gconf which you can watch with gconf-editor (you might need to install it). just open the gconf-editor and got to the path
/desktop/gnome/peripherals/keyboard/kbd/
.
Pretty dirty workaround, works me for now however. If someone knows how to reproduce those special characters, please let me know.
Pinky, are you pondering what I'm pondering?
Offline
My hal settings are respected by xorg (as they have always been), keyboard switching works. I don't use any login manager, nor any fancy DE (just xmonad or openbox). Here's my /etc/hal/fdi/policy/10-keymap.fdi:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keymap">
<append key="info.callouts.add" type="strlist">hal-setup-keymap</append>
</match>
<match key="info.capabilities" contains="input.keys">
<merge key="input.xkb.rules" type="string">xorg</merge>
<!-- If we're using Linux, we use evdev by default (falling back to
keyboard otherwise). -->
<merge key="input.xkb.model" type="string">keyboard</merge>
<match key="/org/freedesktop/Hal/devices/computer:system.kernel.name"
string="Linux">
<merge key="input.xkb.model" type="string">evdev</merge>
</match>
<merge key="input.xkb.layout" type="string">us,cz,de</merge>
<merge key="input.xkb.variant" type="string">altgr-intl,qwerty,</merge>
<merge key="input.xkb.options" type="string">grp:menu_toggle,grp_led:scroll</merge>
</match>
</device>
</deviceinfo>
PS. By the way, I think (although I'm not sure at all), that if you use gnome or kde, you don't have to mess around with hal policies at all, just set the switching in the DE itself. If you try to do both, they can sort of conflict each other.
Last edited by bender02 (2009-10-14 11:39:03)
Offline
bender, I guess it's not like HAL's config is never read. I think the problem is that gdm and/or gnome-setting-daemon do mess something up. I guess gnome is trying to overwrite hal's config but doesn't manage to save the changes. Thus resulting in an empty US keyboard layout on each relogin.
Pinky, are you pondering what I'm pondering?
Offline
bender, I guess it's not like HAL's config is never read. I think the problem is that gdm and/or gnome-setting-daemon do mess something up. I guess gnome is trying to overwrite hal's config but doesn't manage to save the changes. Thus resulting in an empty US keyboard layout on each relogin.
If gnome is really trying to interact with hal, then the problem might be with some permissions - now that gnome is using various *kit's, I'm not sure they work as they are supposed to (I had a problem with it a while ago).
I have another computer at home where I also have gnome installed, so I can check how does it work there when I get home.
My previous post was more for the people who don't use gnome at all (ie. knedlyk).
Offline
Well, I tried now in gnome as well, and it works fine, as expected. I certainly never messed up with gnome keyboard properties - so you guys could try creating a new user and trying gnome with him/her.
Offline
thank you for report, will try out.
just a question, you have tested it with gnome 2.28, right?
Pinky, are you pondering what I'm pondering?
Offline
thank you for report, will try out.
just a question, you have tested it with gnome 2.28, right?
Yes, fully updated arch (with testing, community-testing, but not with gnome-unstable).
Offline