Bug 368673

Could you add the output of "setxkbmap -print" and attach the output of "xmodmap -pke"?

Created attachment 200126 [details]
setxkbmap-print

Created attachment 200129 [details]
xmodmap-pke

Another weird thing - after I fix the layout by running sax2, the output of these 2 commands stays the same.

I can reproduce this behaviour during installation in an xterm (Ctrl-Alt-Shift-x). Just found in y2log.

/usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle -model microsoftpro
/usr/bin/setxkbmap -variant qwerty,basic -layout cz,us -option 
                   grp:shift_toggle -model microsoftpro

But on an installed system using these commands doesn't trigger this problem.

The same problem during installation with the normal cz(qwerty) layout. 

I tried the two commands above in an xterm during installation, but there I cannot reproduce this issue either.

I suggest to add the "-v" option at the end of each setxkbmap command line. Possibly also an additional "setxkbmap -print" command. This might help to debug this isssue. 

BTW, if you use -option "<whatever>" add an additional -option "" in front of to reinitialize the options. Otherwise the given options are added to the existing ones.

Martin, since you're a YaST developer. Anybody, you're aware of, who could add this debug output?

That is jsuchome for Keyboard.ycp and locilka for inst_inc_second.ycp (to add -v and then also log the enhanced output).

Ok. Reassigning to jsuchome. Reassign back to me after you changed Keyboard.ycp accordingly.

Does it make sense to submit a package with just additional debug output? Wouldn't it be sufficient to start installation with a inst-sys modified to contain changed Keyboard.y* files?

Unfortunately I cannot reproduce it, since the font is broken when I choose czech language and keyboard and try to write into some text entry. I thought this was fixed already... HuHa?

