Bug 518281

Please attach 

- /etc/sysconfig
- /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi
- /var/log/Xorg.0.log

*seperately* in *plain/text* format.

Created attachment 302077 [details]
Xorg.0.log

Created attachment 302079 [details]
11-keymap.fdi

Created attachment 302082 [details]
/etc/sysconfig

Since /etc/sysconfig is a directory I send it to you as tgz.

(In reply to comment #4)
> Created an attachment (id=302082) [details]
> /etc/sysconfig

keybaord: KEYTABLE="es.map.gz"

(In reply to comment #5)
> Since /etc/sysconfig is a directory I send it to you as tgz.

Typo. I wanted to write /etc/sysconfig/keyboard. :-(

(In reply to comment #3)
> Created an attachment (id=302079) [details]
> 11-keymap.fdi

<merge key="input.xkb.layout" type="string">es</merge>

Up to here everything looks fine.

(In reply to comment #2)
> Created an attachment (id=302077) [details]
> Xorg.0.log

(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"

xkb_layout should be "es" here. I do not understand this and I can't reproduce
either.

This one looks weird:

  (EE) config/hal: couldn't initialise context: (null) ((null))

hald was not running yet when X started? Whatever

==> WORKSFORME

P.S:: eyboard layout is a user setting anyway and needs to be set by user in
the Xsession (KDE4 here) anyway.

Same Problem here for me on two boxes with german keyboards (also milestone3).

The solution for me was to add the entry

Option "AutoAddDevices" "off"

into the "ServerFlags" section of xorg.conf, so i assume a problem with hal...

Alex, same questions to you.

Please attach 

- /etc/sysconfig/keyboard
- /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi
- /var/log/Xorg.0.log

*seperately* in *plain/text* format.

Of course without having set 

  Option "AutoAddDevices" "off"

Created attachment 303530 [details]
/etc/sysconfig/keyboard

Created attachment 303533 [details]
/usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi

Created attachment 303534 [details]
/var/log/Xorg.0.log

(In reply to comment #10)
> Created an attachment (id=303530) [details]
> /etc/sysconfig/keyboard

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

(In reply to comment #11)
> Created an attachment (id=303533) [details]
> /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi

     <merge key="input.xkb.layout" type="string">de</merge>
     <merge key="input.xkb.variant" type="string">nodeadkeys</merge>

(In reply to comment #12)
> Created an attachment (id=303534) [details]
> /var/log/Xorg.0.log

(II) XKB: reuse xkmfile /var/lib/xkb/compiled/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm
[...]
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"

Do we have some cache issue here? Could you remove this file

  rm /var/lib/xkb/compiled/server-B20D7FC79C7F597315E3E501AEF10E0D866E8E92.xkm

and try again?

Im sorry, that didnt helped, problem still persits...

It's a bit weird. There's another cache file, which is apparently used.

  /var/lib/xkb/compiled/server-D378AD8F86E560F712A83EE36E4E5E92C595B9BD.xkm

Could you remove this as well and restart your Xserver?

No, that neighter didnt the trick - shall i try to delete all .xkm files?

I don't think this would help unless they are loaded by the Xserver, but you can try.

Cannot reproduce this issue. Just installed Milestone 3 (KDE) with spanish keyboard and it's active.

/etc/sysconfig/keyboard:
  KEYTABLE="es.map.gz"

/usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi:
  <merge key="input.xkb.layout" type="string">es</merge>

/var/log/Xorg.0.log:
  (**) Option "xkb_rules" "evdev"
  (**) Option "xkb_model" "evdev"
  (**) Option "xkb_layout" "es"

Thus I can only close this one as WORKSFORME.

Last weekend I did a new fresh Milestone4 install and problem persists, then we can't close it.

IMHO, bugs 520012 and 524200 are identical: X keyboard is set to "us" instead to the selected one in installation.

In text console, keyboard works as espected.

(In reply to comment #19)
> IMHO, bugs 520012 and 524200 are identical: X keyboard is set to "us" instead
> to the selected one in installation.

I agree with Bug #520012. Bug #524200 is something different.

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

X works fine without hal being started, it will wait for it to start up. but it seems there is a bug that it does not set the keyboard layout. Why is the keyboard a user setting, btw? I don't think two users on a system have different keyboards in front of the computer.

(In reply to comment #22)
> X works fine without hal being started, it will wait for it to start up. but it
> seems there is a bug that it does not set the keyboard layout. 

This would be an explanation for the logfile in comment #2, for the logfile in comment #12 it is not.

> Why is the keyboard a user setting, btw? I don't think two users on a system 
> have different keyboards in front of the computer.

Why not?

I'm sorry but today I did a new fresh M5 install and problem persists, so it's necessary to reopen this bug :-(

Looking at /etc/X11/xorg.conf, I've found the solution:

  # Driver "kbd" will be disabled unless 'Option "AutoAddDevices" "off"' 
  # is set in "ServerFlags" section.

but this option is missing in ServerFlags section.

In fact, adding this parameter, everything is fine again :-)

So, please add it to default xorg.conf and close then this bug as fixed.

Thanks.

This is meant as a hint how to enable this section! It's not the solution! I still can't reproduce the issue, even if hald is not running when X starts and starting hald afterwards.

I have the same problem with Milestone 5. Instead German keyboard layout I got us.

(In reply to comment #26)
> I have the same problem with Milestone 5. Instead German keyboard layout I got
> us.

I don't see that issue either. I'm using a german keyboard without any xorg.conf
and no keyboard configuration enabled in KDE or any .xinit/.xsession script.

(In reply to comment #27)
> I don't see that issue either. I'm using a german keyboard without any
> xorg.conf
> and no keyboard configuration enabled in KDE or any .xinit/.xsession script.

After a new install of Milestone 5 I _have_ a xorg.conf, however removing it does not help.

> After a new install of Milestone 5 I _have_ a xorg.conf.

Known issue, which is already tracked. BTW, that's the xorg.conf from installation without any Input section.

I do not have the problem (us keyboard) with a fresh install of the KDE Live CD from Milestone 6 (before I did a DVD install). However is this bug not the same as bug 531818?

No, the brazilian keyboard layout is *very* special. Bug #531818 I can reproduce whereas this bug I cannot.

There is another bug with the same content against KDE Workspace (bug 498314). Still present for some with Milestone 6. Maybe it is a KDE issue as I have found no report for the problem with gnome.

In M6 i just had to go to yast -> language and change from us to german - so i think it is an issue while installing...
(I installed M6 from kde4 live cd, build 235, x84_64)

Also the wrong keyboard settings was applied to the whole system - console and x11...

(In reply to comment #33)
> In M6 i just had to go to yast -> language and change from us to german - so i
> think it is an issue while installing...
> (I installed M6 from kde4 live cd, build 235, x84_64)

Sounds like /etc/sysconfig/keyboard:KEYTABLE is not written during LiveCD installation appropriately. Or the user changed the keyboard configuration via the desktop (user setting!) and expected this to be the global keyboard configuration for a LiveCD installation as well.

> Also the wrong keyboard settings was applied to the whole system - console and
> x11...

Makes perfectly sense. In a xorg.conf-less world global keyboard layout is now
defined via /etc/sysconfig/keyboard:KEYTABLE (there is a mapping to X11 keyboard layout).

(In reply to comment #34)
> Sounds like /etc/sysconfig/keyboard:KEYTABLE is not written during LiveCD
> installation appropriately. Or the user changed the keyboard configuration via
> the desktop (user setting!) and expected this to be the global keyboard
> configuration for a LiveCD installation as well.

I haven't changed anything in KDE itself - this happend direct at first boot. Also KDE was completly in English (so language settings seems to be affected too).
All I did was to change the language setting in yast to german - after that all is fine.
What makes this kind of a showstopper for me is that i use special chars in my passwords - means i can't log into the system, before i messed up with the US keys for these special chars (if anyone would use a german ä,ü,ß or something like that, there would be _no_ way to log in, if i'm right...)

Well, I'm afraid I dont know enough about LiveCD and LiveCD installation. How is a user supposed to define the keyboard layout when running the LiveCD? Running the appropriate KDE/Gnome configuration tool? Anything else, i.e. maybe system-wide? How is the system-wide keyboard configuration done when installing a LiveCD?

(In reply to comment #36)
> How is the system-wide keyboard configuration done when installing
> a LiveCD?

Installer asks on the first screen - see http://en.opensuse.org/Image:OS11.1-live-inst-1.png

(In reply to comment #36)
> Well, I'm afraid I dont know enough about LiveCD and LiveCD installation. How
> is a user supposed to define the keyboard layout when running the LiveCD?
> Running the appropriate KDE/Gnome configuration tool? Anything else, i.e. maybe
> system-wide?

I switch(ed) to german in the grub menu, like you can do in the dvd too - but i assume most users will use the english environment to install....

Wich brings up another question - what will happen if a user set the password to e.g. '3$g2!n-6' in the english liveCD on an non-us keyboard (at least he thinks he do so, because he can't see it...) and select another language in the first install dialog?

Sorry for the double post.

Do you get or don't you get correct entries in /etc/sysconfig if you select german before booting?

(In reply to comment #37)
> Installer asks on the first screen - see
> http://en.opensuse.org/Image:OS11.1-live-inst-1.png

(In reply to comment #38)
> I switch(ed) to german in the grub menu, like you can do in the dvd too - but i
> assume most users will use the english environment to install....

Thanks. So we have consistent and expected behaviour.

(In reply to comment #38)
> Wich brings up another question - what will happen if a user set the password
> to e.g. '3$g2!n-6' in the english liveCD on an non-us keyboard (at least he
> thinks he do so, because he can't see it...) and select another language in the
> first install dialog?

On a LiveCD specifying the password is not the first thing you do, right? Thus I believe the user notices this issue and changes the keyboard layout before changing/entering the password.

> On a LiveCD specifying the password is not the first thing you do, right? Thus
> I believe the user notices this issue and changes the keyboard layout before
> changing/entering the password.

But it also happens with DVD install, see my comment 26 and 30 and also https://bugzilla.novell.com/534023 which is probably related.

This bugreport is getting a mess. As usual discussing seperate issues by different people doesn't help. :-(

Last weekend I tested M6 and got different results depending on media :-/

M6 Live-CD/KDE:
---------------
- Booting to it, keyboard works fine :-)
- Installing it, generates a wrong /etc/sysconfig/keyboard (replacing it with the one generated with DVD, everything is fine again).

M6 DVD:
-------
- Generates a right /etc/sysconfig/keyboard
- according to /etc/sysconfig/keyboard, tty console's keyboard is set to spanish, wich is ok
- X keyboard is allways set to us, wich is wrong

Here the questions are:

a) why are behaving diferent CD a DVD media? is it due to changes between builds or are we setting it up in a different way?

b) why X keyboard is set ignoring /etc/sysconfig/keyboard? where do we store here system wide default keyboard?

In reply to comment #39:

> Do you get or don't you get correct entries in /etc/sysconfig if you select
>german before booting?

Not with DVD media, yes with CD-Live-KDE

In reply to comment #40:

> Thanks. So we have consistent and expected behaviour.

No, we haven't: selecting 'spanish' before booting, i get 'spanish' in tty console, and us in X, wich at least is inconsistent.

In reply to comment #38

> what will happen if a user set the password to e.g. '3$g2!n-6'

This "is not" a big problem, because at least all this signs are present in us keyboard.

The big problem is when you set the password to something like "caña-2ç4" (I did it during M3-DVD install, when I opened this bug): in this case there is no way to login, then no chance to setup keywoard in KDE/GNOME preferences and system turns inusable.

(In reply to comment #44)
> Last weekend I tested M6 and got different results depending on media :-/
> 
> M6 Live-CD/KDE:
> ---------------
> - Booting to it, keyboard works fine :-)
> - Installing it, generates a wrong /etc/sysconfig/keyboard (replacing it with
> the one generated with DVD, everything is fine again).

Please open a seperate bugreport filed against YaST2. You selected the right keyboard layout in http://en.opensuse.org/Image:OS11.1-live-inst-1.png?

> M6 DVD:
> -------
> - Generates a right /etc/sysconfig/keyboard
> - according to /etc/sysconfig/keyboard, tty console's keyboard is set to
> spanish, wich is ok
> - X keyboard is allways set to us, wich is wrong

This is this bug, I never could reproduce.

> a) why are behaving diferent CD a DVD media? is it due to changes between
> builds or are we setting it up in a different way?

It's the same setup, i.e. no xorg.conf in use any longer unless you run
sax2 manually and set 'Option "AutoAddDevices" "off" in this file.

> b) why X keyboard is set ignoring /etc/sysconfig/keyboard? where do we store
> here system wide default keyboard?

/etc/X11/xdm/keytable4hal is called by xdm init script, reads /etc/sysconfig/keyboard:KEYTABLE, maps it to the appropriate X keyboard layout and generates /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi. This again is read by hald
and been provided as keyboard setting to the Xserver. Something like this.

(In reply to comment #45)
> > Thanks. So we have consistent and expected behaviour.
> 
> No, we haven't: selecting 'spanish' before booting, i get 'spanish' in tty
> console, and us in X, wich at least is inconsistent.

Which I can't reproduce.

Egbert, could you try to reproduce. I simply can't.

Just installed Milestone6 x86_64 from DVD (no live dvd or live cd).
I had the same problem, I started the DVD by just pressing Enter for install.
When the graphical system started I left English (US) as language setting but changed the keyboard to german with deadkeys.
I selected kde manually added thunderbird and pidgin to the software selection.

The installed system has the german keyboard layout at the mode (Strg+Alt+F1), but kdm and kde do still use the us keyboard layout. 
I hope this helps you reproduce this bug.

In case its needed, my system is a M2A-VM Mainbard (690G Chipset).

OK, I cannot reproduce the issue here either.
Originally I had 
KEYTABLE="us"
which gave me an us keyboard.
This I changed to:
KEYTABLE="de-latin1-nodeadkeys"
I did: 
init 3; init 5; # restart the Xserver
logged in via KDE, got a german keybard.

Those people who see this problem, could you please start a 'failsave' session, and in the xterm which opens do: 'setxkbmap -print'?
If this tells you something about 'us' on the symbol line please attach:
a. /etc/sysconfig/keyboard
b. /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi
c. the output from 'setxkbmap -print'.

Ok, I just started a new session as failsave.
setxkbmap -print shows:
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)"     };
        xkb_geometry  { include "pc(pc104)"     };
};

Just to be clear, I just changed the keyboard layout for installation, language is still English(US), in case this matters.

Created attachment 316044 [details]
/etc/sysconfig/keyboard

Created attachment 316045 [details]
/usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi

(In reply to comment #52)
> Ok, I just started a new session as failsave.
> setxkbmap -print shows:
> xkb_keymap {
>         xkb_keycodes  { include "evdev+aliases(qwerty)" };
>         xkb_types     { include "complete"      };
>         xkb_compat    { include "complete"      };
>         xkb_symbols   { include "pc+us+inet(evdev)"     };
>         xkb_geometry  { include "pc(pc104)"     };
> };
> 
> Just to be clear, I just changed the keyboard layout for installation, language
> is still English(US), in case this matters.

It shoudln't. The information in the sysconfig/keyboard and in the 11-keymap.fdi file are both correct:
- KEYTABLE="de-latin1.map.gz"
- <merge key="input.xkb.layout" type="string">de</merge>

Tristan, have you restarted the Xserver after you changed to a German keyboard?
(logging out of the session doesn't restart the server any more, doing 'init 3; init 5' from the console seems to be the easiest way to do this).

I already changed the keyboard layout during installation (not at the isolinux menu but in the first  yast installation step, before selecting new installation).
I've already restarted the whole system several times and still have german layout at the console (Strg+Alt+F1) and US layout at KDE 4.3.

Ok, thanks! Tristan, could you please get and attach the output of:

for i in `hal-find-by-capability --capability "input.keys"`; do lshal -u $i; done

Created attachment 316253 [details]
output of for i in `hal-find-by-capability --capability "input.keys"`; do lshal -u $i; done as normal user

output of 

for i in `hal-find-by-capability --capability "input.keys"`; do lshal -u $i; done 

as normal user

(In reply to comment #58)
> Created an attachment (id=316253) [details]
> output of for i in `hal-find-by-capability --capability "input.keys"`; do lshal
> -u $i; done as normal user
> 
> output of 
> 
> for i in `hal-find-by-capability --capability "input.keys"`; do lshal -u $i;
> done 
> 
> as normal user

There is a bunch of stuff missing.
There should be lines like:
  input.x11_driver = 'evdev'  (string)
  input.xkb.layout = 'de'  (string)
  input.xkb.model = 'pc104'  (string)
  input.xkb.rules = 'base'  (string)
This seems to be a HAL issue: HAL doesn't seem to merge 
/usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi.
Looking at the attachment in comment #54 I cannot see why as the condition
 <match key="info.capabilities" contains="input.keys">
is met by those entries.
There seems to be an issue with HAL.

Kay, any ideas what's going on here?

Comparing /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi with 11.1 /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi, one line is missing:

diff -Nur 10-keymap.fdi 11-keymap.fdi
--- 10-keymap.fdi       2009-09-02 20:46:27.009431415 +0200
+++ 11-keymap.fdi       2009-09-02 20:25:58.769835777 +0200
@@ -17,6 +17,7 @@
       </match>

       <merge key="input.xkb.layout" type="string">es</merge>
+      <merge key="input.xkb.variant" type="string" />
     </match>
   </device>
 </deviceinfo>

Reintroducing this line has fixed for me this bug in ALL my 6 problematic systems.

Is this a feature or is just the bug we ar looking for?

Good catch, Miquel! Changed this now in keytables4hal script (xorg-x11 package in X11:XOrg project; also SR'ed for openSUSE:Factory).

Tristan, Alex, Christian. Can you confirm that adding this line fixes the issue?

(In reply to comment #62)
> Good catch, Miquel! Changed this now in keytables4hal script (xorg-x11 package
> in X11:XOrg project; also SR'ed for openSUSE:Factory).
> 
> Tristan, Alex, Christian. Can you confirm that adding this line fixes the
> issue?

It's strange actually. According to the HAL specs the variant property isn't even mandatory.

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

I can confirm that adding the line from comment #61 fixes the issue.
Thanks!

I'm wondering if due to a change in system time during configuration the cache file is newer than the 11-keymap.fdi file and thus the cache didn't get updated.
If someone who still sees this issue could just make a touch on 
 /usr/share/hal/fdi/policy/20thirdparty/11-keymap.fdi
or alternatively remove the hald cache file:
 /var/cache/hald/fdi-cache
Apart from this I have no explanation why the elements from 11-keymap.fdi have not been merged. I cannot find anything in the HAL code (and it wouldn't make sense to me) which would check for individual device properties.

NEEDINFO to Kay again.

What's the question please?

Looking at hald code the cache gets invalidated thru an inotify but only regenerated if the cache file timestamp is older than the timestamp of at least one of the files. Also during the lifetime if hald it seems like even though the cache is marked invalid it only gets regenerated when a new device is registered.
I would think it ought to be regenerated the main loop whenever some request comes in. But I'm just starting to get familiar with HAL.

Kay, I wonder if you could shed some light on what we are seeing here:
A .fdi file gets added, it's supposed to add input.xkb.* properties to input.key devices but even after several reboots those entries don't show up in the lshal output.
Then suddenly when a new input.xkb.* property is added things start to work.
I've tried to give an explanation in comment #66 and contemplated on some observations in comment #69.
Maybe you can give us an idea here. Because I'm afraid adding xkb.variant entries may have fixed the problem for people who already see them but will not address the issue for people who freshly install their system.

(In reply to comment #69)
> I would think it ought to be regenerated the main loop whenever some request
> comes in.

I don't know anything about this code, sorry.

> But I'm just starting to get familiar with HAL.

Hope you noticed that HAL will die and go away soon. It's in maintenance mode and no longer developed. So anything else than important bug fixes would be pretty much a waste of time.

(In reply to comment #70)
> Kay, I wonder if you could shed some light on what we are seeing here:
> A .fdi file gets added, it's supposed to add input.xkb.* properties to
> input.key devices but even after several reboots those entries don't show up in
> the lshal output.

I have no idea how that can happen. If you can reproduce it, you can try to run HAL in debug mode, and see if the log says something. The instructions to enable logging are here:
  http://en.opensuse.org/HAL#Debugging.2FBugreporting

(In reply to comment #71)
> (In reply to comment #69)
> > I would think it ought to be regenerated the main loop whenever some request
> > comes in.
> 
> I don't know anything about this code, sorry.

Forgot to say, that only newly added devices will see the new fdi properties. Adding an fdi file, or changing one will only affect newly added devices, not already existing ones.

We also need to be sure that all this isn't a behavior caused by a probably mis-compiled HAL package, like in this bug:
  https://bugzilla.novell.com/show_bug.cgi?id=535661

Ok, with my last patch to xorg-x11 which removes the hald cache before restarting hald I assume this issue is fixed.
Please feel free to add further test results. If my assumption proves wrong we can reopen the ticket.

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

Works fine in M7

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

Does bug 542009 have a different cause? I'm still seeing it in MS7 and MS8 but not on every platform (VirtualBox works, Laptop(Amilo Pro 2030) has bug)
maybe related: bug 534023, bug 534300

These have different causes, and are unrelated, yes.

With M8 it works fine for me, so I got spanish layout after install.

Installing 11.2 RC1 KDE LiveCD results in a US keyboard map rather than the chosen UK one on an Acer Aspire One ZG5 AOA 150. I have no 11-keymap.fdi in /usr/share/hal/fdi/policy/20thirdparty . setxkbmap -print   results in

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)"     };
        xkb_geometry  { include "pc(pc104)"     };
};

/etc/sysconfig/keyboard has

KEYTABLE="us.map.gz"

Created attachment 322719 [details]
Xorg.0.log for leny2010s report

The path taken at installation was to select Installation from the ISOLINUX menu. Choose UK country at the first screen and allow it to automatically select UK keyboard.  After that the defaults were  (retaining existing /home), save for selecting Copy of System Emails and the user details. 

The problem is overcome by post install using Yast2 to set the country language.

The LiveCD was booted of a USB stick after being dd 'd as per en.opensuse.org instructions.

The path taken at installation was to select Installation from the ISOLINUX menu. Choose UK country at the first screen and allow it to automatically select UK keyboard.  After that the defaults were  (retaining existing /home), save for selecting Copy of System Emails and the user details. 

The problem is overcome by post install using Yast2 to set the country language.

The LiveCD was booted of a USB stick after being dd 'd as per en.opensuse.org instructions.

1. This bug is not about installation from LiveCD.
2. The location for the .fdi file has changed to /etc/hal/fdi/policy/...

AFAIK there are various bugreports about wrong keyboard layout after installation from LiveCD. In case you can't find any of these, open a new one against YaST or installation component. I really don't want to discuss unrelated issues in a 84+ comments bug. It's already confusing enough.