[SOLVED] altgr or others not working+us keyboard default+any wm/de

frp · 2009-03-29 02:24:12

Hi,
I'm bringing both the problem and the solution for a little annoying problem I've been having, I've searched here on foruns and wiki, google, etc, but the solution presented in each case would just simply not work, so, if you have the same problem as me, and this solution doesn't work, you might wanna give a look at wiki and some previous posts, like:
[SOLVED] xmodmap, alt-gr + j or n
alt gr rarely working under X [solved]
[solved] some keyboard keys dont work properly
strange xmodmap behaviour [kind of solved]
AltGr and XKB group switching
[Solved] Loadkeys fails with syntax error
[SOLVED] How to disable Alt-Shift as Sticky Alt Gr?
[SOLVED] Setting up the Compose Key in Fluxbox
[Solved] Problem with "alt" keys
and many more...

Problem: (all related to WM, console works perfectly)
1. US keyboard by default
2. Alt-Gr not functioning

How to recreate: (or how it always happened to me)
not using hal/hotplugging make sure you have the following on your xorg.conf:

Section "ServerFlags"
Option "AutoAddDevices" "False"
EndSection

and just incase, you might wanna add this to the same section:

Option "AllowMouseOpenFail" "true"

xorg.conf configured with minimum Options "XkbRules" "xorg" // "XkbLayout" "pt" // "XkbModel" "pc105"
using firefox merely as example, since it has nothing to do with firefox, and assuming you have no xmodmap or loadkeys file on home dir. don't use the xterm or other term to test, they tend to grab xorg
1.With no login manager running/installed, login through console, and run startx/xinit.
2.Don't press any key, and with the mouse open firefox.
3.Inside firefox write a character you know it's not on the same spot as the US keyboard.
for ex. I used '-' which brings '/' , or '@' which brings '2' ('@' uses AltGr+2)

That's it. If you close and open firefox again, you'll see your keyboard is responding fine.
So, the problem was in the gap between console/startx and the first key pressed, meaning that my keyboard would only be recognized as PT (my keyboard layout) after I pressed any key.
To confirm that, I logged out, and login again, and before going with the mouse to open firefox, I simply pressed a key, then opened firefox, and it was all good, no US characters.

Solution:
on gnome:
1. press a key to make sure your keyboard gets detected correctly.
2. use gconftool2 tool, it's on a shortcut on applications menu.

gconftool2->desktop->gnome->peripherals->keyboard->kbd->options (edit and put 'xorg')

just that should work, but if just 'xorg' ain't enough or if you just want to put more options, you can check how your keyboard is being recognized and fill with the same, run:

$ xprop -root | grep XKB

in gnome is as simple as this. check for more details at Tidbits gconf-and-keyboard-warnings

on openbox and very likely any other WM: openbox standalone, uninstalled gnome ahwile ago
note: if you don't need AltGr combinations, or you don't use Group2 switches of a key, a simple xmodmap works as far as it goes for the layout
1.edit xorg.conf and on keyboard section, put as follows:

...
Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"
EndSection
...

2.edit your .xinitrc and put these two lines: (change 'pt' with the layout for your country/keyboard)

...
setxkbmap -layout pt & # shout at WM to use this layout _since_the_beginning_
(sleep 1 && xset r) & # put repeat on after new keyboard layout loaded
...

I had to add the repeat line, cause without it, the keyboard simply wouldn't repeat the key if you keep it pressed, and it had to be with the 'sleep' thingie behind it, or it wouldn't load. If you use openbox's 'autostart.sh' to load stuff that needs to be loaded after openbox starts and want it organized, you might wanna put the '(sleep 1 && xset r) &' in there.
After checking it's working and if you feel you need more stuff, check '$ man setxkbmap' for more options.

And that's it, problem solved

