Bug 682903

Hmm. What's the entry for /etc/sysconfig/keyboard:KEYTABLE? Please also attach 
/etc/X11/xorg.conf.d/90-keytable.conf.

(In reply to comment #1)
> Hmm. What's the entry for /etc/sysconfig/keyboard:KEYTABLE? Please also attach 
> /etc/X11/xorg.conf.d/90-keytable.conf.


/etc/sysconfig/keyboard:KEYTABLE

KEYTABLE="de-latin1-nodeadkeys.map.gz"


/etc/X11/xorg.conf.d/90-keytable.conf

Section "InputClass"
        Identifier "LocalKeyboard"
        MatchIsKeyboard "on"
        Option  "XkbLayout"     "de"
        Option  "XkbVariant"    "nodeadkeys"
EndSection


So, nothing wrong there. Isn't it?

Yes, X.Org keyboard configuration looks correct. Seems to be a kdm issue. Can you reproduce this issue also with gdm and/or xdm?

I can reproduce the error with xdm. I did a fresh install of gdm, since it was not installed, and everything is fine there.

Some additional information regarding my system, maybe this can help: I did a fresh install of OpenSUSE 11.4, but I imported the existing users from a previous 11.3 installation. And of course I reused the existing home directories.

What worries me is that even with xdm you get the english keyboard layout for login. xdm doesn't change the keyboard layout being set initially by Xserver . Could you attach /var/log/Xorg.0.log.

Created attachment 421747 [details]
Xorg log file

Let's see if you can find something suspicious.

(In reply to comment #6)
> Created an attachment (id=421747) [details]
> Xorg log file
> 
> Let's see if you can find something suspicious.

[  6363.490] (**) Option "xkb_rules" "evdev"
[  6363.490] (**) Option "xkb_model" "evdev"
[  6363.490] (**) Option "xkb_layout" "de"
[  6363.490] (**) Option "xkb_variant" "nodeadkeys"

Looks good, but maybe the cached keyboard layouts in /var/lib/xkb/compiled
are wrong. Could you remove /var/lib/xkb/compiled/server-* and try once again
with xdm?

I deleted every server-* file after I did an "init 3" as root and then I did an "init 5" to start X again. Nothing changed. Still qwerty instead of qwertz. Hopefully the init 3/5 was enough to test the keyboard layout.

Hmm. I do not understand that behaviour.

Me neither...

I guess this is not a common problem, since I have two other openSUSE 11.4 systems running without this strange behavior. Nevertheless I planned to do a separate second installation of the 11.4 on the same machine as a playground. Maybe I can reproduce the bug.

Still, thanks for your effort!

Are there any Xkbmap* files in /etc/X11? See /etc/X11/xdm/Xsetup why I'm asking this question.

Created attachment 422544 [details]
ls -R of /etc/X11

As far as I can see there are no Xkbmap* files in /etc/X11. I've attached the output of 'ls -R' so you can check it. Maybe I have overseen something.

(In reply to comment #12)
> Created an attachment (id=422544) [details]
> ls -R of /etc/X11
> 
> As far as I can see there are no Xkbmap* files in /etc/X11. I've attached the
> output of 'ls -R' so you can check it. Maybe I have overseen something.

I can't see such a file either.

Ok. I'm afraid I need to give up on this one. :-(

I found the error, or at least, I have more detailed information now.

The "bad boy" is my bluetooth keyboard (Microsoft Bluetooth Mobile Keyboard 6000). Starting KDM (or XDM is guess, haven't tried it yet) with only the BT keyboard connected triggers only the english qwerty keyboard layout. Now, connecting a USB keyboard switches the layout to german, but only after I have pressed a button on the USB keyboard. Just connecting it doesn't seem to work.

Sometimes disconnecting the USB-keyboard changes the layout back to english, but this only happened 1 or 2 times from >10 logins to KDM. So this I cannot reproduce.

The interesting question would be: Why does gdm recognizes the correct language of my BT keyboard?

Maybe also interesting for you: I set up my BT keyboard with the help of KDEs Bluedevil.

So, a very special setup I guess I have here. I reopened the bug. Nevertheless I am kind of used to it now, but maybe it is interesting for you to now that BT keyboards are a little bit bitchy. ;-)

What a mess. This sounds like evdev reinitializing the keyboard (with us keyboard layout) when the new keyboard connects. Could you attach the new lines of Xorg.0.log when you connect the new keyboard?

Created attachment 423825 [details]
Xorg.0.log

I am not sure if I would have extracted every important piece of information, so I attached the whole file.

Following situation is represented within the Xorg.0.log file:

I started the system without the USB keyboard, only the bluetooth keyboard was activated. Results as described in the bug report: english keyboard layout.

I guess the interesting part starts at 81.208. It's the first time I can seen my bluetooth keyboard. Nevertheless it says "Option "xkb_layout" "de"", but I only have the english layout.

Now at 201.005 I connected the USB keyboard. The layout changes to german within kdm.

> [    81.211] (EE) Microsoft Bluetooth Mobile Keyboard 6000: failed to 
> initialize for relative axes.
>[    81.211] (II) Microsoft Bluetooth Mobile Keyboard 6000: initialized for
> absolute axes.

Maybe that's the issue why keeping "german" keyboard doesn't work. Is there a trackball/touchpad whatever built in?

Ok. I just verified that connecting a new keybaord indeed reinitializes als the keyboard layout to global settings. For unknown reasons this fails with your Bluetooth keyboard and what you see is a fallback to us keyboard layout.

Can you switch to german keyboard layout at all with the Bluetooth keyboard connected?

terminal_1) tail -f /var/log/Xorg.0.log
terminal_2) setxkbmap "de(nodeadkeys)"

The keyboard does not have a trackball or a trackpad.

It seems I cannot switch to a german layout:

setxkbmap "de(nodoeadkeys)"
Error loading new keyboard description


Xorg.0.log
[  1207.427] (EE) Error loading keymap /var/lib/xkb/compiled/server-CCEC699EFC4E1FC4FBE31CD23A5A76B547F0A0D3.xkm


I did this while logged in into KDE4, but in KDE4 I had no problems with the keyboard layout.

Ok. Looks like loading a keyboard layout doesn't work once you've connected your bluetooth keyboard.

Unfortunately we do not have the ressources to address that issue
still for openSUSE 11.4. Could you please test again with
a current Milestone of openSUSE 12.1, whether the issue still
exists and give me feedback about the result? Thanks.

Still waiting for a response for more than a month now. Please reopen once
you can provide the requested feedback. Thanks.

This bug is here still present in OpenSuSE 12.2 with Logitech K750 keyboard
(wireless):
Elsewhere in the system the keyboard layout is correctly set but in KDM its
always the us-layout used.
As soon as any key on a parallel connected wired keyboard is pressed, the
wireless K750 keyboard changes the correct layout as well.

Created attachment 505736 [details]
Xorg log file from OpenSuSE 12.2

Ok. So you hijacked a similar bug. Oh well...

November and 12.2 + Update are still affected (here with a K800) with the unify 
dongle.
Now I found this bug I can always type a letter on the internal lappy keyboard :-(

i can also reproduce this bug in 12.2 with KDE 4.9.5 from obs:K:R:49.

My keyboard's the Logitech K750 with unified dongle.

Should there be a new bug opened, or will this one lead to a fix at some point?


I'd think this is actually quite serious, just imagine having a Y in your username or password. I have one in my local username...

Unfortunately confirmed here with a laptop ( layout is fr_CH )
Work perfect if the laptop is alone.
Once I dock it mostly and usb hub, + logitec K750 illuminated keyboard and mouse on a unified dongle. kdm propose the external keyboard in en_US but the internal dell is still in fr_CH 

So the symptom are a variant of the initial one, but still look like the same.
I didn't try yet to remove and re-plug the keyboard once kdm is running.

@Stefan I'm actually on factory-snapshot, so if you need a precise log of something I should be able to give it a try.

I found a quirky little detail...

if i after booting type a character on my laptop's builtin keyboard the external keyboard correctly flips over to german!

Same here with kde 4.10 (under 12.2 or 12.3) so xorg version change did affect the issue.

If I use one touch of the internal lappy keyboard (like control) and then use the external logitech the mapping become correct.

?

I have made a fresh install of Opensuse 12.3 and have the same problem with Logitech K750 with unified dongle. The kdm manager uses US_keyboard.
If I connectect a usb keyboard and press one touch, then I get a french keyboard.
When I start kde, everything beomes coorect.
It's very annoying and don't know how to deal with this.
Thanks,
vincent
I've installed kde 4.10.

I also made a fresh install of Opensuse 12.3.
Same issue here. K750 with unified dongle. The keyboard layout at the login screen and on the desktop is "us". In the Console its set correctly.

I've tried MANY variants of (in file /etc/X11/xorg.conf.d/10-evdev.conf:


Section "InputClass"
        Identifier "evdev keyboard catchall"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        Driver "evdev"
        Option "XkbLayout" "ch"
        Option "XkbVariant" "nodeadkeys"
        Option "XkbRules" "evdev"
        Option "XkbModel" "evdev"
EndSection


Most interesting:
In /var/log/Xorg.0.log the entry "matches" and selects ch.

In opensuse 12.1 with sysvinit (not systemd) it seems working for me.

BTW I've just tested another keyboard: UltraX Permium Keyboard (PN 868029-025 / PID ST727J00379). This is not a Wireless Keyboard, but has the same Problem.

Please ignore my comment from 2013-08-28 06:50:33 UTC.
There was a special condition. After restoring the image, it's not affecting the UltraX Premium Keyboard anymore

this applies to non-bluetooth keyboards as well, I have a Logitech k750 attached to my laptop, the internal keyboard of the laptop switches to German just fine, the external keyboard doesn't. strangely enough, pressing a key on the INTERNAL keyboard switches the EXTERNAL keyboard to German, and then all is well...

Same problem here with a custom-build keyboard with builtin touchpad.
/etc/sysconfig/keyboard: KEYTABLE="de-latin1-nodeadkeys.map.gz"

/etc/X11/xorg.conf.d/90-keytable.conf:
Section "InputClass"
        Identifier "LocalKeyboard"
        MatchIsKeyboard "on"
        Option  "XkbLayout"     "de"
        Option  "XkbVariant"    "nodeadkeys"
EndSection

Layout on console: German
Layout on kdm: us
Layout in kde: German

Test on KDE: Cursor in username-field. I press "-" on the keyboard and get "/" in the username field.
I now connect a microsoft USB-Keyboard. Pressing "-" on the custom keyboard I get "/" in the username field. Pressing "-" on the usb-keyboard leads to a "-" as it should be. Now pressing "-" again on the custom keyboard I get "-". After unconnecting the USB keyboard the layout on the custom keyboard is german...till the next reboot.

So the custom keyboard has the right layout after connecting another keyboard and pressing a key on it.

Strange behavior....but very annoying.

Sorry,, System is opensuse 12.3

Ok, seems to be a problem of Xorg.
Stopped al xdm,kdm and Xorg.
Startet Xorg with "/usr/bin/X :0 vt07", then I start a xterm.
With the standad-keyboard I have a us-layout (should be german).
Plugged in a usb keyboard and pressed some keys on the standard keyboard....still us.
Pressed a key on the usb keyboard. Layout on the usb keyboard is german. Pressed a key on the standard keyboard....layout is now german too.

All tests on openSUSE 12.3

I can reproduce this bug on 13.1 with a Logitech K750 cordless desktop.

Is there a workaround for this? The bug is over 3 years old by now.

I still have the same problem here. I can reproduce the bug on a fresh OpenSUSE install where I set my Layout and Language to German or other Non-US

I have this file in suspicion:
/etc/X11/xdm/keytable

there is a variable $cache_keytable that I do not understand. I'm trying to set "layout=de" as a workaround and report back if it works.

changing the fallback "layout=us" in /etc/X11/xdm/keytable did not help at all. 

I hope somebody will find a workaround soon because it is very annoying on multi user systems with complex passwords...

I just installed a fresh system without having the bug. The only difference: I use a external attached Keyboard on a Laptop through a Dockingstation and did the following:

1) at boottime of the install medium I selected some other language as keymap and as language (F2)

2) during the installation process i also selected different languages and then set the one I want so I changed the value before actually confirming my selection.

