Bug 432627

What do you mean with sometimes? Does this also happen when starting a failsafe Xsession instead of KDE4?

It mean it can happening right after the boot or some times later. 
It can stop working after simple typing in adress bar in konqueror. After some typing it can be working again, but not for long time.

Created attachment 243679 [details]
SaX log

Created attachment 243680 [details]
Xorg log

Created attachment 243681 [details]
Xorg.conf

Again. Does this also happen when starting a failsafe Xsession instead of KDE4?

Have tested failsafe session. Keyboard works fine in xterm and Firefox, all keys working good, but in kde4 apps running in failsafe i.e. konqueror keyboard dont work at all.

Ok. This sounds like a KDE4 related issue. Who knows what KDE4 does with the keyboard.

Sometimes this happens when changing layout to Russian through keystroke Ctrl-Shift, switching back to English makes Backspape working again. Keysym provided by xev utility in Russian layout is "No symbol" instead of BackSpace. 

Way to reproduce: reboot, log in to KDE4 with kdm4, run console, switch to Russian layout with Ctrl-Shift. Backspace doesn't work, xev shows (keysym 0x0, NoSymbol). Possibly that's another bug - in my case cursor keys are working fine.

issue still present in beta3

In beta 3 I have tested issue more. 

I found that backspace dont work mostly in russian keyboard layout, but sometime it dont work also in english keymap after layout switch from russian to english.

When backspace work good xev print following 

KeyPress event, serial 34, synthetic NO, window 0x2800001,
    root 0x1a6, subw 0x0, time 2263558, (45,110), root:(717,135),
    state 0x4010, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "                                  
    XmbLookupString gives 1 bytes: (08) "                                
    XFilterEvent returns: False                                          

KeyRelease event, serial 34, synthetic NO, window 0x2800001,
    root 0x1a6, subw 0x0, time 2263638, (45,110), root:(717,135),
    state 0x4010, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "                                  
    XFilterEvent returns: False     

When dont:
KeyRelease event, serial 34, synthetic NO, window 0x2800001,
    root 0x1a6, subw 0x0, time 2235990, (69,64), root:(741,89),
    state 0x6010, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:                                                
    XFilterEvent returns: False                                                 

KeyRelease event, serial 34, synthetic NO, window 0x2800001,
    root 0x1a6, subw 0x0, time 2236614, (69,64), root:(741,89),
    state 0x6010, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:                                                
    XFilterEvent returns: False 

Not sure if others key sometimes dont work in beta3, seems its only about backspace

Issue still present in beta4, installed from DVD i386 with KDE4. Backspace still randomly dont work in russian keyboard layout.

This really serious bug, because no way to  type anything, I have use cursor key and delete instead of backspace in all application, and it make me crazy

I have same problem (Toshiba A200 1M8/openSUSE 11.1b4 x86_64/Live CD install). Backspace isn't working in Russian layout.
I hope developers will fix it in RC1. Thanks.

Don't play around with severities: http://en.opensuse.org/Bugs/Definitions

I'm sorry for playing with severities.

I've tested more this issue. This is no anythyng about KDE4.

Backspace dont work in russian keyboard layout on autologin in an window manager, i've tested it on IceWM, TWM, KDE4 and KDE failsafe (currently installing GNOME for test it). If I logout and login again all keys works perfectly. 

Backspace works after autologin only on X failsafe session without a window manager.

Not sure if it affected only to autologin or to th first login without autologin too, because cant disable autologin on my 11.1 beta4.

Ok, tested it with disabled autologin i found that backspace works good on first and others post logins, issue reproduces only with autologin enabled.

If it helps, I've  tested this issue with kdm3 and kdm4 (4.1.2 and 4.1.3) as Display manager and in all that cases issue reproduced. 

I still have this issue in KDE4 Live CD i686 beta5

Issue still reproduces on current Factory  beta5.2 Backspace dont work, as result system unusable at all. Cant surf internet, cant type in OOo, cant use Jabber or IRC, because backspace dont work in all this applications.