xev is your friend, nice to grab keycodes and stuff, or clicks from mouse to check which button is which
What I tried and didn't work for me:
10-keymap.fdi - changed it just in case, but no good.
locales - changed both LOCALE on rc.conf and locales.gen to PT files, and didn't work.
xorg.conf - tried all those usual options like 'grp:toggle'; 'nodeadkeys', 'compose:ralt', 'grp:switch', etc., took of XkbRules and Xkbmodel, leaving only the XkbLayout, still no good.
xkbcomp - tried some options
xmodmap - made the xmodmap file of my keyboard. It started great, with PT layout instead of US one, but no AltGr key.
xmodmap keysym - tried diferent keysym combinations, like Alt_R, Meta_R, ISO_Level3_Shift, Multi_keys, Mode_switch, etc. It was funny, I managed to grab some nice AltGr combinations, but not the ones I needed.
/usr/share/X11/xkb - messed around with the files here. First focused on the keyboard layout file ('pt' in my case) and the ones he was calling. After some tries, messed with others to try a "manual" making of the keyboard, but didn't work either. (after none worked, copied back the backup of original files)

This following message was always appearing, not in Xorg.0.log or .xsession-errors, always on console output, you see it if you logout or if you ctrl+alt+F1 (assuming you loaded xinit/startx from vc/1):

The XKEYBOARD Keymap compiler (xkbcomp) reports:
>Warning: Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols:
Ignoring extra symbols
Errors from xkbcomp are not fatal to the X server

with some of the tries, I managed to take this message out, but still, my AltGr wouldn't function.
After solving the problem with 'setxkbmap' on .xinitrc, the message still appears, but my keyboard is fully functional, so it's all cool

