The single source of XKB configuration is /usr/share/X11/xkb. That solution does not allow people to provide local materials (symbols, types, models, layouts, variants, options ...) without patching the original OS files. That bug is about adding extra bits to X code that would facilitate using local XKB files from /etc/X11/xkb that would be considered as addition to /usr/share/X11/xkb. 2 main issues here: 1. The low level materials (symbols, types, compat) can be put to the additional directory /etc/X11/xkb/symbols and xkbcomp can use -I option to include other directories. Relatively easy to manage 2. The problem of rules/base and rules/base.xml - all tools that used to access those files from /usr/share/X11/xkb (including DEs like GNOME) should realize there are 2 sources of information, 2 directories (or more?)
We need patches for this in the server too to handle the actual parsing of the various XkbOptions rules. That looks relatively simple, call XkbRF_LoadRules() a second time for the other path and then add -I to the xkbcomp invocation. got a patch for that and it looks like it works. A more complete approach would be to add the new include path as automatic second default path in xkbcomp, don't have that yet. setxkbmap is similar, can be made to load both paths. the DE tools are a bit harder since they all need to be updated individually.
Adding /etc/X11/xkb to the search path sounds like a good idea to me. Since this was opened against xkbcommon I'll mention it's easy to add there too. One issue is that in order to use whatever files I add to my /etc in the form of an RMLVO (that is setxkbmap, xorg.conf, layout chooser, etc.) I must create a new rules file entry. But the rules file format and the xml don't support any sort of include statement. So I have to copy and edit the system file, which is suboptimal. I guess it's possible to change the RMLVO format to accept a comma-seperated list for the Rules as well, as it does for the layout, variant and options? e.g. 'setxkbmap -rules myrules,evdev'.
I think that's a bit risky because the comma is a separator between two distinct items, not a list of to-be-merged items. e.g. setxkbmap -layout "us,de" is US + german layout as separate groups. But I think most of the custom-include use-cases will make use of existing layouts, so really what you want is something like setxkbmap -rules "evdev+myrules", i.e. load evdev but then merge myrules in. having said that, is the rules file format defined anywhere but in our stack's implementation? adding include directives may be the best path here.
Right, the '+' is only used for the kccgst's, that's why I didn't think about it, but it's better. Btw, in kccgst, '+' means override, '|' means augment (though the xserver and xkbfile have a small issue with it[1][2]). [1] http://lists.x.org/archives/xorg-devel/2012-August/033458.html [2] http://lists.x.org/archives/xorg-devel/2012-August/033459.html The format is not used anywhere else that I know. There is a parser in xkbfile and an exact copy in the xserver (maprules.c). We intially imported that into xkbcommon, but it was enough of an eyesore that I rewrote it (src/xkbcomp/rules.c, some documentation here[3]). [3] https://raw.github.com/xkbcommon/libxkbcommon/master/doc/rules-format.txt I think adding an include statement is definitely possible, as long as it isn't used by e.g. rules/evdev, so old parsers continue to work. Also implementing in xkbcommon is not a problem, xkbfile might take a bit more effort...
The other option is implicit merging, so if there is an "evdev" rules file in multiple source directories, they get implicitly merged. This is relatively easy but less obvious since the include order relies on the configuration directory order (a compile-time setting). At this point, a include directive seems like the best option still. I'd have to remove a hardcoded xkb rule from evdev but that's easy. > I think adding an include statement is definitely possible, as long as it > isn't used by e.g. rules/evdev, so old parsers continue to work. yeah, we should probably even add some sort of test into xkeyboard-config that checks that no rules directive is ever merge there.
> yeah, we should probably even add some sort of test into xkeyboard-config > that checks that no rules directive is ever merge there. Never heard about any include stmt in rules.(In reply to comment #5) Actually, I am totally for include directive, that would allow to make rules modular, even within the same directory. It is already 1K+ lines long.
I wrote up the include support in xkbcommon, you can see it here if you're interested: https://github.com/xkbcommon/libxkbcommon/commits/bug-74422 The syntax is ! include myrules Do you see any need for something more complicated? Semantically it is equivalent to simple text substitution (like #include), so the order matters, and the details of overriding/augmenting are the same. I think the basic rules would need some adjustments though, for example the wildcard rules in rules/evdev, like this one: ! model layout = symbols [snip] * * = pc+%l%(v) and this one ! model = symbols [snip] * = +inet(evdev) make it a bit tricky to add stuff in the user's rules (at least for the layout) and then include evdev. And lets not forget this one... https://bugs.freedesktop.org/show_bug.cgi?id=14372 Been on my TODO list to look at this, since I wanted to support >= 4 groups in xkbcommon. About the xml files, I've never had to deal with them, so don't know. Maybe some 'conf.d'-like dir is possible for those?
(In reply to comment #7) > The syntax is > ! include myrules > Do you see any need for something more complicated? no, I think that's just fine. Anything more complicated will just come back to bite us.
Looks like we can just close this one out now. Any new issues should be filed at https://github.com/xkbcommon/libxkbcommon
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.