but you're the only one to report such a general problem -> no ship stopper

And btw, the live cds may be bad for testing as the xkb setup of them is broken in beta5

Last my test was on installed and updated to factory beta5, not an LiveCD.

Now i've trried Xorg 7.4 from  http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.0/ on my stable openSUSE 11.0 with kde 3.5 and got the same problem. Now I can say that this is issue of Xorg 7.4, not any kde Application, that bug assigned for.

When I press backspace in russian layout xev tell me 

KeyRelease event, serial 34, synthetic NO, window 0x2c00001,
    root 0x1a6, subw 0x0, time 72148, (-207,587), root:(606,629),
    state 0x6010, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2c00001,
    root 0x1a6, subw 0x0, time 73308, (-207,587), root:(606,629),
    state 0x6010, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Xorg generates release event twice and no press event, and generate wrong keysym.


When all works fine xev produce this 

KeyPress event, serial 34, synthetic NO, window 0x2c00001,
    root 0x1a6, subw 0x0, time 76084, (-207,587), root:(606,629),
    state 0x4010, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "
    XmbLookupString gives 1 bytes: (08) "
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0x2c00001,
    root 0x1a6, subw 0x0, time 76188, (-207,587), root:(606,629),
    state 0x4010, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "
    XFilterEvent returns: False


please, reassign this bug to Xorg team