note: by "manual" keyboard, I'm refering to putting these 5 Options, in xorg.conf. under keyboard section - "XkbKeycodes" // "XkbTypes" // "XkbCompat" // "XkbSymbols" // "XkbGeometry" with the files chosen by you on /usr/share/X11/xkb
Xorg.0.log would always load the keyboard options correctly with no WW or EE, with no indication whatsoever to a keyboard layout US or default (since that was the one being loaded 1st when entering).
funny fact: when I was messing with '/usr/share/X11/xkb' files to make a "manual" keyboard, I managed to get this output on Xorg.0.log (something like this, didn't save the file to copy exact words), after my layout was already loaded:

....
Loading default "us"...

and I was like "I knew it!" altho I knew it since the beggining (duh!), it was nice to see it written somewhere

Note that some of these things I tried, didn't work for me, but worked for others, as you can check on the links above, and for certain, there are other ways of solving this problem.

If you use a login manager, you probably never felt this problem, not sure tho, since I didn't make tests with lm's. If you don't use a login manager but are very used to shortcut keys to navigate through your WM, you probably didn't feel it either, since the keyboard layout gets recognized on the 1st key you press.

I'd like to leave this link here, we all know it and love it on the terminal, basicly is the man pages, but on the web, I enjoyed it cause it gave me more flexibility reading several man pages "at the same time" (aka firefox tabs ):
http://linux.die.net/man/

Well, I guess that's it.
have fun, and gl!

Last edited by frp (2009-03-30 08:10:08)

eNTi · 2009-03-29 11:07:31

thank you for that comprehensive help. you should add that info to the wiki troubleshooting page if you ask me. i'm having the exact same problem with me "de" layout. everything that starts up with X11 (kde) uses the us keymap until i restart it.

the problem ist: your "solution" is merely a workaround that might or might not brake in the (near) future. for me that's a bug... not a regression but a bug, since they modified the "old" behavior, that so many of us need to be working set by:

Section "ServerFlags"
    Option      "AutoAddDevices" "False"
EndSection

whatever those guys at the xorg development team are trying to do... it's not working (very well). i don't know how such changes make it into a stable tree, since they're obviously not very well tested... unless we are the testers.

Last edited by eNTi (2009-03-29 11:09:32)

Crooksey · 2009-03-29 11:13:16

Input devices simply arent declared in xorg.cong anymore, they are declared in the hal fdi file.

frp · 2009-03-30 08:29:25

Crooksey wrote:

Input devices simply arent declared in xorg.cong anymore, they are declared in the hal fdi file.

hmm... *rollseyes*... I don't know if I should cry or laugh... maybe you were tired? sleepy? dunno, but it's sad to see a comment just for being a comment.
I say this because, if you actually read what I posted, you'd notice this problem has nothing to do with hal, since I use xorg.conf for configuring my keyboard, which automatically means I'm not using hal, and right in the start I say:

frp wrote:

so, if you have the same problem as me, and this solution doesn't work, you might wanna give a look at wiki and some previous posts, like:

so, if you read the wiki or some of the links I posted, all relate to problems on configuring xorg.conf for keyboard.
With hal configuring your input devices, you don't even need the entries and sections for mouse or keyboard in xorg.conf, these:

Section "ServerLayout
....
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
....
Section "InputDevice"
Identifier "Mouse0"
....
Section "InputDevice"
Identifier "Keyboard0"
....

simply because you configure them on hal fdi file, with the options you want as you would on xorg.conf.
And if you read my post, you'd see:

frp wrote:

just that should work, but if just 'xorg' ain't enough or if you just want to put more options, you can check how your keyboard is being recognized and fill with the same, run:
$ xprop -root | grep XKB

if you actually have runned it on your computer (assuming you're using hotplugging), you would see something like this:

_XKB_RULES_NAMES(STRING) = "evdev", "evdev", "pt", "", ""

but if you don't use hal, and use xorg.conf, you see something like this:

_XKB_RULES_NAMES(STRING) = "xorg", "pc105", "pt", "", ""

Said this, I'm gonna point you to the wiki sections of input hotplugging:
1.http://wiki.archlinux.org/index.php/Beg … otplugging
2.http://wiki.archlinux.org/index.php/Xor … server_1.5
If you read carefully, you see that you have to use the Option "AutoAddDevices" "False" so hal won't take over your configuration. Incase you want hal, you have 2 links pointing to it, the 1st one below the 1st purple rectangle, and the 2nd link is inside the 2nd purple rectangle, read before clicking.
3.http://wiki.archlinux.org/index.php/Xor … g_properly
here is an example of the stuff I tried and didn't work for me, as stated on my post.

Now I'll add a line or two of hotplugging on my post, so I can avoid posts like that and stay focused on the real problem, which is the gap between console/startx and the 1st key pressed, not using hal.

eNTi wrote:

the problem ist: your "solution" is merely a workaround that might or might not brake in the (near) future. for me that's a bug... not a regression but a bug, since they modified the "old" behavior, that so many of us need to be working set by:

yep, this workaround as you perfectly stated, might break. I've been trying to find the actual file that leads to a default of US, but no luck. It's like if the keyboard layout is "dormant", and after the 1st key is pressed, it grabs the definitions on xorg.conf. Now, why is he "dormant" on a US layout, what tells it to be US? if the layout coming from the console is PT (in my case) and the layout in xorg.conf is pt, why the US in the middle? weird

bernarcher · 2009-03-30 09:09:18

Quite a lot of fine print to read.
I did merely skim it so I may have missed some points.

One cause of catching up a wrong keyboard layout may however be caused by the fact that the environment changes in the startup process. Hence the system tries to use the initial setup when processing, say .xinitrc, then switches to a login shell which probably uses quite another environment settings.
It is a problem I have to work around in my IceWM setup where the internal taskbar command line works in another environment as the current desktop does.

Not sure if this really applies to the semi-automatic xorg keyboard setup. It could be that AutoAddDevices is processed in the newly set up environment istead of the startup one. But I don't have the time to dig deeper here.

Last edited by bernarcher (2009-03-30 09:11:58)

frp · 2009-03-30 09:43:59

@bernacher
by login shell, you mean login manager? if yes, I'm not using one, the change in environment is console->X.

About your problem in IceWM, that could actually be related. Note that I never tried IceWM, so what I'm gonna say might not have nothing to do.
Well, I tested here, and I can have two layouts on diferent environments just like you, one US and one PT. In the post I say that if I enter WM, don't press any key, and open firefox, I have US layout. close and open again and it's PT.
What I tested right now was, open mousepad, and confirm it's US layout, and open a second mousepad window, and confirm it's PT. and then I was alt-tabbing and I had US layout in one and PT on the other. If I close the US layout one, I don't have US layout anymore, unless I logout ofc.
I solved this with the workaround posted above:

setxkbmap -layout pt & # shout at WM to use this layout _since_the_beginning_
(sleep 1 && xset r) & # put repeat on after new keyboard layout loaded

adding these two lines to the .xinitrc. but change 'pt' for your layout
you could try and see if it works on your IceWM.
gl!

bernarcher · 2009-03-30 10:55:25

frp wrote:

@bernacher
by login shell, you mean login manager? if yes, I'm not using one, the change in environment is console->X.
About your problem in IceWM, that could actually be related. Note that I never tried IceWM, so what I'm gonna say might not have nothing to do.
Well, I tested here, and I can have two layouts on diferent environments just like you, one US and one PT. In the post I say that if I enter WM, don't press any key, and open firefox, I have US layout. close and open again and it's PT.

There are two "shell modes" in bash: login and interactive. The login shell is responsible for setting up the environment and starting the WM/DM. The interactive one subsequently uses this one, unless you force a new login by e.g. "su -". This is what you normally use in a terminal. (see info bash)

About that firefox keyboard initalization problem, this is a known gtk issue. It vanishes if you allow hal/evdev to auto add devices. Otherwise you have live with it. Xorg 1.6 probably might cure this, but I am not sure.

Last edited by bernarcher (2009-03-30 10:56:25)

frp · 2009-03-30 20:09:37

bernarcher wrote:

About that firefox keyboard initalization problem, this is a known gtk issue. It vanishes if you allow hal/evdev to auto add devices.

As i said in my original post, it's not a firefox problem, it happens with anything you open, except terms, terms tend to grab xorg.conf. If I allow hal/evdev to auto add devices, it's true the problem vanishes, but so does my keyboard and mouse and only option is to hard reset with power or reset button on the pc.
Well, if I was using hal/evdev, I don't think I'd make this post at all

bernacher wrote:

Otherwise you have live with it. Xorg 1.6 probably might cure this, but I am not sure

Actually, I don't have to live with it, because the workaround I presented solves it, these two lines in .xinitrc:

setxkbmap -layout pt & # shout at WM to use this layout _since_the_beginning_
(sleep 1 && xset r) & # put repeat on after new keyboard layout loaded

I guess for now I gotta have a look into bash stuff, and wait for Xorg 1.6

btw, did you try it on your IceWM?

Last edited by frp (2009-03-30 20:10:34)

proc · 2009-06-27 16:35:15

Thanks frp I was having the same problem on my HTPC where I have an Italian keyboard.

I must say the new Xorg is really pissing me off: first the auto add devices thing, then Xrandr making multiple monitors with more than one video card unusable and now this (related to HAL). I mean, monitor hot plugging is fine on a notebook (a part from the virtual desktop size you have to specify in xorg.conf ), but screwing everything just for that is not a sensible thing to do in my opinion.

Sorry for the rant

Arch Linux

#1 2009-03-29 02:24:12

[SOLVED] altgr or others not working+us keyboard default+any wm/de

#2 2009-03-29 11:07:31

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#3 2009-03-29 11:13:16

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#4 2009-03-30 08:29:25

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#5 2009-03-30 09:09:18

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#6 2009-03-30 09:43:59

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#7 2009-03-30 10:55:25

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#8 2009-03-30 20:09:37

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

#9 2009-06-27 16:35:15

Re: [SOLVED] altgr or others not working+us keyboard default+any wm/de

Board footer