3) result was a System with the selected keymap.

so either this problem only exists if the language has never been manually selected and instead just being autodetected or it is a problem that only occurs with certain hardware.
I'm trying the same install procedure on my PC with Logitech Keyboard (unifying device) connected. If i manage to get a german keymap after the installation maybe I can confirm that its just some keymap selection bug in the opensuse installer.

was the keyboard connected to the docking station by PS2 or by USB?

Product is no longer supported. In case the issue is still reproducable on a maintainerd product (at that momement: openSUSE 13.1 or later), feel free to reopen.

I can still reproduce this on both openSUSE 13.1 and openSUSE 13.2.

Thanks!

Hi.

There is a patch at

   https://bugs.freedesktop.org/show_bug.cgi?id=49950#c11

that should fix this issue. A user having this problem (on multiple distributions, openSUSE included) applied it to his Debian system and resolved the problem. I think that it worths a try.

Greetings.

Added patch to xorg-x11-server-7.6_1.14.3.901 from a opensuse 13.1 and built a new rpm....

Changing the keyboard layout is working for us now.....

Hmm. Still not upstream that patch.

(In reply to Stefan Dirsch from comment #51)
> Hmm. Still not upstream that patch.

Does it mean that the patch cannot be applied on openSUSE? I'd like to know it to build the package for my own if not possible.

I didn't say that. Usually we don't add patches, which haven't been upstreamed yet. Otherwise you end up with no longer maintainable and partly broken sources. We don't want that.

(In reply to Stefan Dirsch from comment #53)
> I didn't say that. Usually we don't add patches, which haven't been
> upstreamed yet. Otherwise you end up with no longer maintainable and partly
> broken sources. We don't want that.

But you didn't say the opposite either (and you haven't said if it's going to be included or not in your answer), hence my question, :D. Note that I'm not complaining, it's just that I'd like to know the procedure to act in consequence. I understand the "not upstreamed, not included" policy.

The procedure is help to get this patch upstreamed, e.g. give Peter Hutterer a friendly reminder in the upstream bug report:

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

Looking at the upstream ticket, there is no real solution, yet. 
Background: the devices causing problems are devices which are both keyboard and pointer. However X does not support this well: you are either associated to the 'master keyboard' or to the 'master pointer'. Trying to work around this introduces the issues you are seeing. Any further hacks to fix this will introduce issues elsewhere. The solution would be for the driver (evdev or libinput) to create two separate devices for X. This needs to be coded, though and there is no implementation for it, yet.

Currently there are two tickets open:
For evdev: https://bugs.freedesktop.org/show_bug.cgi?id=92897
For libinput: https://bugs.freedesktop.org/show_bug.cgi?id=92896

Currently a first proof-of-concept implementation for libinput exists. There is nothing in sight for evdev. Once an implementation becomes available, it will show in Tumbleweed/Leap.

Therefore I would like to close this ticket with 'UPSTREAM'.