(In reply to comment #21 from Stephan Kulow)
> but you're the only one to report such a general problem -> no ship stopper

Me too, and some more peoples around, not all of they posted a comment there. 

i reproduce

Me too.
BackSpace is working:
KeyRelease event, serial 34, synthetic NO, window 0x3600001,
    root 0x1a6, subw 0x0, time 880510, (697,359), root:(702,384),
    state 0x4000, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "                                  
    XFilterEvent returns: False         
BackSpace is not working:
KeyRelease event, serial 34, synthetic NO, window 0x3600001,
    root 0x1a6, subw 0x0, time 887796, (697,359), root:(702,384),
    state 0x6000, keycode 22 (keysym 0xfed5, Terminate_Server), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
My xorg.conf:
Section "InputDevice"
    Identifier     "Mouse[1]"
    Driver         "mouse"   
    Option         "Buttons" "5"
    Option         "Device" "/dev/input/mice"
    Option         "Name" "KYE NetScroll + Traveler"
    Option         "Protocol" "explorerps/2"        
    Option         "Vendor" "Sysp"                  
    Option         "ZAxisMapping" "4 5"             
EndSection

Oh,sorry, my xorg.conf:
Section "InputDevice"
    Identifier     "Keyboard[0]"
    Driver         "kbd"        
    Option         "Protocol" "Standard"
    Option         "XkbLayout" "us,ru"  
    Option         "XkbModel" "microsoftpro"
    Option         "XkbOptions" "grp:lctrl_lshift_toggle,grp_led:scroll"
    Option         "XkbRules" "xfree86"                                 
    Option         "XkbVariant" "basic,winkeys"                         
EndSection 

This has nothing to do with Russian keyboard layout. Bug can be reproduced even with single "us" layout.

Steps to reproduce (for Beta5):
1. Install KDE4 desktop.
2. Enable auto-login in /etc/sysconfig/displaymanager (DISPLAYMANAGER_AUTOLOGIN) and in kdm config.
3. Add the following line to corresponding "InputDevice" section in xorg.conf:
Option       "XkbOptions" "grp:ctrl_shift_toggle"
4. Disable kxkb in KDE configuration.
5. (re)start kdm.
6. Press Ctrl+Shift. Now Backspace and function keys do not work (produce wrong keysyms).

Possible workarounds: run setxkbmap with some options after login or enable kxkb.

Looks like under certain conditions KDE (or kdm) does something funny with XKB upon startup.

I can confirm this issue. I have opensuse 11.0, X.org updated from Factory, KDE 4.1.3 from factory too. KDM is login manager

I have enabled autologin with "yast/security and users/user and group management"->"expert options/login settings".

I also have KDE layout indicator inabled: "Configure Desktop/Regional and Language/Keyboard Layout" -> "Indicator Only", so I can see current layout indicator in tray.

After rebooting and autologging in I have the following behavior:

1. Login with english layout by default - layout indicator shows "us" - backspace works
 
 2. Press ctrl+shift - input language is russian - layout indicator shows "ru" - backspace works
 
 3. Press ctrl+shift - input language is english - layout indicator shows "3" (!) - backspace works
 
 4. Press ctrl+shift - input language is russian - layout indicator shows "4" (!!) - backspace does NOT work.


And this all loops.

Log out/login again solves the issue - layout indicator only shows "us"/"ru", no extra "3"and "4" layouts.


keyboard section from xorg.conf

Section "InputDevice"
  Driver       "kbd" 
  Identifier   "Keyboard[0]"
  Option       "Protocol" "Standard"
  Option       "XkbLayout" "us,ru"  
  Option       "XkbModel" "microsoftpro"
  Option       "XkbOptions" "grp:ctrl_shift_toggle"
  Option       "XkbRules" "xfree86"                
  Option       "XkbVariant" "basic,winkeys"        
EndSection

this looks like the same issue in upstream, and it have a solution: 

https://bugs.freedesktop.org/show_bug.cgi?id=16105

and

https://bugs.freedesktop.org/show_bug.cgi?id=16364

Partially confirm this bug:
I've had the same issue after installing 11.1 Beta5, but updating to Beta 5.2 and update of xorg from factory solved the problem.

Now I have xorg-x11-7.4-8.8 & kde4-kdm-4.1.73-3.3 with enabled autologin, so the reaction on backspace seems correct:

KeyPress event, serial 31, synthetic NO, window 0x3e00001,
    root 0x1a6, subw 0x0, time 14396359, (527,-156), root:(532,364),
    state 0x10, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "                                
    XmbLookupString gives 1 bytes: (08) "                              
    XFilterEvent returns: False                                        

KeyRelease event, serial 34, synthetic NO, window 0x3e00001,
    root 0x1a6, subw 0x0, time 14396480, (527,-156), root:(532,364),
    state 0x10, keycode 22 (keysym 0xff08, BackSpace), same_screen YES,
    XLookupString gives 1 bytes: (08) "                                
    XFilterEvent returns: False

May be the x86_64 architecture that I have matters...

Upstream does indicate some fixes, maybe Stefan or Vincent can comment on effectiveness.

The upstream fixes are not in what we ship yet, AFAIK.

FWIW, in GNOME, we had a similar issue for 11.0 (see bug #369263). We have a patch that runs "setxkbmap" on login to workaround this...

Thanks. This reminds me to Bug #371756, comment #36/39.

I found a solution. It's pretty simple.

Wr nrrd to comment out or remove 102 and 103 strings in /etc/X11/xinit/xinitrc.common

this two:

#
# Fix keyboard layout on newer Xservers (Bug #368673, Bug #433983)
#
xdpyinfo | grep -q "X.Org version: 6.9.0" || \                
  setxkbmap -print | xkbcomp - $DISPLAY

Please, include it in GM, really nessesary fix for russian users.

103 and 104 lines, sorry

i've tested for bugs Bug #368673, Bug #433983 and they not reproduces without this lines, no more need for this trick in xinitrc.common

solution also works for me on openSUSE 11.0 with X.Org 7.4

A agree with Vitaliy Tomin about the reason of this bug.

xdpyinfo | grep -q "X.Org version: 6.9.0" || \                
 setxkbmap -print | xkbcomp - $DISPLAY

On default configuration Xorg version is 1.5.2. ( xdpyinfo | grep -q "X.Org version: 6.9.0" ) returns false and commands ( setxkbmap -print | xkbcomp - $DISPLAY ) execs - but the current version of Xorg doesn't need this command.

( setxkbmap -print | xkbcomp - $DISPLAY ) was necessary on OpenSuse 11.0 with X.Org version: 1.4.0.90.

But /etc/X11/xinit/xinitrc.common belongs to xorg-x11 and we don't need to care about old hacks in OpenSuse 11.0.

Well, I don't believe that we no longer need this hack. That would mean that gdm has implemented what is mentioned in comment #33. I don't think this has happened.

*** Bug 457116 has been marked as a duplicate of this bug. ***

But why we have 'grep -q "X.Org version: 6.9.0"' condition with Xorg 1.5.2 ?

(In reply to comment #39 from Stefan Dirsch)
> Well, I don't believe that we no longer need this hack. That would mean that
> gdm has implemented what is mentioned in comment #33.

Is Bug #371756 mentioned in this comment reproducible in 11.1 without this
hack? (Cannot check it myself due to access restrictions for that bug).

Do any keyboard-related problems appear after removing these two lines?

(In reply to comment #41 from Dmitri Mittov)
> But why we have 'grep -q "X.Org version: 6.9.0"' condition with Xorg 1.5.2 ?

We do not have it. It's followed by "or", not "and". That is why second part of the command is executed.

>> But why we have 'grep -q "X.Org version: 6.9.0"' condition with Xorg 1.5.2 ?

> We do not have it. It's followed by "or", not "and". That is why second part of the command is executed.

Yes. The second part of the command executes. And this is the reason of the bug. Without theese lines all works fine in kde4.

Does gnome and other DE or WM need 'setxkbmap -print | xkbcomp - $DISPLAY' to work?

Why it reassigned to KDE Workspace if bug can be fixed by removing two lines in /etc/X11/xinit/xinitrc, that part of xorg package?

I have this issue with any kind of DE, including IceWM and twm.

(In reply to comment #45 from Vitaliy Tomin)
Indeed, this bug has nothing to do with KDE. It's definitely bug in xorg. It can be easily reproduced without any DE or WM at all: just run 
WINDOWMANAGER=xterm startx

As long as kdm/gdm (only displaymanager with autologin feature we have on the distro) do not implement what is mentioned Bug #371756, comment #36/39, we need this hack, which unfortunately breaks backspace with russian keyboards. Currently there is no fix available. Removing the hack is not an option here.

(In reply to comment #47 from Stefan Dirsch)
Could please anybody tell what these comments are about? Bug #371756 has restricted access.

I removed this restriction now. No idea why it was set.

Stefan: fwiw, in https://bugs.freedesktop.org/show_bug.cgi?id=16105 there's a comment saying it might have been fixed in X.

... *might* have been fixed in X. Who knows it for real.

(In reply to comment #47 from Stefan Dirsch)
> As long as kdm/gdm do not implement what is mentioned Bug #371756, comment
> #36/39, we need this hack
Hm, now I don't understand why that bug is relevant: it's about keyboard auto-repeat during installation.

I've also carefully read all comments for bugs 368673 and 369263. They seem to indicate that putting this line to xinitrc.common does not always help (Bug 368673, comment #59; Bug 368673, comment #110-111; Bug 369263, comment #41; Bug 369263, comment #47). Running this command manually from terminal does fix broken keymaps, but running from xinitrc -- doesn't.

I still can't see why this hack is needed. But, of course, the best thing to do is to look for upstream fixes.

(In reply to comment #51 from Stefan Dirsch)
> ... *might* have been fixed in X. Who knows it for real.

We'll know when we'll have the new X :-) It's just a matter of waiting for the release and then testing.

And what do you mean with "new X"?

(In reply to comment #54 from Stefan Dirsch)
> And what do you mean with "new X"?

New releases of the module containing the commit mentioned in the upstream bug? I don't know if it's the X server or one of the X libs. Asking Peter Hutterer is a good way to have the right answer.

Was this fixed in the released 11.1? If not, what is the good workaround for this?

1. I want to have autologin enabled
2. I want to use kde4 layout indicator in the "Indicator Only" mode
3. I want the fix to be done automatically during system/desktop startup (without having to manually run any programs after each login)

(In reply to comment #56 from Anton Moiseev)
> Was this fixed in the released 11.1?
No.

> If not, what is the good workaround for this?
See Comment #34.

Thank's, I already can see - installed new Opensuse 11.1 and the bug is here as described. Solved by putting 'setxkbmap' line to ~/.bashrc, now its fine

a correction:

setxkbmap -layout 'us,ru(winkeys)'

if running just setxkbmap without options, symbol 'э' из printed in wrong way

Related: Bug #466263

*** Bug 473657 has been marked as a duplicate of this bug. ***

Actually, the Xorg bugs 16105 and 16384 (and the attached patches) indicate that this is changing the path for evdev / hal enabled input only.

xorg commit 9c5dd7337fa93fb1650cc017e523b939dcbf482a might fix this issue, though. Have to verify.

(In reply to comment #62)
> Actually, the Xorg bugs 16105 and 16384 (and the attached patches) indicate
> that this is changing the path for evdev / hal enabled input only.

but this issue have nothing with hal/evdev, it caused by strange suse hacks in /etc/X11/xinit/xinitrc.common, it just duplicate layouts defined in xorg.conf, and ruined it

I finally removed the hack in /etc/X11/xinit/xinitrc.common for Factory, since it's no longer required with xorg-server 1.6. Thus we can close this issue as fixed now for openSUSE 11.2.

(In reply to comment #64)
> I finally removed the hack in /etc/X11/xinit/xinitrc.common for Factory, since
> it's no longer required with xorg-server 1.6. Thus we can close this issue as
> fixed now for openSUSE 11.2.

Ok, it fixed for 11.2 and works good for me in factory, but what about stable 11.1 and SLED 11?

Curent SLED 11 RC4 has this 103 and 104 lines in /etc/X11/xinitrc.common  and it broke keyboard layyot - backspace and F1-F12 simply doesnt works. Also this lines vroke all keymapings made in ~/.Xmodmap.

This bug are very critical for russian users, so many people disappointed by oS 11.1 because even keyboard doesnt work as it should, what they will think about future SLED 11?

There are no plans to address this issue also for openSUSE 11.1, since it requires an update to xorg-server 1.6, which is not an option.

Do you plan to get it fixed for SLE11?

Can anyone explain why that hack is needed in the first place ?

If it breaks the keyboard for everyone who's using a russian keyboard, it's definitely worth shipping a patch, isn't it ? :)

changing "version" to "final", as it's still broken in 11.1

(In reply to comment #69)
> Can anyone explain why that hack is needed in the first place ?

Without it czech keyboard layout is broken when autologin is used. See Bug #368673. Apparently this issue is fixed with xorg-server 1.6 we recently switched
to for factory/openSUSE 11.2. So we removed this hack.


> If it breaks the keyboard for everyone who's using a russian keyboard, it's
> definitely worth shipping a patch, isn't it ? :)

And breaking czech keyboard layout again? I don't think so.

(In reply to comment #71)
> 
> > If it breaks the keyboard for everyone who's using a russian keyboard, it's
> > definitely worth shipping a patch, isn't it ? :)
> 
> And breaking czech keyboard layout again? I don't think so.

And breaking russian keyboard layout again? I don't think so.

Not sure, what you want to tell me with your comment, Andrey.

How about changing those lines to

xdpyinfo | grep -q "X.Org version: 6.9.0" || {
  setxkbmap -print | grep -Eq '\bxkb_symbols\b.+".+\bru\b' || \
    setxkbmap -print | xkbcomp - $DISPLAY ;
}

instead ?

Cheap hack, but that would at least not run the "setxkbmap -print|xkbcomp..." part that breaks the russian keyboard layout when the X.org is configured for russian keyboard layout ;)

Or, at least, that's my interpretation.

Could someone with a russian keyboard test it ?

yes, this fixes our issue.

Didn't this broke Czech keyborads?
If no, could we release online update?

Could someone with a czech keyboard please test it ?

I'm reopening the bug as we might have a working patch here.

I'm afraid there's no czech guy added to this bugreport.

There is one ;-). I will play around with it later this week, if I find a bit of spare time.

Jan, in case you really play around with it, please make sure to test without the hack, with the original hack and with the improved one. Autologin must be enabled to reproduce the issue and it's only reproducable if you get logged in automatically, so only the first time you start the displaymanager. So you need to restart it for each test.

Jan, are you still planning to test this?

Yes, still planning. Not enough time, though. Hopefully I will find some this week.

Still waiting for appropriate feedback for more than 3 weeks now. Please reopen once you can provide the requested feedback. Thanks.

Stefan, just look at the patch, this is obviously going to work (as in: not break anything) as it only affects the Russian keyboard layout.

Can't we just have that patch pushed out ?

I disagree. I would like to see this tested first.

I can test it with Czech keyboard. But please, could someone familiar with this bug summarize what/how to be tested (hard to figure out from 84 comments).

I mean: 11.1/Factory? KDE4.2.2/KDE4.1.x? Any other prerequisities? What are the exact fix/fixes I should try? (pointers to appropriate comment numbers should be enough)

Thanks

See comments #74 and #79. The hack is in /etc/X11/xinit/xinitrc.common. Please test with regular 'cz,us' keyboard layout.

I finally managed to get some test results. To prevent confusion, for
the whole duration of testing, the following configuration was in place:

Section "InputDevice"
  Driver       "kbd"
  Identifier   "Keyboard[0]"
  Option       "Protocol" "Standard"
  Option       "XkbLayout" "us,cz"
  Option       "XkbModel" "microsoftpro"
  Option       "XkbOptions" "grp:alt_shift_toggle,grp:switch"
  Option       "XkbRules" "xfree86"
  Option       "XkbVariant" "basic,basic"
EndSection

All testing was done using konsole, firefox and xterm to avoid
influence by KDE environment.

1. Autologin enabled:

a] Hack completely removed
Czech keyboard works perfectly, everything I tried worked just
as I expected, space works, backspace works.

b] Hack in place
Backspace doesn't work in one of two cases. Broken.

c] Proposed fix
As expected, nothing changes from the previous case. Broken backspace.

2. Autologin disabled:

a] Hack completely removed
Works.

b] Hack in place
Works.

 c] Proposed fix
Works.

Hack breaks basic czech keyboard when autologin is in use, probably the same way it breaks russian keyboard. Adding proposed solution will fix russian keyboard (hack won't be applied), czech keyboard will stay broken as it is now, though.

Seeing those results, I'm not very sure what the hack is there for, I didn't find any case where it actually helped something. Maybe I didn't have the right testcase, though. Anything else I should test for?

Petr, you said you will take a look on it, can you confirm my findings?

Using xkbcomp, I got following results.

1a, 2a, 2b, 2c gave the following (which seems correct):

    key <BKSP> {
        type= "CTRL+ALT",
        symbols[Group1]= [       BackSpace, Terminate_Server ]
    };

While 1b and 2c gave this (obviously wrong): 

    key <BKSP> {
        type[group1]= "CTRL+ALT",
        type[group2]= "ONE_LEVEL",
        type[group3]= "ONE_LEVEL",
        type[group4]= "ONE_LEVEL",
        symbols[Group1]= [       BackSpace, Terminate_Server ],
        symbols[Group2]= [       BackSpace ],
        symbols[Group3]= [       BackSpace ],
        symbols[Group4]= [ Terminate_Server ]
    };

Sorry, the second part is 1b and 1c. 

So, according to my findings, you can safely apply the patch and it will help with russian+autologin, but czech+autologin stays broken...

Jan, thanks a lot for testing and detailed test description and results! Indeed having seen these results the hack appears no longer to make any sense, but ... instead of "us,cz" our default is to use "cz,us" and given the brokeness of xkb in X this *can* make a difference. Any chance to do the detailed testing again to verify that you get the same results with our default "cz,us" setting?

Just for completeness, this was tested on oS11.1 with all maintenance updates applied. 

Yes, I hope to get back to it tomorrow. I also plan to test with querty variant, because in one of the related bugs, I found that the problem manifested with qwerty variant only. We will see.

(In reply to comment #90)
> instead of "us,cz" our default is to use "cz,us" and given the brokeness of xkb
> in X this *can* make a difference. Any chance to do the detailed testing again
> to verify that you get the same results with our default "cz,us" setting?

Since still no treply from Yan, I've tested it on "ru,us"

When I set us layout as second, I got all problems as described above. Backspace and F1-F12 now doesnt work in "us" layout.

Nevertheless I would like to see feedback by Jan about "cz,us" as well.

Jan?

I'm testing it now.

Autologin disabled:

us,cz; no hack - OK
us,cz; hack - OK
us,cz; cond hack - OK

us,cz(qwerty); no hack - OK
us,cz(qwerty); hack - OK
us,cz(qwerty); cond hack - OK

cz,us; no hack - OK
cz,us; hack - OK
cz,us; cond hack - OK

cz(qwerty),us; no hack - OK
cz(qwerty),us; hack - OK
cz(qwerty),us; cond hack - OK

So, hack presently doesn't influence anything when autologin is disabled. OK. We knew that already, but I just wanted to make sure that we won't break anything in case hack is disabled completely. Autologin enabled following soon.

Autologin enabled:

us,cz; no hack - OK
us,cz; hack - BROKEN
us,cz; cond hack - BROKEN

us,cz(qwerty); no hack - OK
us,cz(qwerty); hack - BROKEN
us,cz(qwerty); cond hack - BROKEN

cz,us; no hack - OK
cz,us; hack - BROKEN (backspace doesn't work with english for a change...)
cz,us; cond hack - BROKEN

cz(qwerty),us; no hack - OK
cz(qwerty),us; hack - BROKEN (again, english backspace)
cz(qwerty),us; cond hack - BROKEN

Tested with KDM4, konsole, xterm. Tested with F-keys, arrows, backspace, space and a random bunch of others. From my viewpoint, it is clear. We can remove the hack. 

However, I obviously didn't test installer and such (and some of the referenced bugs were supposed to trigger only with installer). On the other hand, update of X for oS11.1 won't probably be used within installer... 

Tired... need sleep now ;)

Ok. Convinced. I'm going to remove the hack in OBS, X11:XOrg:sle11 now. It's already removed fro Factory.

done. Will be officially available for SLE11-SP1 or the next update I'm preparing.
There's already an update in the queue. Unfortunately it won't be part of this
(QA is already testing).

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-PRELOAD 11-2009A (i386, x86_64)

Will be the patch for 11.1 available?

Yes, that's the plan.

Update released for: Mesa, Mesa-debuginfo, Mesa-debugsource, Mesa-devel, Mesa-devel-static, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debugsource, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
openSUSE 11.1 (debug, i586, ppc, ppc64, x86_64)

Update released for: Mesa, Mesa-32bit, Mesa-debuginfo, Mesa-debuginfo-32bit, Mesa-debuginfo-x86, Mesa-debugsource, Mesa-devel, Mesa-devel-32bit, Mesa-devel-static, Mesa-x86, xkeyboard-config, xorg-x11, xorg-x11-Xvnc, xorg-x11-debuginfo, xorg-x11-debugsource, xorg-x11-driver-video, xorg-x11-driver-video-32bit, xorg-x11-driver-video-debuginfo, xorg-x11-driver-video-debuginfo-32bit, xorg-x11-driver-video-debuginfo-x86, xorg-x11-driver-video-debugsource, xorg-x11-driver-video-x86, xorg-x11-server, xorg-x11-server-debuginfo, xorg-x11-server-debugsource, xorg-x11-server-extra, xorg-x11-server-sdk, xorg-x11-xauth
Products:
SLE-DEBUGINFO 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-DESKTOP 11 (i386, x86_64)
SLE-SDK 11 (i386, ia64, ppc64, s390x, x86_64)
SLE-SERVER 11 (i386, ia64, ppc64, s390x, x86_64)