Bug 579119

Summary: yast2 keyboard does not update /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi
Product: [openSUSE] openSUSE 11.2 Reporter: Forgotten User CHC7OcAR44 <forgotten_CHC7OcAR44>
Component: YaST2Assignee: Jiří Suchomel <jsuchome>
Status: RESOLVED WONTFIX QA Contact: Jiri Srain <jsrain>
Severity: Major    
Priority: P2 - High CC: lnussel
Version: Final   
Target Milestone: ---   
Hardware: i586   
OS: openSUSE 11.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Forgotten User CHC7OcAR44 2010-02-11 15:18:46 UTC
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-2.1 Firefox/3.5.2

I use 'yast(2) keyboard' to select my keyboard layout.  After that, /etc/sysconfig/keyboard contains my newly selected keyboard layout, but /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi still contains an old (and wrong, of course) keyboard layout.  When I then (re)start 'X' to get a pure X server, the keyboard is wrong.

Reproducible: Always

Steps to Reproduce:
1.type init 3, to stop the xdm system
2.select another keyboard layout using 'yast keyboard'
3.check if /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi is updated.  It is not.
  Also, if I remove  /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi before calling 'yast keyboard',   /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi is not created.
Comment 1 Forgotten User CHC7OcAR44 2010-02-11 19:11:51 UTC
I have now found that there is a script called /etc/X11/xdm/keytable4hal that does create /etc/hal/fdi/policy/20thirdparty/11-keymap.fdi with the changed keyboard layout info.  I can solve my problem if I call that script after 'yast keyboard', but I still think that it should be more straightforward.
Comment 2 Stefan Dirsch 2010-02-16 17:20:53 UTC
This script is called in /etc/init.d/xdm. So "rcxdm restart" fixes that issue as well. In case we reintroduce the YaST module for the keyboard on Linux console the script needs to be run by YaST. Reassigning.
Comment 3 Forgotten User CHC7OcAR44 2010-02-16 22:50:33 UTC
Actually, I start my X server using directly the command 'X -ac -retro', because I only want to make an X server.
Also, the script is currently only called by 'xdm start', so it won't be invoked after CTRL-ALT-BACKSPACE, which only restarts the X server.
Comment 4 Jiří Suchomel 2010-02-25 12:56:00 UTC
(In reply to comment #2)
> This script is called in /etc/init.d/xdm. So "rcxdm restart" fixes that issue
> as well. In case we reintroduce the YaST module for the keyboard on Linux
> console the script needs to be run by YaST. Reassigning.

Well, "rcxdm restart" will kill X session, which is not what we want to do from YaST. Do you know gentler solution?
Comment 5 Stefan Dirsch 2010-02-25 13:02:02 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > This script is called in /etc/init.d/xdm. So "rcxdm restart" fixes that issue
> > as well. In case we reintroduce the YaST module for the keyboard on Linux
> > console the script needs to be run by YaST. Reassigning.
> 
> Well, "rcxdm restart" will kill X session, which is not what we want to do 
> from YaST. Do you know gentler solution?

Well, another option would be to copy the code from /etc/init.d/xdm

        # use system keyboard as global X keyboard configuration
        if [ -x /etc/X11/xdm/keytable4hal ]; then
           if /etc/X11/xdm/keytable4hal; then
               /etc/init.d/haldaemon stop && \
                   rm -f /var/cache/hald/fdi-cache && \
                   /etc/init.d/haldaemon start
           fi
        fi
Comment 6 Jiří Suchomel 2010-02-25 13:15:36 UTC
Well, I do not see why YaST should do this. 

Could it be part of kdb script, which is restarted from YaST? Or some other stand alone one, that should YaST call directly? Are there any more conditions when it should be called and when not?
Comment 7 Stefan Dirsch 2010-02-25 13:34:41 UTC
(In reply to comment #6)
> Well, I do not see why YaST should do this.

Why not?

> Could it be part of kbd script, which is restarted from YaST? 

Why? It's X configuration, not Linux console keyboard.

> Or some other stand alone one, that should YaST call directly? Are there any 
> more conditions when it should be called and when not?

Not that I'm aware of.
Comment 8 Jiří Suchomel 2010-02-26 13:46:22 UTC
YaST cannot do such dark magic. If something should be changed in such code we well not know about it.

Either do that action in some of the script already called by YaST (what about setxkbmap?), or create a standalone script from that that you are going to maintain and YaST could call such script.


BTW, do I understand it correct that if user would use login manager himself, it would work for him? Than we can declare it as invalid, I think.
Comment 9 Stefan Dirsch 2010-02-26 14:14:32 UTC
(In reply to comment #8)
> YaST cannot do such dark magic. If something should be changed in such code we
> well not know about it.

Well, thinking about it once more, it might not be a good idea to restart haldaemon on top of a Xsession (not sure what will happen then), but you need to do this so that the new HAL keyboard settings get active. Additionally you need to restart the Xserver  afterwards. The only safe way I see this all can happen is in /etc/init.d/xdm script.

> BTW, do I understand it correct that if user would use login manager himself,
> it would work for him? Than we can declare it as invalid, I think.

You mean user restarts login manager himself? Just using a login manager doesn't help of course.

I don't see how to resolve that issue other than informing that (s)he needs
to restart xdm script. Well, it wasn't my idea to reintroduce static X11 keyboard configuration in YaST2.
Comment 10 Jiří Suchomel 2010-02-26 14:18:32 UTC
Ludwig, I think you had some comments about the implementation, do you have any idea here?
Comment 11 Ludwig Nussel 2010-02-26 14:28:20 UTC
see bug 541351
Comment 12 Jiří Suchomel 2010-03-09 12:28:42 UTC
Well, according bug 541351, this seems to change anyway...

Please tell me if YaST should do anything when 541351 is resolved.
Comment 13 Stefan Dirsch 2010-03-09 15:10:51 UTC
I don't see a solution for that issue for HAL. I don't think this is going to change for the successor.