GNOME Bugzilla – Bug 674874
don't read .xmodmap files by default
Last modified: 2017-07-17 18:26:52 UTC
Currently we read a set of xmodmap files from HOME gchar *xmodmap_file = g_build_filename (g_get_home_dir (), XMODMAP_KNOWN_FILES [i], NULL); This probably not a great idea because it can silently break the user's input and there is no way to fix it from the UI. Perhaps we should ignore them by default.
Before, we had that setting in g-s-d (configurable in gconf) - the list of "well-known" xmodmap files. It was enough just to make that list empty in gconf. Then, it was removed: http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/keyboard/gsd-keyboard-xkb.c?id=4239cb8a5d73af79d2cdf0f294a33d31fbbb9afe Are you saying it should be returned back? Of course, dropping .xmodmap support is not an option.
(In reply to comment #1) > Before, we had that setting in g-s-d (configurable in gconf) - the list of > "well-known" xmodmap files. It was enough just to make that list empty in > gconf. Then, it was removed: > > http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/keyboard/gsd-keyboard-xkb.c?id=4239cb8a5d73af79d2cdf0f294a33d31fbbb9afe > > Are you saying it should be returned back? > > Of course, dropping .xmodmap support is not an option. That code should be removed, and we should add code to gnome-settings-daemon to call the hotplug script for keyboards too. See bug 674221.
(In reply to comment #2) <snip> > That code should be removed, and we should add code to gnome-settings-daemon to > call the hotplug script for keyboards too. See bug 674221. Which to happen needs libgnomekbd to do _nothing_ on keyboard plug, otherwise you'll end up breaking what people put in the scripts...
libgnomekbd should definitely configure new keyboards with the layouts specified in the g-c-c. AFTER that, xmodmap settings should be applied (directly, using explicit xmodmap support - or indirectly through the script). I do not mind replacing xmodmap execution with the script execution - that does the job anyway.
(In reply to comment #4) > libgnomekbd should definitely configure new keyboards with the layouts > specified in the g-c-c. gnome-settings-daemon should be asking libgnomekbd to do it then. Otherwise there's two things racing to set layouts, etc. on keyboards. 1. launch pre-script 2. tell libgnomekbd to set the layouts 3. launch post-script But we need libgnomekbd to stop touching devices unless it's been asked to. That means anything in the "device-added" signal handler needs to be made something for gnome-settings-daemon to call.
Currently the model is 1. libxklavier is notified by XKB 2. g-s-d notified by libxklavier's signal (X-new-device) 3. g-s-d configures XKB (apply_xkb_settings) 4. g-s-d invokes libgnomekbd's xmodmap support (gkbd_keyboard_config_patch) So, between #2 and #3 g-s-d can invoke pre-script. And instead of #4 g-s-d would call the post-script. Is that fair?
I thought that there was no need for a pre-script. gnome-settings-daemon fixed in master, up to you now.
Agreed. The function is removed from libgnomekbd. Actually, not that kbd code in g-s-d and g-c-c is under heavy redesign (with the vision to enhance ibusability) - I am totally prepared to pass the ownership of libgnomekbd to anybody interested. It only makes sense as a helper library for g-s-d and g-c-c, these 2 projects should drive the requirements to libgnomekbd...
So how do I enable those scripts? where is the documentation?