(In reply to comment #10 from Jiří­ Suchomel)
> Does it make sense to submit a package with just additional debug output?
> Wouldn't it be sufficient to start installation with a inst-sys modified to
> contain changed Keyboard.y* files?

No idea if it's enough to submit a package with just additional debug output.
I don't know, how to select a special inst-sys, so this won't help me. No idea what you mean with Keyboard.y* files. I'm not a YaST developer.

(In reply to comment #12 from Stefan Dirsch)
> (In reply to comment #10 from Jiří­ Suchomel)
> > Does it make sense to submit a package with just additional debug output?
> > Wouldn't it be sufficient to start installation with a inst-sys modified to
> > contain changed Keyboard.y* files?
> 
> No idea if it's enough to submit a package with just additional debug output.

But that's what you propose, isn't it?

> I don't know, how to select a special inst-sys, so this won't help me. No idea
> what you mean with Keyboard.y* files. I'm not a YaST developer.

Sorry. I mean that the change of Keyboard.ycp you require in comment 9 could be done in test environment, and it doesn't require to release new package. I can do the test myself, but I'm blocked by the issue with broken fonts....

(In reply to comment #11 from Jiří­ Suchomel)
> Unfortunately I cannot reproduce it, since the font is broken when I choose
> czech language and keyboard and try to write into some text entry. I thought
> this was fixed already... HuHa?

That's bug #371747 : Some lib missing in inst-sys that is required for encoding conversions.

IIRC we did have problems a long time ago with switching keyboard variants on the fly. This was never quite as reliable as entering the correct keyboard variant to the X11 configuration and starting X11 with that configuration, but it worked in the installed system.

So if this is only a problem during installation, this problem might not be so severe.

Jiří­, didn't know that you've meant the package submit / optional inst-sys as an exclusive or. Maybe you can test with the special inst-sys, because you know  how to setup this test environment, but I can't. So I vote for submitting the package. Then it might already be possible to investigate this issue further with Beta1.

Oh no, you all seem to get carried away in the wrong direction :-)

The problem exists in the installed system too, and there it bothers me far more than during the installation.

Martin Vidner> The problem exists in the installed system too, and
Martin Vidner> there it bothers me far more than during the
Martin Vidner> installation.

How can we reproduce it in the installed system? Stefan and me tried
to reproduce it on our workstations running Factory but unfortunately
we were not yet able to reproduce it (see comment #4).

Jiří­, is your part now committed for STABLE, so I can reassign the bug to locilka?

No, it is not. I didn't see a reason to add test output into installation, before the questions of above comments are answered. 
Martin says it is not related to installation, anyway.

(In reply to comment #18 from Mike Fabian)
> How can we reproduce it in the installed system? Stefan and me tried
> to reproduce it on our workstations running Factory but unfortunately
> we were not yet able to reproduce it (see comment #4).

That is strange. I can reproduce it in VirtualBox, and could give you access to it over VNC.

There might be additional keyboard problems when using VirtualBox
and/or VNC. I am not sure about VirtualBox but I ran in quite a few
keyboard problems happening *only* when VNC was used.

Anyway, trying cannot hurt, if you give me access to your VirtualBox
via VNC, I’ll try whether I can reproduce it. Although it would be
nicer if I could reproduce it on a “normal” machine.

VNC is known for all kind of strange keyboard behaviours, so this is not an option. Using VirtualBox instead of a normal installation could be another reason for your keyboard problems after installation. BTW, this is the first
time you're mentioning, that you're using VirtualBox. I suggest to try it without VirtualBox/VNC.

The only situation, where we could reproduce this issue was during installation. Thererfore I asked for debug information to add to installation, but obviously this was not appreciated.

==> WONTFIX

Well, I had a reason for not submitting a package with a debug information. But I will do it if there is no other way to debug the problem.

I added the debug to my testing inst-sys and this is the result: 

Calling " /usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle -model microsoftpro -v" produces the output:

Warning! Multiple definitions of keyboard model
Using command line, ignoring X server
Warning! Multiple definitions of keyboard layout
Using command line, ignoring X server
Trying to build keymap using the following components:
keycodes:   xfree86+aliases(qwertz)
types:      complete
compat:     complete
symbols:    pc+cz+inet(microsoftpro)+us:2+group(shifts_toggle)
geometry:   microsoft(natural)

Immediate call of "setxkbmap -print" returns
xkb_keymap {
  xkb_keycodes  { include \"xfree86+aliases(qwertz)\"};
  xkb_types     { include \"complete\"};
  xkb_compat    { include \"complete\"};
  xkb_symbols   { include pc+cz+inet(microsoftpro)+us:2+group(shifts_toggle)\"};
  xkb_geometry  { include \"microsoft(natural)\"};
};

Does this help?

The output looks fine. What's the output of the second command mentionend in comment #4?

Do you mean this one?

 /usr/bin/setxkbmap -variant qwerty,basic -layout cz,us -option grp:shift_toggle -model microsoftpro -v

Than it is: (sorry for formatting)

Warning! Multiple definitions of keyboard model\n         Using command line, ignoring X server\nWarning! Multiple definitions of keyboard layout\n         Using command line, ignoring X server\nTrying to build keymap using the following components:\nkeycodes:   xfree86+aliases(qwertz)\ntypes:      complete\ncompat:     complete\nsymbols:    pc+cz(qwerty)+inet(microsoftpro)+us(basic):2+group(shifts_toggle)\ngeometry:   microsoft(natural)

xkb_keymap {\n\txkb_keycodes  { include \"xfree86+aliases(qwertz)\"\t};\n\txkb_types     { include \"complete\"\t};\n\txkb_compat    { include \"complete\"\t};\n\txkb_symbols   { include \"pc+cz(qwerty)+inet(microsoftpro)+us(basic):2+group(shifts_toggle)\"\t};\n\txkb_geometry  { include \"microsoft(natural)\"\t};\n};

Yes, that's it. Output looks fine here as well. So indeed the debug output didn't help us to explain, why we run into this issue during installation.

Jiri, can you reproduce this problem during installation at all?

Juhliarik was able to reproduce the behavior also on a running system. Jozef, could you help here, please?

(In reply to comment #29 from Stefan Dirsch)
> Jiri, can you reproduce this problem during installation at all?

Good question. I don't know, as it all looks weird for me, see comment 11.

I can reproduce the problem in openSUSE 11.0 Alpha3-x86_64 installed
in qemu.

Czech selected in linuxrc, then I started an xterm with
Ctrl+Shift+Alt+x at the first screen of YaST2 (where one needs to
agree to the License).

In that xterm, I can already reproduce the problem.

Unfortunately I still cannot reproduce it in the installed system.

I can find only one call to “setxkbmap” in /var/log/YaST2/*:

    bash-3.2# grep setxkbmap /var/log/YaST2/*
    /var/log/YaST2/y2log: /usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle -model microsoftpro
    bash-3.2#

Calling the same command again manually does *not* fix the problem for me!

(In reply to comment #33 from Mike Fabian)
> I can find only one call to “setxkbmap” in /var/log/YaST2/*:

Well, the second setxbmap was invoded by another changing the keyboard in the Keybaoard settings.

Mike> Calling the same command again manually does *not* fix the
Mike> problem for me!

Sorry, that was nonsense, calling the same command once more *does*
fix the problem!

Although calling the “setxkbmap” command from the y2log file manually
fixes the problem for me, it is a bit weird that the output of
“xmodmap -pke” remains completely unchanged.

Could this be related?:

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

Jiří Suchomel> Good question. I don't know, as it all looks weird for
Jiří Suchomel> me, see comment 11.

Don’t try it in a Qt widget, open an xterm with Control+Shift+Alt+x
and try it there. Then you can reproduce it without being
confused by the encoding problem caused by the missing library.

Another thing I tried:

- Choose some non-Czech language in Linuxrc (I did choose Japanese)
- click through the first few YaST2 screens until you see the
  summary of the installation options
- change the keyboard layout from Japanese to Czech
- test it and it is OK
  (broken in the Qt test widget (comment #11) but OK in an xterm).

Checking the y2log file reveals that setxkbmap has been called twice,
once setting the Japanese keyboard and then setting the Czech
keyboard.

Could it be that the first try sometimes fails?
(i.e. something similar to
https://bugs.freedesktop.org/show_bug.cgi?id=13539 ?)

Another try:

- choose Czech in linuxrc
- click through the YaST2 screens always choosing the default until
  the installation starts
- while YaST2 happily installs packages, open an xterm
  (Control+Shift+Alt+x)
- test for the keyboard problem → it’s OK now!
- check y2log:
  /usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle -model microsoftpro
  appears 3 times!

So maybe we should call setxkbmap always a few times for best effect ☺

Right. Let's run the command at least 3 times to be on the safe side. I'm wondering if this also helps Martin and Josef after installation ?!?

(In reply to comment #39 from Mike Fabian)
> Jiří Suchomel> Good question. I don't know, as it all looks weird for
> Jiří Suchomel> me, see comment 11.
> 
> Don’t try it in a Qt widget, open an xterm with Control+Shift+Alt+x
> and try it there. Then you can reproduce it without being
> confused by the encoding problem caused by the missing library.

This is broken another way: when I try to write czech characters in the xterm, nothing is shown. But the cursor moves - maybe it is a font problem?
Switching to US layout via shift-shift is possible and than I cannot reproduce the original problem. (I tested with Alpha 3.)

Anyway, I don't see why YaST module should be responsible for this bug. The command it calls looks correct and is indeed the same as in previous versions.

Jiří Suchomel> This is broken another way: when I try to write czech
Jiří Suchomel> characters in the xterm, nothing is shown. But the
Jiří Suchomel> cursor moves - maybe it is a font problem?

I don’t think this could be a font problem, xterm uses the “fixed”
font there which certainly *is* available in instsys.¹

Jiří Suchomel> Switching to US layout via shift-shift is possible and
Jiří Suchomel> than I cannot reproduce the original problem. (I tested
Jiří Suchomel> with Alpha 3.)

I can reproduce that with Alpha 3 *but* *only* if I choose Czech
already in linuxrc *and* test at the very first YaST2 screen.

If I choose Czech later or proceed to later YaST2 screens, the problem
goes away, apparently because YaST2 calls setxkbmap *again* and the
second call works.

Jiří Suchomel> Anyway, I don't see why YaST module should be
Jiří Suchomel> responsible for this bug. The command it calls looks
Jiří Suchomel> correct and is indeed the same as in previous versions.

Yes, I think so as well. Seems to be an Xorg problem.

Calling setxkbmap several times seems to be a workaround albeit a
silly one.

-- 
¹ By the way, I encountered an unrelated problem here while testing
with xterm: When testing at the first screen of YaST2,
xterm sometimes has a window frame (icewm running) and sometimes not
(icewm not running). There seems to be a problem that icewm
does not start always or maybe not always that early?

Ok. There might be a way to reproduce it by using a xorg.conf which non-czech keyboard layout (use one from installation to make sure) also after installation. Then run the setxkbmap command once. Verify. Run it a second time. Verify again.

I tried that yesterday night but without success.

(I started a second xserver:

    X :2 & sleep 10; xterm -display :2 &

and then executed the setxkbmap command for Czech. It worked
immediately. Tried on magellan (Factory-x86_64)).

And I did this with a test user which does not have a .xinitrc
and therefore does not do extra calls to setxkbmap (or xmodmap)
while starting X.

I finished the Czech Alpha3 installation using all defaults.
(I used
/mounts/dist/install/openSUSE-11.0-Alpha3/openSUSE-11.0-Alpha3-KDE-i386.iso)

After KDE4 starts, the problem is reproducable.

Calling

/usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle -model microsoftpro

manually fixes the problem.

After restarting the KDE session, the problem is back.

I can reproduce the issue when using an xorg.conf file with the following keyboard section.

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

which should do the same as running

/usr/bin/setxkbmap -layout cz,us -option grp:shift_toggle \
                   -model microsoftpro -variant qwerty,basic

Running this command afterwards fixes the issue.

Created attachment 206794 [details]
xorg-conf-screenshot.png

screenshot of qemu showing the keyboard related sections
of /etc/X11/xorg.conf and /etc/X11/xorg.conf.install.

I can reproduce it the same way as Stefan in comment #51
on my workstation running Factory-x86_64.

When parsing the keyboard configuration from the config file the Xserver is running

"/usr/bin/xkbcomp" \
  -w 1 "-R/usr/share/X11/xkb" \
  -xkm \
  "-" \
  -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" \
  -emp "> " \
  -eml "Errors from xkbcomp are not fatal to the X server" \
  "/tmp/server-1.xkm"

And I can reproduce the issue when running

setxkbmap -print | \
  "/usr/bin/xkbcomp" \
  -w 1 "-R/usr/share/X11/xkb" \
  -xkm \
  "-" \
  -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" \
  -emp "> " \
  -eml "Errors from xkbcomp are not fatal to the X server" \
  "/tmp/server-1.xkm"

I can't reproduce the issue when I'm running

setxkbmap -print | \
  /usr/bin/xkbcomp \
  -w 1 "-R/usr/share/X11/xkb" \
  -  \
  -em1 "The XKEYBOARD keymap compiler (xkbcomp) reports:" \
  -emp "> " \
  -eml "Errors from xkbcomp are not fatal to the X server" \
  :1

instead. So it's somewhat related to the use of xkm instead of an X display.

The keyboard layout description in the Xserver looks completely broken. Right after the Xserver start:

# xkbcomp :1 -xkb bad.xkb
Warning:          Could not load keyboard geometry for :1
                  BadAlloc (insufficient resources for operation)
                  Resulting keymap file will not describe geometry

# setxkbmap -print | /usr/bin/xkbcomp - :1

# xkbcomp :1 -xkb good.xkb
#

Stupid workaround for /etc/X11/xdm/Xsetup:

#
# Fix keyboard layout (Bug #368673)
#
setxkbmap -print | xkbcomp - $DISPLAY

It will help anybody using xdm/kdm/gdm. It won't help users, who are still relying on xinit/startx. It won't help for installation either.

Stupid workaround applied for STABLE/Factory/Beta1.

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

I have alpha3 plus with updated /etc/X11/xdm/Xsetup. The fix in comment #56 does not work reliably. In about 30% of cases I still get the keyboard broken as described in the initial comment.

I'm wondering if there is a timing issue here, although I don't understand it at all.

Could you remove the call from /etc/X11/xdm/Xsetup and run the command afterwards in your Xsession? Does this work reliably?

I'm wondering if there is a timing issue here, although I don't understand it at all.

Could you remove the call from /etc/X11/xdm/Xsetup and run the command afterwards in your Xsession? Does this work reliably?

Yes, running the command from xterm seems to work reliably.

Could you figure out if this is a timing issue by replacing the one liner setxkbmap call in /etc/X11/xdm/Xsetup with

declare -i t=30
while test $((t--)) -gt 0 ; do
  setxkbmap -print | xkbcomp - $DISPLAY
  sleep 0.1
  xkbcomp $DISPLAY -xkb /tmp/xkbcomp.$t && break
  echo "$t to go" > /tm/xkbcomp.togo
done

The other idea is that we need to run the command in /etc/X11/xdm/Xstartup at the beginning of each Xsession instead of when the displaymanager is starting.
It should be safe to add the line above the TabletPC stuff.

(In reply to comment #63 from Stefan Dirsch)
>   xkbcomp $DISPLAY -xkb /tmp/xkbcomp.$t && break

It always ends here in the first cycle, with t=29. However the space is
sometimes broken afterwards. The file /tmp/xkbcomp.29 is always the same.

But the xkbcomp fails when I later call it from xterm.
It seems that it is set correctly in Xsetup and broken later.

In this case I suggest to try what I proposed in comment #64.

The fix from comment #64 seems to work.

Ok. So I'll move it to Xstartup.

fixed.

I have hit the same problem on beta2 with gnome desktop, slovak keyboard layout.

Does it work after manually running

  setxkbmap -print | xkbcomp - $DISPLAY

What's the result (out.xkb) of 'xkbcomp :0 out.xkb' before and after running the command above?

Created attachment 212362 [details]
first output of xkbcomp

xkbcomp :0 out.xkb
Warning:          Could not load keyboard geometry for :0
                  BadAlloc (insufficient resources for operation)
                  Resulting keymap file will not describe geometry
attaching out.xkb as xkbcomb_out1.xkb

Created attachment 212363 [details]
second output of xkbcomp

After setxkbmap -print | xkbcomp - $DISPLAY
the command "xkbcomp :0 out.xkd" had no warning messages
attaching out.xkb as xkbcomb_out2.xkb.

After setxkbmap command it got fixed, but after log-out and log-in, the problem is here again.

Who the hell breaks this during Xsession start? Could you rename setxkbmap command and adjust Xstartup accordingly? Would be interesting if it works then.

And check your .xsession-errors file for setxkmap error messages.

Still no feedback after a week. Please reopen once you can provide the requested feedback. Thanks.

Ladislav, please try to provide requested information.

I had renamed the setxkbmap and changed the name also in /etc/X11/xdm/Xstartup. 
Called init 3 and then init 5 from console but the issue is still there. 
I haven't found any error massages in .xsession-errors regarding setxkbmap.

Ok. Then I suggest to try what I proposed in comment #63. In Xstartup, not Xsetup. And with setxkbmap renamed.

(In reply to comment #82 from Stefan Dirsch)
> Ok. Then I suggest to try what I proposed in comment #63. In Xstartup, not
> Xsetup. And with setxkbmap renamed.
> 

And where exactly should I add the while loop in Xstartup?

It's a replacement for

   setxkbmap -print | xkbcomp - $DISPLAY

There is no such line in /etc/X11/xdm/Xsetup. Therefor I was asking.

xorg-x11.changes:
[...]
* Fr Apr 18 2008 sndirsch@suse.de
- moved stupid workaround to fix keyboard layouts to Xstartup
  (bnc #368673)

(In reply to comment #71 from Ladislav Michnovic)
> I have hit the same problem on beta2 with gnome desktop, slovak keyboard
> layout.

This change is included in Beta2. So you're testing something different.

I have little mess up with Xsetup and Xstartup files.
In addition: I have added the while loop etc. into the Xstartup. The result is that it did not help. I don't see any xkbcomp.* files in tmp, so I assume the code is not executed at all.

(In reply to comment #86 from Stefan Dirsch)
> xorg-x11.changes:
> [...]
> * Fr Apr 18 2008 sndirsch@suse.de
> - moved stupid workaround to fix keyboard layouts to Xstartup
>   (bnc #368673)
> 
> (In reply to comment #71 from Ladislav Michnovic)
> > I have hit the same problem on beta2 with gnome desktop, slovak keyboard
> > layout.
> 
> This change is included in Beta2. So you're testing something different.

I'm confused. The beta2 does have this line in changelog
* Fr Apr 18 2008 sndirsch@suse.de
> - moved stupid workaround to fix keyboard layouts to Xstartup
>   (bnc #368673)
 and it is not fixed.

I have discovered that when I use GDM, your loop from comment #63 in file /etc/X11/xdm/Xstartup is not executed at all. After switch to KDM (KDE 3.x), the loop is executed and the issue with no break space is gone. 

So if the user installs GNOME only sysstem, he/she will hit this issue again.

Created attachment 214427 [details]
mvidner-xkbcomp.29

I am using Beta 2 (xorg-x11-7.3-79, the change is there, Lado) with KDE and autologin.
I applied the loop in comment 63 to /etc/X11/xdm/Xstartup and called init 3, init 5. I got xkbcomp.29 (attached above) and the problem persists.

(In reply to comment #91 from Martin Vidner)
> I am using Beta 2 (xorg-x11-7.3-79, the change is there, Lado)

I know. I was confused by the filename in comment #63.

> with KDE and autologin.
> I applied the loop in comment 63 to /etc/X11/xdm/Xstartup and called init 3,
> init 5. I got xkbcomp.29 (attached above) and the problem persists.

Strange. It works for me. Maybe it is lang dependent or 30 iterations are not enough. I have "0 to go" in file from:
echo "$t to go" > /tmp/xkbcomp.togo

I'd say that the hack "setxkbmap -print | xkbcomp - $DISPLAY" always works correctly but something breaks it later under some circumstances. The loop from
comment 63 is IMHO useless for detection of this problem.

I am trying a conclusion:

1) GDM ignores /etc/X11/xdm/Xstartup. Does not happen with xdm/kdm3. Not sure
   about kdm4. Ladislav, could you check this?
2) For Martin something later breaks the keyboard layout again. Maybe an
   existing $HOME/.Xmodmap. Martin, please check this.

(In reply to comment #92 from Ladislav Michnovič)
> Strange. It works for me. Maybe it is lang dependent or 30 iterations are
> not enough. I have "0 to go" in file from:
> echo "$t to go" > /tmp/xkbcomp.togo

This is weird, because this would mean that the xkbcomp call did never work.

KDE4-kdm is O.K. The while loop is executed and the space issue is gone. 
I have again "0 to go" in file /tmp/xkbcomp.togo.

Martin's turn.

> 1) GDM ignores /etc/X11/xdm/Xstartup. Does not happen with xdm/kdm3. Not sure
>    about kdm4. Ladislav, could you check this?

Indeed gdm ignores /etc/X11/xdm/Xstartup. Either this needs to change or 

  setxkbmap -print | xkbcomp - $DISPLAY

needs to be added to the appropriate place below /etc/gdm/. Vincent, could 
you take care of this one?

(In reply to comment #97 from Stefan Dirsch)
> > 1) GDM ignores /etc/X11/xdm/Xstartup. Does not happen with xdm/kdm3. Not sure
> >    about kdm4. Ladislav, could you check this?
> 
> Indeed gdm ignores /etc/X11/xdm/Xstartup. Either this needs to change or 
> 
>   setxkbmap -print | xkbcomp - $DISPLAY
> 
> needs to be added to the appropriate place below /etc/gdm/. Vincent, could 
> you take care of this one?

Yes, I will do it. Just to get things clear: /etc/X11/xdm/Xstartup should be run before /etc/X11/xdm/Xsession? Btw, any reason to not run it from Xsession?

Yes, AFAIK Xstartup is running before Xsession. There is a config file xdm-config in /etc/X11/xdm/xdm-config, which specifies, which scripts to run.
There these are seperated.

  DisplayManager.*.startup:       /etc/X11/xdm/Xstartup
  DisplayManager.*.session:       /etc/X11/xdm/Xsession

Hope this helps.

/etc/gdm/Xsession now does:
 /bin/bash /etc/X11/xdm/Xstartup && exec /etc/X11/xdm/Xsession $1 $GDM_LANG

Sounds good. Thanks!

Martin, still waiting for your feedback. See my comment #94.

The problem is still here on Beta3, KDE4 and autologin with new created user ($HOME/.Xmodmap doesn't exist).

(In reply to comment #103 from Petr Ostadal)
> The problem is still here on Beta3, KDE4 and autologin with new created user
> ($HOME/.Xmodmap doesn't exist).

Maybe because you're using gdm. Still waiting for feeback by Martin.

Sorry for the delay. I have no ~/.Xmodmap.

Petr, please add

  setxkbmap -print | xkbcomp - $DISPLAY

at the end of /etc/X11/xinit/xinitrc.common. If this still doesn't help I'm nearly lost here. Another desperate idea is to additionally add 

  -noreset

to Xserver command line, which needs to be done differently for each and every displaymanager. :-( For xdm this is in /etc/X11/xdm/Xservers.

When I use autologin, it is broken. When I end the X session and log in from KDM, it works. In both cases, /tmp/xkbcomp.29 is the same.
I tried strace on both ends of the pipe in the working an failing case, but 
could not make anything from the difference.

I tried xinitrc.common and it seems to work there.

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

Petr? See my comment #106.

Putting it in xinitrc.common does not seem to work reliably :-( In one case after autologin, it was broken even though the commands had run.

> to comment #106 :
>  setxkbmap -print | xkbcomp - $DISPLAY

> at the end of /etc/X11/xinit/xinitrc.common. If this still doesn't help I'm
> nearly lost here.

It dosn't work.

Did you try reproduce it? It is easy, set Keyboar Layout to "Czech" and with pressing left shift and  right shift in the sam etime, you can swith between czech an US layout. 
US layout doesn't work and has the problem with space.

brucell:/home/bruce11.2 # ls #one space after ls
bash: ls : command not found

when you switch back by pressing L & R shitfs to czech layout, it works well.

autologin seems to be the problem here. I have no idea, what it exactly does. :-( It seems to ignore even /etc/X11/xdm/Xsession !?! I bet everything
is fine when using xdm ...

Ladislave, Martin, Petr, can you confirm, that it always works - *** with autologin disabled *** - when putting the line

  setxkbmap -print | xkbcomp - $DISPLAY

into /etc/X11/xinit/xinitrc.common?

Later I can take care about autologin - in case I will ever find the persons who know anything about it. I'm sure it's handled completely differently for
gdm, kdm3 and kdm4.

I wonder if it would be easier to debug the original problem. It almost looks like a memory corruption in X server. Is it possible to run X server in valgrind?

Vladimir - sure; that's the first thing I tried when hunting for the (surprisingly similar bug) #369263# - to do it you have to drop the suid bit on /usr/bin/Xorg.
However - ~all the results are false positives (from ioctls) there; and (somehow) the X server seems to re-fork itself in a strange way that valgrind doesn't appear to understand - and the tracing stops after a short while [ it seemed to me at least ].
So - while I share your suspicion of some intermittent memory corruption, or uninitialized memory underlying this - sadly, it's not easy to find it with valgrind [unless I did something stupid of course ;-]

Right. Still the reporters can help - by giving feedback ASAP.

My system start to forget keyboard layout selection. I don't know what's wrong. I'll do completely new installation with beta3+.

> Later I can take care about autologin - in case I will ever find the persons
> who know anything about it. I'm sure it's handled completely differently for
> gdm, kdm3 and kdm4.

Without autologin with kdm it works well.

After fresh install of Beta3+ with GNOME, I can't reproduce the problem.

Ladislave, Martin, Petr, please make sure to test with gdm, kdm3 and kdm4.

Sorry, but I'm unable to test it. The sax is totally broken that I don't even know what keyboard layout I have. It got changed after gdm restart and sax2 shows something else. 

Ok. Ladislav, so your feedback of comment #119 is invalid.

Ok, but at least Petr and Martin are still left to give me some valid feedback. BTW, 'setxkbmap -print' shows you the current keybaord layout.

With a clean install of Beta3plus, KDE4 autologin, it has worked fine 3 times now, also after a relogin.

Martin, which displaymanagers did you test?

Now I have tested with kdm4, gdm, xdm, wdm.

(But BTW the whole logout/login process has become very slow in any of the DMs. Anyone know why?)

Martin, kdm3 is still missing. :-(

It also works with kdm3. :-)

> comment #124
>
> With a clean install of Beta3plus, KDE4 autologin, it has worked fine 3 times
> now, also after a relogin.

I tested autologin with clean installation Beta3plus, KDE4 autologin and it still doesn't work for me ;( (the difference between me and Martin is that he tested on i386 and I tested on x86_64).

I have updated the kernel to get rid of the acpi=off (bug 391845 comment 13) and guess what:
The delay is gone and the keyboard problem is back. (With kdm3, but I am not going to try all of them now.)

(In reply to comment #129 from Petr Ostadal)
> > With a clean install of Beta3plus, KDE4 autologin, it has worked fine 3
> > times now, also after a relogin.
> 
> I tested autologin with clean installation Beta3plus, KDE4 autologin and it
> still doesn't work for me ;( (the difference between me and Martin is that
> he tested on i386 and I tested on x86_64).

The difference is also that you tested with autologin, although I asked you
to test without autologin. :-(

(In reply to comment #130 from Martin Vidner)
> I have updated the kernel to get rid of the acpi=off (bug 391845 comment 13)
> and guess what:
> The delay is gone and the keyboard problem is back. (With kdm3, but I am not
> going to try all of them now.)

This is still without autologin?

Still with autologin (which is the default installation settings). On a relogin, it works.

Actually, Stefan, in comment 51 you write that you are able to reproduce the problem locally, right? You surely have other work to do, but we are losing time just because of testing latency.

Oh, and thanks for working on this on a holiday.

I'm encouraged that Vincent can reproduce the very similar #369263# easily - and I assume can help get you setup with that Stefan.

(In reply to comment #132 from Martin Vidner)
> Still with autologin (which is the default installation settings). On a
> relogin, it works.

Please test *without* autologin.

> Actually, Stefan, in comment 51 you write that you are able to reproduce the
> problem locally, right?

Only during installation, never afterwards. :-(

> You surely have other work to do, but we are losing time just because of
> testing latency.

We're mostly using time, since you're testing different things than I proposed. :-( Again. Please test *without* autologin for all relevant displaymanagers, i.e. gdm, kdm3 and kdm4. Nobody cares about xdm/wdm.
I gave up WRT autologin for now.

(In reply to comment #134 from Michael Meeks)
> I'm encouraged that Vincent can reproduce the very similar #369263# easily -
> and I assume can help get you setup with that Stefan.
 
This would be wonderful, if he could help me to understand autologin of gdm.

(In reply to comment #135 from Stefan Dirsch)
> (In reply to comment #134 from Michael Meeks)
> > I'm encouraged that Vincent can reproduce the very similar #369263# easily -
> > and I assume can help get you setup with that Stefan.
> 
> This would be wonderful, if he could help me to understand autologin of gdm.

Just tell me what you need to understand: as far as I can tell, the exact same things are happening with autologin and without autologin. See bug #369263 comment #56 for an interesting experiment that makes me believe that the thing that causes different behaviors is the fact that the user clicks or types some text.

Oh, and using "init 3" and "init 5" is much faster than rebooting to test autologin. Thanks Michael ;-)

(note that I reproduced the issue in bug 369263 with kdm3 autologin).

> Just tell me what you need to understand: as far as I can tell, the exact
> same things are happening with autologin and without autologin.

This ins what I wanted to kow. So exactly the same files in /etc/X11/xdm/ are read by gdm during autologin. 

If this issue only happens with autologin during boot I would assume that we would have a race conditition with the kbd init script (again).

Ok. I think the best I can do for now is adding

  setxkbmap -print | xkbcomp - $DISPLAY

to the end of /etc/X11/xinit/xinitrc.common and set this bugreport to LATER.
Hopefully we figure out one day, what the real issue is and how to fix it properly.
  

done.

xorg-x11.changes:
-------------------------------------------------------------------
Fri May 23 15:37:31 CEST 2008 - sndirsch@suse.de

- moved setxkbmap call from /etc/X11/xdm/Xstartup to
  /etc/X11/xinit/xinitrc.common (bnc #368673)

I'm very uncomfortable with closing this bug -- especially since the workaround you've implemented doesn't even work.  Saying "we'll spend our time on something else for now" is maybe ok, but I think the bug should stay open until it is actually fixed.

The bug is still open. It's just set to LATER.

KDE4 + autologin + RC1 - still doesn't work

Yes, I gave up WRT autologin.

FWIW, in GNOME, we now have an ugly workaround in place for 11.0: the daemon that handles xkb in GNOME will run setxkbmap after the first time it configures the layout, and this should be enough to unbreak things (see bug 369263). If running setxkbmap fixes your issue, then I guess such a workaround can also be added to KDE.

Finally I was able to reproduce this issue on RC1. Apparently it happens with gdm, kdm3 and kdm4, but only when autologin is enabled and only for the first login. It is not related to the boot procedure at all, i.e. you can trigger it with "rcxdm restart". It even happens with a failsafe Xsession (=xterm only). I still have no idea what's happening there.

The same issue when logging in a user without a password by double click, i.e. not touching the keyboard at all. This means that it is not related to autologin, but to keyboard input during login.

I agree with Vincent, that this is a duplicate of Bug #369263. The behaviour is decribed there in comment #56. The upstream bug is

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


*** This bug has been marked as a duplicate of bug 369263 ***

I don't have good news. It is still reproducable on GM. KDE4, autologin enabled, Slovak keyboard.

(In reply to comment #148 from Ladislav Michnovič)
> I don't have good news. It is still reproducable on GM. KDE4, autologin
> enabled, Slovak keyboard.

But that is no news:

(comment #143 from Stefan Dirsch)
> Yes, I gave up WRT autologin.



*** This bug has been marked as a duplicate of bug 369263 ***

Did I ever claim it is fixed now? It's a duplicate of Bug #369263. See my comment #147. Thanks.

(In reply to comment #150 from Stefan Dirsch)
> Did I ever claim it is fixed now? It's a duplicate of Bug #369263. See my
> comment #147. Thanks. 

I have overlooked that. Sorry.