GNOME Bugzilla – Bug 414571
the default keyboard should be the default keyboard for gdm
Last modified: 2013-12-16 18:41:09 UTC
When gdm is loaded in ubuntu the keyboard active is the one in xorg.conf not the one configured with gnome-keyboard-properties. So should gnome-keyboar-properties be able to change xorg.conf also? Maybe at a default system keyboard checkbox which only can be set with administrator rights. So when you check the checkbox it will ask your root pasword.
No, gnome-keyboard-properties will NEVER change xorg.conf because they are for per-user settings, not per-system. xorg.conf is a very troublesome file for programmatic modifications (read "not XML":), so I will not mess with it. I think the right solution would be to hack gdm to include the keyboard settings.
How do you propose that GDM knows which user's keyboard settings should be used to configure GDM? Note that by the time GDM knows the user you want to log in as, you are finished typing your username and password (in other words all the typing you need to do in GDM). Perhaps gnome-keyboard-properties (or some other program) could offer a feature that would allow users to more easily configure their xorg.conf file, but I don't think that GDM is the right program to do this. Whatever program is used to configure your xorg.conf system-wide keyboard settings should work for users who are using other display managers (such as KDM or xdm). Tying it to GDM makes no sense. Please reassign this bug to the right module for fixing this problem. I will close it if it is left in the gdm category. Unless you can argue that this is somehow really a gdm issue.
Ok, let me describe the way I see it: 1. I do not know whether any gconf is available to gdm (from gdm's user?). If it does, it would make life a bit easier, otherwise some extra hacking would require. But there is absolutely no need to change xorg.conf. 2. Gdm would keep keyboard configuration in his config (gconf-based or not) and actualize it on startup of gdm-chooser. libgnomekbd could help here (the same way it helps gnome-settings-daemon). Also, libgnomekbd could provide the keyboard indicator as well (as it does for the screensaver unlock panel). Does this make sense?
It is technically possible for the gdm user to access GConf if the gdm user has a writable $HOME directory, but there are some things to consider. Remember that the gdm user is designed to have "least privilege" so that if the user somehow exploits the login program, the user doesn't have root privilege. Today, the "gdm" user does not require a $HOME directory (writable or not). If you were to make GDM use .gconf then it would require this. Some may argue that the gdm user having a writable $HOME directory wouldn't be a huge problem, but adding privilege to the gdm user does add some risk. It's naturally difficult to assess how much risk is exposed by adding privilege. Therefore, it would be better if the GDM user made use of some other configuration mechanism that didn't require a $HOME directory. GDM has its own configuration file which might be a better place to store such configuration needed to setup/configure how GDM operates. This might require writing a new frontend for libgnomekbd that works with a GDM configuration mechanism rather than GConf settings. Does this make sense?
> Therefore, it would be better if the GDM user made use of some other > configuration mechanism that didn't require a $HOME directory. GDM has its own > configuration file which might be a better place to store such configuration > needed to setup/configure how GDM operates. This might require writing a new > frontend for libgnomekbd that works with a GDM configuration mechanism rather > than GConf settings. Well, there is no need to write special "frontend" for libgnomekbd. All gdm would need is saving/loading GkbdKeyboardConfig into his own configuration file (and ok, let's forget about gconf, I see your point here). I think this is doable. And sure I can give any help required.
Cool. I'll be waiting for your patch then. :) I'm not exactly sure what configuration GDM would need to support keyboard configuration. However, if you want to highlight what would be needed to put into GDM configuration, I'd be happy to help figure out how we could specify this in the configuration file.
Ghm, I am not really familiar with gdm internals. But if I find time... BTW, if you are going to be @GUADEC, we could have a quick session about it. As I said, the main thing is GkbdKeyboardConfig (http://svn.gnome.org/viewcvs/libgnomekbd/trunk/libgnomekbd/gkbd-keyboard-config.h?revision=12&view=markup) You should save model, layout_variants, options. If you look at other save/load functions (from X or GConf), you'll get the idea. Then, gkbd_keyboard_config_activate would actualize the configuration. For the sample, you can have a look at the code in g-s-d: http://svn.gnome.org/viewcvs/gnome-control-center/trunk/gnome-settings-daemon/gnome-settings-keyboard-xkb.c?revision=7434&view=markup
Thanks for the pointers. It might make sense to hold off on this until the D-Bus rewrite goes in. The D-Bus rewrite makes it easier to run various programs along with GDM more easily, so integrating this should be easier then. I'm a little wary to muck with the GDM configuration too much to support this sort of feature until after the rewrite, since the configuration stuff is changing.
gdm reads ~/.dmrc to help per-user to login with the recently used language/layout. gnome-settings-daemon reads the gconf data set by gnome-keyboard-properties to replace the language/layout. It is a conflict.
this should all work well, now i think (and has for some time)