Bug 479746

I just found out that as a side-effect this prevents the users from changing the keyboard layout in HAL. I tried to force 

<merge key="input.xkb.layout" type="string">cz,us</merge> 

either in /etc/hal... or in the existing /usr/share/hal... fdi files, but it doesn't take effect until I removed the callout for fedora-setup-keyboard from /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi -- I don't understand why indeed, but...that's the way it is :(

Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available) and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf (if you have one) whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

handing over to hal, this isn't an evdev problem.

I just realized that fedora-setup-keyboard is just a shell script, so here I'm posting "-x" output:

>fedora-setup-keyboard                                   
+ [[ -x /usr/bin/python ]]                               
+ [[ -x /usr/bin/hal-set-property ]]                     
+ source /etc/sysconfig/keyboard                         
+ [[ -n cz-us-qwertz ]]                                  
++ rhplquery cz-us-qwertz                                
++ /usr/bin/python -c 'import rhpl.keyboard_models; m = rhpl.keyboard_models.KeyboardModels().get_models(); print "junk='\''%s'\'' layout='\''%s'\'' model='\''%s'\'' variant='\''%s'\'' options='\''%s'\''" % tuple(m["cz-us-qwertz"])'                                                                                  
+ eval 'junk='\''Czech'\''' 'layout='\''us,cz'\''' 'model='\''pc105'\''' 'variant='\'''\''' 'options='\''grp:shifts_toggle,grp_led:scroll'\'''               
++ junk=Czech
++ layout=us,cz
++ model=pc105
++ variant=
++ options=grp:shifts_toggle,grp_led:scroll
+ hal_set layout
+ [[ -n us,cz ]]
+ /usr/bin/hal-set-property --direct --udi '' --key input.xkb.layout --string us,cz

error: libhal_ctx_init_direct
+ hal_set model
+ [[ -n pc105 ]]
+ /usr/bin/hal-set-property --direct --udi '' --key input.xkb.model --string pc105

error: libhal_ctx_init_direct
+ hal_set variant
+ [[ -n '' ]]
+ /usr/bin/hal-set-property --direct --udi '' --key input.xkb.variant --remove

error: libhal_ctx_init_direct
+ hal_set options
+ [[ -n grp:shifts_toggle,grp_led:scroll ]]
+ /usr/bin/hal-set-property --direct --udi '' --key input.xkb.options --string grp:shifts_toggle,grp_led:scroll

error: libhal_ctx_init_direct

The $UDI variable is really *not* set anywhere, where should it be? In the sourced /etc/sysconfig/keyboard? Even after adding the following line to that file:
UDI="/org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input"
I'm still getting similar output:

>fedora-setup-keyboard                                                                                    
+ [[ -x /usr/bin/python ]]                                                                                
+ [[ -x /usr/bin/hal-set-property ]]
+ source /etc/sysconfig/keyboard
+ [[ -n cz-us-qwertz ]]
++ rhplquery cz-us-qwertz
++ /usr/bin/python -c 'import rhpl.keyboard_models; m = rhpl.keyboard_models.KeyboardModels().get_models(); print "junk='\''%s'\'' layout='\''%s'\'' model='\''%s'\'' variant='\''%s'\'' options='\''%s'\''" % tuple(m["cz-us-qwertz"])'
+ eval 'junk='\''Czech'\''' 'layout='\''us,cz'\''' 'model='\''pc105'\''' 'variant='\'''\''' 'options='\''grp:shifts_toggle,grp_led:scroll'\'''
++ junk=Czech
++ layout=us,cz
++ model=pc105
++ variant=
++ options=grp:shifts_toggle,grp_led:scroll
+ hal_set layout
+ [[ -n us,cz ]]
+ /usr/bin/hal-set-property --direct --udi /org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input --key input.xkb.layout --string us,cz

error: libhal_ctx_init_direct
+ hal_set model
+ [[ -n pc105 ]]
+ /usr/bin/hal-set-property --direct --udi /org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input --key input.xkb.model --string pc105

error: libhal_ctx_init_direct
+ hal_set variant
+ [[ -n '' ]]
+ /usr/bin/hal-set-property --direct --udi /org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input --key input.xkb.variant --remove

error: libhal_ctx_init_direct
+ hal_set options
+ [[ -n grp:shifts_toggle,grp_led:scroll ]]
+ /usr/bin/hal-set-property --direct --udi /org/freedesktop/Hal/devices/platform_i8042_i8042_KBD_port_logicaldev_input --key input.xkb.options --string grp:shifts_toggle,grp_led:scroll

error: libhal_ctx_init_direct

Furthermore: "cz-us-qwertz" shouldn't be converted to "us,cz" of course.

> Steps to Reproduce:
> 1. Type fedora-setup-keyboard

are you running as root?
why do you need to run this standalone anyway?

(In reply to comment #6)
> are you running as root?

It doesn't matter, it happens under root account as well as under any other regular user account.

> why do you need to run this standalone anyway?

Ehm...I even wouldn't need to know there is something like fedora-setup-keyboard, if it wouldn't break setting correct keyboard layout in X for me, read my comment #1 (this is how I found out the command doesn't work and later on I discovered that *therefore* any settings in hal's fdi files are ignored).

Have you tried with the latest hal package in Fedora 10, Fedora 11 or tried Rawhide? In either case, can you let us know whether the issue is still happening, and give the current version of the HAL packages you're using?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. 

    Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem please feel free to reopen the bug report. 

TK009
-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers